EmbeddedRocketComputer

Embedded computer: attitude and mission control, telemetry

The embedded computer is a major part of a launcher, because of the development and testing time it requires, and because a simple unforeseen case can lead the whole operation to failure.

The embedded computing world undergoes lots of constraints: power consumption, size, weight, heat and operating temperature... On the other hand, it must have a low latency to process the attitude control loop (read data from attitude sensors and command the actuators). Realtime computing is a standard for microcontroller-based systems, which do not feature an operating system overlay, but it can be more complicated to have deadline guarantees when an OS is used, on PC-based boards. In that case, a hard-realtime operating system must be used, unless you are willing to replace it with your sole process and manage all I/O yourself.

The high altitude and space environments are also raise the problem of radiation. For electronic systems, there are mainly two issues: bit flip or component burning because of radiation and sparking because of potential differences on sun-facing and opposite external faces of a satellite's structure. The space radiation environment is thoroughly described on this DYI Space Exploration page, based on a NASA report. Many techniques exist against radiation, both physical with radiation-hardened electronics and with software features like redundancy.

Hardware

It's obviously hard to have a low cost, small form factor, with high processing power. But do we really need high power? That depends on what sensors are used, and the processing power they require. Beyond that, we only need to get the command control, mission planning and telemetry, which don't require a high power.

Since we are limited by cost, we won't be able to get high quality sensors, or highly integrated sensors like an inertial sensor, but rather accelerometers, and digital gyroscopes. Their data will need to be processed, but that still does not require a lot of power. If we use a video camera however, to track the sun and the Earth's curvature for attitude sensing, it will require a lot more processing power.

High processing power

An alternative to pure processing power by a CPU exists: digital signal processors (DSPs), and since they are also very expensive, we can use FPGAs to program them. An FPGA (Field-Programmable Gate Array) is an electronic chip with a matrix of gates that can be programmed in order to specialize it to a specific information processing. It then acts as a hardware processing based on a software definition of the processing, offloading the CPU. Information about FPGAs can be found at fpga4fun.com.

And it happens that there is an embedded microprocessor board that includes a FPGA and multiple I/Os, and a quite faire processing power: the Armadeus, based on an ARM (FreeScale) processor. Moreover, it supports the free (GPL) Xenomai Linux-based RTOS. Armadeus board integration has a dedicated page.

Other interesting embedded computer boards: the Eddy-CPU v2.1, Portux G20 and the BeagleBoard. They do not include a FPGA but are cheaper, the first has a great temperature range, the second is more powerful and smaller, and the third is cheap, open and has a large community.

Low processing power

If video is not used as a sensor, microcontrollers may be able to handle some sensors and actuators, at least for aircraft control. The ArduPilot is a good example of open project trying to achieve that. Other Arduino-based initiatives have appeared. For example, the Rocket Mega shield features a fast GPS chip, XBee telemetry, MicroSD card, pressure/altitude sensor, gyroscope and accelerometers.

A few other microcontroller boards have recently received some attention, like the GravityBoard. It is more powerful than Arduinos, features high-power outputs, uses space-tolerant hardware.

Telemetry/Communications

Main article: Telemetry

From what is explained on SparkFun's XBee guide, the 900MHz low data rate (10kbps) version of XBee is able to transmit up to a range of 24km (15 miles), when using a high gain antenna. Also see the ArduPilot telemetry page.

Two Xbee modules for wireless telemetry: This one with this adapter in the air and this one with this antenna and this adapter board.

Very High Data Rate Transmitter in X-Band for CubeSat: This X-Band transmitter can transmit up to 13.3 GB per pass with a 5 meter station.

"I have since discovered that the transmitters in these balloons are only 10mW, but because of the line of sight they can manage several hundred miles", in 434MHz band, from Radio Antics.

Sensors

Before creating a new dedicated Sensors page because it takes too much space here, here is a list of sensors that can or should be used:

• Accelerometers: nowadays common, accelerometers allow attitude sensing, together with gyroscopes or/and magnetometers. For our project, a single-axis accelerometer can be used to detect free-fall created by separation of plane and rocket, and to sense the roll movement of the rocket, at least for the first part of the flight, since Earth gravity will be more or less sensed depending on the roll. A second accelerometer could be used for thrust confirmation, collinear to the length of the rocket. It would also be a nice telemetry feature, and provide a feedback on the stress the structure has to sustain. To chose a sensor, sparkfun wrote an accelerometer tutorial.
• Gyroscopes: they can obviously be helpful on attitude sensing, for yaw roll and pitch of the plane, and thus for the control command. To chose a sensor, sparkfun wrote a gyroscope tutorial. However, those sensors can be relatively expensive for a decent precision, and might be replaced by a camera sensor for low rotation rates.
• Magnetometer (3D compass): lots of sensors exist too, for example the MicroMag and SCP1000, but are quite expensive. Knowing where is the North of Earth can be very useful, in order to corroborate information from the camera or other sensors, and add some precision to the orbital injection parameters.
• Static pressure sensor, like Freescale's MP3H6115A and another for the extended range of high-altitude. Small and very sensitive sensors are appearing, like the BMP085. The pressure sensor requires vents, or static ports, in the fuselage to exchange outside air with inside pressure chamber. Details about the size and number of these ports are explained here for model rocketry.
• Thermometer: for systems health monitoring, like engines temperature.
• GPS: sensors have an altitude limitation due to USAF export regulation, but some unlimited chips can easily be found. 10Hz refresh rate can be obtained for relatively cheap ($30), like the MTK3339.
• Camera: 8-bit data port if possible, like the TCM8230MD sensor. Some ARM processors (i.MX) feature the Camera/CMOS Sensor Interface (CSI) and hardware-accelerated processing or compression from this port. Horizon sensor is provided by a camera.
• Pitot tubes even exist in stores (like DIYDrones)!
• Fuel gauge or low level indicator and thus end of mission, orbital injection parameters freezing and stating.

For the rocket in particular, a pressure sensor is needed for the rocket engine. It is both used to verify that everything is working fine, and it allows the thrust to be computed in flight. As said on arocket: I'm convinced that if you have a good chamber pressure transducer, know the throat diameter, and have good estimates of thrust coefficient, it's probably more accurate than directly measuring thrust from a load cell.

Software

First thing about software is always thinking about the model of the application, meaning how will it be conceived or organized. Several layers are generally seen in softwares:

• Real application: mission
  • Keep track of the status in the mission
  • Send orders (commands) to the control layer
• Control system
  • Sensors and actuator communication and processing
  • Control loop from sensors to actuators regarding to commands
• Operating system
• Hardware

Mission: the launch program

We need to chose a way to express and manage the mission. It is defined by actions to trigger when some conditions are met, like "when altitude is 60km, proceed to staging", or "at T+7s, begin roll program".

Control

The control loop's purpose is to ensure that the vehicle is in a state consistent with the state expected by the mission. It controls attitude (roll, pitch, yaw) of the vehicle in order to make it fit with the expected attitude. In our case, roll is not really a concern for the rocket, since the satellite does not carry important science payload that has to be pointed in a particular direction. For the aircraft, on the other side, it is very important.

A control loop is decomposed like that:

picture

Sensors information is collected and processed. Actuator commands are processed from both sensor data and expected-to-be-reached sensor data (nominal flight pattern).

This loop has to be processed several times per second, with a highly accurate timing. Indeed, sensor processing, for example accelerometer data, has to be integrated to know the speed and the position of the vehicle. If time shifts randomly, calculated speed will not be correct, leading to false actuation command. With no luck, and we have to assume that it is the case, that creates real attitude error while it was not previously bad. If error is too important on pitch for example, it can lead to catastrophic structural damage at such high speeds.

Hard realtime operating systems (RTOS) guarantee that the time between expected processing time and actual processing time (the system's latency) is bounded by a very low maximum value.

Failsafe, mission abort

In case something goes wrong, for example and engine failure, or structural failure, if it can be detected by sensors, the systems will have to go into a failsafe mode - basically shutting down everything that can explode and try to return to ground in the minimum of different parts. Options are explored on the mission page.

In some cases, the mission will need to be aborted from ground, because no sensor was available for a specific task, or because of a programming error. An upload communication would then be needed, allowing the system to cease its mission, and try to go back in one piece.