EmbeddedRocketComputer

Embedded computer: guidance, mission, and telemetry

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

The embedded computing world undergoes lots of constraints: power consumption, size, weight, operating temperature... Outcomes are seen in processing power, memory space, connectivity (I/O ports), battery life, and mechanical design.

An embedded control computer has to have a low latency to process data from attitude sensors and command actuators. Realtime computing must be achieved through a hard-realtime operating system, or without using an operating system if you have only one process.

Hardware

It's 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 their processing. Beyond that, we only need to get the command control, mission planning, and telemetry, that 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 intertial 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 curve for positionning, it will require a lot of processing power.

An alternative to pure processing power by a CPU is possible: 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 chipset 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.

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.