The new Sensor Platform is scheduled for its first rocket test next Sunday (2015-10-11). More info will follow.
Just a quick post with update on current progress. I have in Excel drawing up a sketch of the cabinet design for the sensor platform. It consists of two 19″ standard rack cabinets on 1U and 2U. The Sensor Controller is built into the 2U cabinet, and the sensor hardware (Unit) is built into a 1U cabinet.
The two cabinets are mounted in a 4U rack.
The first parts for the hardware enclosures have been ordered, and the below is the picking list from RS-Online. The texts are mostly in Danish, but the link may provide English information.
I expect to receive the parts in the coming week, and the work on cutting all the holes in the 3mm alu front plate will begin. The software implementation is also progressing nicely, and it is time for it to start being used in actual hardware and final implementation and not just in mocks.
I like to do short iterative development, and test every step, so there is a limit on how long you can work with mocks, before it must be tested in real life.
With regards to powering the devices, I actually have started thinking about using PoE – Power over Ethernet. More will follow as decisions are made…
I have started writing the software for the Sensor Platform, and will post some design drawings (UML), when I have got a bit further.
The plan is to implement the Sensor Controller and mock of the Arduino Due in C#, so that it can easily be tested together. Afterwards it will be easy to implement the Arduino Due implementation using the mock as reference.
I have decided to implement support for sampling at higher frequency than 1000 Hz, because I believe the platform will be able to support it. The practical implications of this is changes to the protocol between Sensor Controller and Arduino Due (it will in the future be called Unit), so that the interval between sampling on a sensor can be specified in microseconds and not milliseconds.
- Automatic discovery between Sensor Controller and Unit (Arduino Due) has been implemented. Unit network MAC is used as unique identifier. Discovery works by the Unit broadcasting an UDP package across the network, and the Sensor Controller will reply thereby making both parties aware of each other.
- Configuration of Unit’s sensors are currently being implemented. The Sensor Controller will send an UDP package for each sensor that much be configured to the Unit defining sensor id, sensor type (analog, load cell), input index, sample interval etc.
I have been testing the Arduino Due + WIZ820io module that makes up the real-time component of the Sensor Controller platform.
I previously posted a picture of the Arduino Due board and asked, if anyone could spot the issue with the board. Several replied on facebook with the correct diagnosis. A single pin in the SPI header was not soldered correctly during production of the board.
This issue was actually driving me crazy, because I had not noticed this problem, and the usage of the WIZ820io module included many possible issues like wrong wiring, incorrect manual customization of the Arduino Ethernet library etc.
I have learned the lesson now and will in the future do a thorough visual inspection of all components before use.
The WIZ820io with the W5200 chip has some “usability” issues, which I will go into later including how to wire and configure the module for use with Arduino Due, so even with the soldering fixed it is not totally plug and play.
So after solving the issues, I got a basic example DHCP sketch to work. The network module initialized correctly, and we got an IP from the router.
Before preceding with further implementation of the architecture, it is important to validate that the chosen hardware can actually meet the design goals. The Arduino + WIZ820io platform must be able to deliver sensor data in real-time for multiple sensor sampling at minimum 1000 Hz.
To achieve a sustainable sample rate at 1000 Hz for multiple sensors all sampling and transmitting/storing the sample values must take less than 1 millisecond. To achieve this we must analyse the requirements and design a CPU budget for each operation to ensure that a single cycle in the sensor loop (read all sensors and store/transmit values) takes less than 1 millisecond.
A quick test of the analog read performance using the built-in 12bit ADC shows that it takes approximately 9 nanoseconds per sample (0,000009 milliseconds) equivalent of sample frequency of 111111111 Hz, so analog read performance is not going to be a bottleneck to achieve a sampling rate of 1000 Hz. A CPU budget of 1 microsecond (1/1000 millisecond) is therefore enough for multiple analog sensors such as pressure sensors.
For internal housekeeping, logging, buffer management lets allocate 1 microsecond from the CPU budget.
The last part of the CPU budget consists of transmitting the sensor data, so lets look at some performance tests of the network module with the following configuration:
- Each sensor value consists of 9 bytes of data (id, timestamp and value).
- 4 sensors simulated sampled at 1000 Hz
- SPI is configured at 28 MHz.
- Sensor data are combined into UDP packages with 1 – 100 sensor data values per UDP package.
- 100 Mb/s network link.
The above graph shows the test suite results. X-axis defines the number of sensor values per UDP package, left y-axis and blue line time in milliseconds used for sending the UDP traffic and right y-axis and red line the sending speed in Mb/s.
Studying the sending speed (red line) indicate that the maximum UDP send performance is at approx. 4.,5 Mb/s running SPI at 28 MHz.
The time used for UDP traffic per millisecond (blue line) sharply drops but is at 4 sensor values per UDP package and higher proportional with number of sensor values per UDP package. Who can tell why?
The CPU budget requires us to use maximum 0,998 milliseconds for transmitting data, so we could optimize UDP traffic by combining up to 62 sensor values into a single UDP package taking 0,991 milliseconds. With 4 sensors sampling at 1000 Hz a single UDP package would be enough every 15.5 millisecond ~ 64.5 Hz.
There is really no reason to stretch the CPU budget so much, so a single UDP package must contain 4 – 40 sensor values using 0.183-0.687 milliseconds of the CPU budget.
You may wonder why not just always combine 4 sensor values into a UDP package, if this gives the best CPU budget. Well multiple aspects must be included into the analysis. The platform architecture enables multiple Arduino Due to be connected to a single Raspberry Pi (that acts as the controller and receives all sensor data), so it is also important to consider how many resources must be used by the receiver of the UDP traffic in this case the Raspberry Pi acting as the controller. The software running on the Raspberry Pi can more effectively process fewer bigger UDP packages than many small packages.
A value between 4 – 40 sensor values per UDP package must therefore be chosen that best matches the gives combination of resources on both the Raspberry Pi (controller) and Arduino Due (sensors). Further tests will help identify the value more precisely. It may end up being a configurable value to fit each setup of sensors.
The conclusion is that the Arduino and WIZ820io module can without problems sample multiple analog sensors at 1000 Hz and real-time stream the data to the controller using the UDP protocol.
Next we will go into details about the WIZ820io module and the implementation progress of the sensor platform.
So to start with let us look at the overall architecture of the second generation of the Sensor Controller platform.
The overall requirements are:
- Support sampling on multiple sensors simultaneous at 1000 Hz per sensor.
- Store sample data locally on a USB device
- Real-time stream sensor data to operator
- support no configuration usage
- scalable design that can be extended with many types of sensors
- hardware components must be cheap standard commodities and easy to obtain. Arduino and Raspberry Pi platform is preferred due to the big community and low prices.
Based upon the requirements it is clear that the sensor platform must move sensor data between components very fast.
Lets say we sample on 4 pressure sensors at 1000 Hz and the data packages looks like:
|Sensor Id||Time code (milliseconds)||Sensor value|
|1 Byte||4 byte||4 byte|
This requires transmitting 1000 * 4 * 9 = 36,000 bytes/second or 288,000 bits/second.
So what are the candidates for transferring data, if we base the platform on Arduino and Raspberry Pi.
- Standard serial communication / UART – Raspberry Pi and Arduino supports UART communication at a rates above 1 Mb/s. The Raspberry Pi has a single UART and Arduino has several.
Devices must share the same ground unless additional components are used.
- I2C – Raspberry Pi and Arduino supports I2C at frequencies up to 400 kHz, but actual transfer rates will be much lower than 400 kb/s. Raspberry Pi supports 2 I2C buses.
Devises must share the same ground unless additional components are used, and wires must be short.
- SPI – Raspberry Pi and Arduino supports SPI easily at frequencies up to 42 MHz.
Devises must share the same ground unless additional components are used, and wires must be short.
- Ethernet – Raspberry Pi supports 100Mb/s network natively, but most Arduino require a an extension to support Ethernet. Arduino Ethernet extensions are connected using SPI, so it will not go any faster than the SPI bus.
To select the correct technology the following must be considered:
- Is the transfer speed high enough, so that we plenty of available CPU time to actually collect the sensor readings? Do we have to tweak the implementation or use non standard settings to achieve the necessary transfer speed?
- It is required that the platform must support many interconnected devices to support scaling the sensor platform.
- Does the technology support powering the different components using isolated power sources? We may for practical reasons want to use different batteries for the different hardware components.
So how does the different technology rate:
- UART – It may be possible to achieve the necessary transfer speed with some tweaking, but Raspberry Pi only supports a single UART pair (RX/TX), which makes it difficult for it to act as a controller connected to many different Arduinos.
- I2C + SPI – Two different master/slave bus implementations. For both buses the master must initiate the communication on both read and writes. Sensor hardware would therefore not be able to stream data to the controller/master, because the master must request every single read from the slave.
This will make it difficult to achieve fast enough data transfer from the slaves to the master, and the implementation will be complex.
- Ethernet – There are very good support for Ethernet communication on both Arduino and Raspberry Pi. The Arduino have high enough transfer speed with UDP to send sensor data in real time, and the Raspberry Pi has high enough receive speed to process data streams from multiple Arduino.
Wiring is simple, cables can be long and interconnection of many devices are simple using network switches.
For simplicity and scalability the choice of communication technology is therefore simple. Ethernet will be used for transfer of sensor data using UDP.
To ensure plenty of CPU power and a scalable platform Arduino Due and Raspberry Pi 2 will be used. Arduino Due will be connected to the sensors and stream sensor data in real time to the Sensor Controller hosted on a Raspberry Pi 2. The Sensor Controller will show the data on a local LCD, record it to local storage and stream it in real time to the operator.
The architecture design therefore looks like:
The W5200 Ethernet chip is used from WIZnet, which is new and much faster than the W5100 model being used in the standard Ethernet boards for Arduino.
The W5200 chip is available in a nice module WIZ820IO that combines the Ethernet plug with the chip, pins etc. for easy mounting.
In the next post we will look at the initial wiring of the WIZ820IO to the Arduino Due and initial tests.
The first generation of the Sensor Controller platform was built nearly a year ago, and have already been used in over 20 rocket engine static tests by Raketmadsens Rumlaboratorium with success.
In the summer 2014 Raketmadsens Rumlaboratorium was founded by Peter Madsen, and he urgently need a platform for collecting sensor data from his static rocket tests.
As development of the platform had to be quickly completed, and performance requirements were not so high, the phidgets hardware platform was selected as the foundation.
The brain of the platform was the Phidgets SBC (Single Board Computer). Running Debian OS it allowed the controller software to be written in C# using mono and interface directly with the sensor hardware.
The Phidgets SBC has integrated analog inputs 0-5V with 10bit resolution, which enables standard pressure sensors with 0-5V output signal to be connected directly.
The used pressure sensors needs minimum 6-7V for correct operation, and Phidgets SBC only outputs 5V through the plugs used for analog sensor. So either the analog sensor had to be powered from another power source than the SBC or a 12V Analog adapter from Phidgets must be used.
The adapter was used, which converts the SBC 5V to 12V.
For measuring thrust a load cell from Vetek rated at 10ton was used. This would enable measurement of thrust up to approximate 100.000 newton.
The challenge with a load cell is the very low volt signal it outputs. Most load cells output a analog signal measured in mV/V. The used load cell was rated a 3,00 mV/V meaning given a input voltage of 5V it would output 15 mV at full load and 7,5 mV at half load (5 ton).
At 10 bit resolution the lowest value the SBC can measure is 0,0049V = 4,9 mV giving a resolution of approx. 3,2 ton. 12bit AD resolution would give a measurement resolution of approx. 814 kg.
A “normal” AD converter can therefore not be used, because a very high sample resolution is required to get any meaning full data from the load cell.
A Phidgets 24bit AD was selected with in theory could give a resolution of 0,0005 kg using a gain of 64. In real life noise makes it very difficult to measure so precisely, but with a large average over 50-100 measurements, a precision of 0,0010 kg can be achieved.
As mentioned the platform has been used with success for many tests, but it has it’s limitations. The CPU of the SBC is slow, and the SBC platform does not natively support sampling at higher frequency than 125 Hz. The result is that a single SBC has difficulties real time streaming of data from more than 2-3 sensors simultaneous, and it really can’t go above 125 Hz.
You may think that 125 Hz must be high enough, but there has been several tests at Raketmadsens Rumlaboratorium with ignition spikes, where the “lower” sample rate made it difficult to know exactly how high the pressure spike was. Higher sample rate is also important to identify any high frequency oscillations.
A new Sensor Controller platform is therefore under development based upon Raspberry Pi 2 and Arduino Due. The goal is to support 1000 Hz sampling on 10 sensors or more including real time streaming of data to command central and live stream. The resolution of the pressure sampling will also be increased from 10bit to 12bit giving 4 times higher solutions.
Stay tuned and follow the progress and the reference hardware platform is build, and the software is designed.
KB Rocket Solutions now has a homepage!
I will in the coming period be adding content about previous and current activities so stay tuned.
Currently a new sensor platform is in development based upon Raspberry Pi 2 and Arduino Due support sampling at 1000 Hz.
Details will later follow about the flight and guidance simulator under development to help test different guidance / navigation algorithms under different conditions and configurations.