Flight Computer Software

Overview

This page will attempt to explain what the heck is going on software wise inside the FlightComputer (FC) and why.

The FlightComputer is collection of POSIX threads ("pthreads") all happily working together. For general information on pthreads, see the Debian package glibc-doc and search the net for 'pthreads'. Previously we had a collection of processes running; the difference is that all threads run in a shared memory area and all processes run in their own areas. This both good and bad: bad because one thread can kill everything, good because threads can efficiently communicate in shared memory (it makes inter-thread communication much easier).

For those who were used to the old architecture, never fear. Each of the old processes is now a thread, and they still mainly communicate via fifos as before. The overall structure of the design remains the same, but it is now easier to share large data structures between tasks.

See BlackboardArchitecture for more.

run_threads (the thread manager)

run_threads is the process that starts up and starts up all the appropriate threads. run_threads is usually started by the pre-flight-boot init script, unless the system reboots during flight, in which case run_threads will be started with the '-recovery' argument by the in-flight-reboot init script.

If a thread dies, it has been proposed that run_threads should restart that thread, possibly giving up after some number of restarts. Implementing this behavior is easy, but careful thought is required on the state that the thread should restart into.

If any thread causes a signal to be delivered to it, and the behavior of the signal is terminate, all of the threads will die. Doing better is likely to be hard under the 2.4 kernel and LinuxThreads. Just don't get any segfaults, OK?

can_rw

All of our sensors and actuators are hanging off the CAN bus. So we obviously need a CAN driver. We're using our own CAN driver called uncanny which is specifically for the broken, screwed up and almost unuseable Intel 82527. Not that we're opinionated.

can_rw opens uncanny for reading and writing. When it gets FIFO messages, it passes them on to uncanny; when it recieves CAN messages, it passes them to dispatch and fc2net.

(Now that we're in one process, we should split this into can_rdr and can_wtr threads again for a cleaner design. Ideally, uncanny will allow its device to be opened twice, as long as one open is read-only and the other is write-only. In fact, allowing multiple writers ought to not be very hard, right?)

fc2net/net2fc

When fc2net gets FIFO messages, it broadcasts them on the network.

When net2fc recieves messages from the network, it passes them to dispatch and can rw.

dispatch

A very simple thread that takes every FIFO message that it recieves and re-sends it to all FIFOs in its list. That list is presently hard-coded in an array.

If desired, dispatch could filter the messages that it sends, to avoid waking up threads that don't care about the current message.

If desired, dispatch could place messages on the blackboard.

sequencer

gps

pressure

atv

logger

Logs all FIFO messages that it receives. At present it writes them to /tmp/fcfifolog. At present /tmp is a tmpfs, a sort of RAM disk, as I recall. At present this needs some work.

Development

Nitty-gritty details on how to develop, test, and install the flight computer software.

Testing

There are a number of tools available for testing components of the flight computer software.

Simulating the FC

See DevelopmentEnvironmentForLv2.

TestCanIn

TestCanIn is used to send a stream of data to a fifo to simulate CAN messages.

 TestCanIn fifo < fake_data.txt

where data contains lines in the same format as TestNetSend, except prefixed by a time parameter (can be set to 0 for now). [A nice future enhancement would be to use the time parameter to send the messages at repeatable intervals instead of streamed as fast as possible.]

TestNetRecv/TestNetSend

These each print a usage string if given an unknown parameter.

TestNetSend is used to send a single UDP CAN message to the network. Aside from the optional address and port parameters, you specify in order (in decimal):

11-bit CAN id (0-7ff)
RTR bit (0-1)
data length (0-8)
0-8 data bytes (0-255)

TestNetSend -r 255.255.255.255 -q 4443 123 0 3 10 20 30

TestNetRecv is used to listen to all UDP FIFO messages sent to a particular port.

 TestNetRecv -p 4441

See ltc-fc-common/net_common.h for the default address and port assignments.

RocketView

The Java app RocketView will display all messages broadcast on the network, including those sent from a real or simulated flight computer. Messages from particular subsystems are formatted as graphs (IMU) or user-friendly values and states (FC state, GPS).

CANtalope

See CantalopeSoftware and DevelopmentEnvironmentForLv2.

Installation on the FlightComputer

First, reconfigure your network to talk to the FlightComputer (see OrinocoWirelessSetup).

Next, copy new components to the flight computer (ask one of the team members for the password):

 scp run_threads root@10.0.0.1:
 scp can.o root@10.0.0.1:

Then login to the flight computer as root:

 ssh root@10.0.0.1

Shutdown the software and run the new stuff.

 killall manager
 killall run_threads
 rmmod can

 insmod ./can.o
 ./run_threads

Test away. (For debugging CAN driver problems, it is often useful to see the CAN driver debug messages on the serial console. Use minicom or some other terminal program to connect to the flight computer's serial console. The serial parameters are 9600-8N1. Be careful to plug the serial cable on the right way! The red wire should be closest to the edge of the motherboard. See FlightComputer for pictures.)

If it works to your satisfaction, back up the old stuff and install the new stuff, so that it will be invoked on the next reboot.

 mv fcfifo/run_threads runthreads.bak
 mv run_threads fcfifo

 mv /lib/modules/2.4.18/misc/can.o can.bak
 mv can.o /lib/modules/2.4.18/misc

For full configuration of the FlightComputer, see FlightComputerSoftware2002.

There is a seperate page for development of the CanBusLinuxDriver, uncanny.

orphans: RealTimeLinux

Attachments: