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 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?
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.
(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 gets FIFO messages, it broadcasts them on the network.
See also: GroundSupport
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.
See also: FlightComputerStateFlowSep2003
See also: GlobalPositioningSystem
See also: LvTwoAmateurTelevisionOverview
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.
Nitty-gritty details on how to develop, test, and install the flight computer software.
There are a number of tools available for testing components of the flight computer software.
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.]
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
ltc-fc-common/net_common.h for the default address and port assignments.
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).
Installation on the FlightComputer
Next, copy new components to the flight computer (ask one of the team members for the password):
scp run_threads firstname.lastname@example.org:
scp can.o email@example.com:
Then login to the flight computer as root:
Shutdown the software and run the new stuff.
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
There is a seperate page for development of the CanBusLinuxDriver,