-1

I am designing the controller and data acquisition unit for a rocket engine test stand. This system needs to control a number of actuators on the test stand and also be able to transmit collected data back to the host computer where the team will be watching live data/camera feeds from safety.

The overall design requirements are as follows:

  • Acquire data from ~15 analog sensors at 1KHz
  • Control the actuators on the test stand including valves and ignition switches
  • Transmit data back to the host computer in our shelter in real time
  • Accept control from the host computer for things like manual valve actuation, test sequence modification, sequence abortion, etc.

I am not exactly sure where to begin when laying out the software for this system. I am considering using an STM32 ARM Cortex-M4 processor running at 180 MHz. I am having trouble figuring how I should approach the problem. I have considered using an RTOS system but based on what I have seen those generate large overheads as you run them faster as the scheduler has to run each tick. The other idea I'm bouncing around is a state machine combined with some timer-based interrupts for reading and then sending data back out to the PC. Any advice as to how to approach this problem to minimize code complexity would be greatly appreciated. Thanks.

EDIT: I have been told to clarify a number of things concerning the technical specs of the system.

My actuators consist of:

  • 6 solenoids (controlled digitally through relays/MOSFET, and switched around once a second)
  • 2 DC motors (driven with PWM outputs in a PID loop, need to be able to ramp position controllably)
  • One igniter, again controlled through a relay/MOSFET

My sensors consist of:

  • 8 pressure transducers (analog voltages)
  • 4 thermocouples (analog voltages)
  • 2 motor encoders (quadrature encoders)
  • 1 light sensor (analog voltage)
  • 1 Load cell (analog voltage)

Ideally all of the collected data (all of the above sensors) plus some additional data (timestamps, motor set positions, solenoid positions) is streamed back to the host computer at in real time.

Dhruv Goel
  • 1
  • 1
  • It would seem that you would benefit from doing everything completely synchronous. Are the reads pure analog voltages or do you need to poke the sensors with some digital serial bus? How CPU-intense this is depends a lot on how you will control the valves. Are they proportional and need PWM? Do you need to regulate them with PID etc? How much data do you need to transfer to the host? As you can tell, there's not enough details to answer the question. "Any advice as to how to approach this problem to minimize code complexity": yep, write a technical specification before anything else. – Lundin Mar 16 '20 at 07:18
  • the RTOS should be slower, event driven or a strictish timed main loop approach may work too. But I think the key here is not settling on one target mcu/brand so quickly. is overkill not allowed, like a pi-zero? cost is quite cheap unless this is some mass produced product. 180mhz is just the system clock MAX, the peripherals likely are a fraction of that and you have many, if there is a host driving this you could have one mcu per sensor. do your system engineering first, communications/I/O are a big factor in the success of the solution. – old_timer Mar 16 '20 at 08:09
  • national instruments if that is still their name likely has a product you plug into a pc that can easily handle the data collection you need as an example, but will no doubt cost more than an mcu. I am sure there are other brands that carry full lines of off the shelf test equipment. – old_timer Mar 16 '20 at 08:10
  • @Lundin I have added the information you mentioned, please let me know if there is anything else you would like to know. – Dhruv Goel Mar 16 '20 at 23:37
  • @old_timer Budget is a pretty big concern and I don't think we'll be able to afford the NI board, I will look into the PI zero. The reason was thinking about this specific MCU is because I have a development board already and I have used the same MCU to design a similar DAQ system for another system (without the need for actuators or data streaming though) – Dhruv Goel Mar 16 '20 at 23:39

1 Answers1

0

Given the motor control with PWM & PID, you need to specify a desired resolution, either in PWM timer ticks or ADC reads. This is the most critical part. It doesn't hurt if the ADC has greater resolution than your specified resolution either. The PCB has to be designed accordingly, with sufficient resolution on resistors etc.

After you've done this, find MCU with sufficiently accurate ADC. I would imagine that 12 bit resolution is enough for most applications, but I don't know your specific case.

Next, you need to decide how fast you want the PID to be. Should an output on the PWM result in a read on the ADC in the next cycle, or could you settle for slower response? The realtime bottleneck here will be the ADC conversion clock, not the CPU.

The rest of the system doesn't seem time critical at all - you just have to ensure that everything is read/set synchronously. The data transmission to/from the host should preferably be done over CAN since it comes with hard real-time characteristics. Doesn't seem that you need a whole lot of bandwidth.

I have designed systems very similar to this using bare metal 16 bit MCUs running on 16MHz. Processing speed is really not a big concern, but meeting real-time deadlines is. That means you can forget about using Linux toys like Rasp PI, it's completely out of the question. And a RTOS is likely overkill since it mostly adds additional complexity.

A bare metal Cortex M with sufficient ADC resolution and CAN seems like a good choice. If you can stay away from floating point, that's nice too - depends on how advanced math you need. If you need nothing more advanced than PID, it can be implemented with fixed point just fine. (Or PI rather, since that usually works best for fast motor control systems.)

Lundin
  • 195,001
  • 40
  • 254
  • 396