summaryrefslogtreecommitdiff
path: root/FlightComputerSoftware.mdwn
blob: 6e6735a507b2788c000d83219c588201b26e9fa6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
# <a name="Flight Computer Software"></a> Flight Computer Software

## <a name="Overview"></a> 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.

<map name="fcfifo-components">
</map>

<area alt="gps" coords="57,208,129,256" href="http://cvs.psas.pdx.edu/c/fcfifo/gps.c?rev=HEAD" shape="rect" title="gps">
<area alt="gps" coords="113,304,185,352" href="http://cvs.psas.pdx.edu/c/fcfifo/gps.c?rev=HEAD" shape="rect" title="gps">
<area alt="buffer" coords="231,592,319,680" href="http://cvs.psas.pdx.edu/c/fcfifo/buffer.c?rev=HEAD" shape="rect" title="buffer">
<area alt="nodes" coords="153,208,225,256" href="http://cvs.psas.pdx.edu/c/fcfifo/nodes.c?rev=HEAD" shape="rect" title="nodes">
<area alt="nodes" coords="201,400,273,448" href="http://cvs.psas.pdx.edu/c/fcfifo/nodes.c?rev=HEAD" shape="rect" title="nodes">
<area alt="can_wtr" coords="349,496,437,544" href="http://cvs.psas.pdx.edu/c/fcfifo/can_rw.c?rev=HEAD" shape="rect" title="can_wtr">
<area alt="can_rdr" coords="159,16,244,64" href="http://cvs.psas.pdx.edu/c/fcfifo/can_rw.c?rev=HEAD" shape="rect" title="can_rdr">
<area alt="dispatch" coords="336,112,427,160" href="http://cvs.psas.pdx.edu/c/fcfifo/dispatch.c?rev=HEAD" shape="rect" title="dispatch">
<area alt="sequencer" coords="556,208,657,256" href="http://cvs.psas.pdx.edu/c/fcfifo/sequencer.c?rev=HEAD" shape="rect" title="sequencer">
<area alt="sequencer" coords="455,304,556,352" href="http://cvs.psas.pdx.edu/c/fcfifo/sequencer.c?rev=HEAD" shape="rect" title="sequencer">
<area alt="report_state" coords="395,400,512,448" href="http://cvs.psas.pdx.edu/c/fcfifo/report_state.c?rev=HEAD" shape="rect" title="report_state">
<area alt="atv" coords="299,400,371,448" href="http://cvs.psas.pdx.edu/c/fcfifo/atv.c?rev=HEAD" shape="rect" title="atv">
<area alt="imu_can_rdr" coords="728,16,851,64" href="http://cvs.psas.pdx.edu/c/fcfifo/imu.c?rev=HEAD" shape="rect" title="imu_can_rdr">
<area alt="imu" coords="681,208,753,256" href="http://cvs.psas.pdx.edu/c/fcfifo/imu.c?rev=HEAD" shape="rect" title="imu">
<area alt="logger" coords="188,728,263,776" href="http://cvs.psas.pdx.edu/c/fcfifo/logger.c?rev=HEAD" shape="rect" title="logger">
<area alt="fc2net" coords="287,728,361,776" href="http://cvs.psas.pdx.edu/c/fcfifo/fc2net.c?rev=HEAD" shape="rect" title="fc2net">
<area alt="net2fc" coords="489,16,561,64" href="http://cvs.psas.pdx.edu/c/fcfifo/net2fc.c?rev=HEAD" shape="rect" title="net2fc">
<area alt="pressure" coords="441,208,532,256" href="http://cvs.psas.pdx.edu/c/fcfifo/pressure.c?rev=HEAD" shape="rect" title="pressure">
<area alt="rec" coords="249,208,321,256" href="http://cvs.psas.pdx.edu/c/fcfifo/rec.c?rev=HEAD" shape="rect" title="rec">
<area alt="aps" coords="345,208,417,256" href="http://cvs.psas.pdx.edu/c/fcfifo/aps.c?rev=HEAD" shape="rect" title="aps">

[[fcfifo-components.png]]

See [[BlackboardArchitecture]] for more.

### <a name="run_threads (the thread manager)"></a> 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?

### <a name="can_rw"></a> 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|FlightComputerSoftware#dispatch]] and [[fc2net|FlightComputerSoftware#fc2net_net2fc]].

(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?)

### <a name="fc2net/net2fc"></a> 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|FlightComputerSoftware#dispatch]] and [[can_rw|FlightComputerSoftware#can_rw]].

See also: [[GroundSupport]]

### <a name="dispatch"></a> 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.

### <a name="sequencer"></a> sequencer

See also: [[FlightComputerStateFlowSep2003]]

### <a name="gps"></a> gps

See also: [[GlobalPositioningSystem]]

### <a name="pressure"></a> pressure

See also: [[RocketScience#The_Atmosphere]], [[RocketScience#Aerodynamics]]

### <a name="atv"></a> atv

See also: [[LvTwoAmateurTelevisionOverview]]

### <a name="logger"></a> 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.

## <a name="Development"></a> Development

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

### <a name="Testing"></a> Testing

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

#### <a name="Simulating the FC"></a> Simulating the FC

See [[DevelopmentEnvironmentForLv2#Simulating_the_FC]].

#### <a name="TestCanIn"></a><a name="_TestCanIn"></a> 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.]

#### <a name="TestNetRecv/_TestNetSend"></a><a name="_TestNetRecv/_TestNetSend"></a> 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.

#### <a name="RocketView"></a><a name="_RocketView"></a> 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).

#### <a name="CANtalope"></a> CANtalope

See [[CantalopeSoftware]] and [[DevelopmentEnvironmentForLv2]].

### <a name="Installation on the _FlightCompu"></a> 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:

- [[data-flow-diagram.dia]]
- [[fc.dia]]