Software Meeting 07/01/2003

Attendees:

IanOsgood, Tim, ?TrevorElliott, ?LarryLeach, ?JamesPerkins, ?KatharineXiong, ?JameySharp

*Action Items:*%ACTION{ who="Main.TrevorElliott" due="Tue, 8 Jul 2003" state="closed" }% CAN Bus node id generation (done, but can't put into cvs)

Serial cables for LTC, FC:

CAN Analyzer:

?LarryLeach has set up http://cantalope.sourceforge.net for the Serial to CAN analyzer open source project, this is part of a class project. ?MarkusWeltin will be doing the hardware part, and AndrewGreenberg has already written and contributed specifications.

OMSI's Space Days:

Recovery Node:

Tim is working on it. Boards go out tomorrow, yay!
Tim now has a development laptop, finally.
?LarryLeach observes that rolling feature freeze, with avionics nodes done sooner, woudl be optimal for FC software team. This is truly the best of all possible worlds!

GPL-GPS:

Tim has been doing lots of work on this, saved $5000.00 of work in one all-nighter.

CAN bus IDs from nodes:

AndrewGreenberg was discussing a common sharing of source code for IDs across all computer languages.
Each node's export.h is probably crunchable into a standard.
Need to get state machines of FC, LTC, and LCC worked out.
?JameySharp says he already wrote this, it's in m4, and a single file is translated into the various header files. Apparently this idea needs to be upgraded to produce the four-level namespace that Andrew came up with for the avionics CAN nodes.
Jamey says that the C code that is being produced is somehow incompatible with Andrew's compiler... notably the trailing comma at the last enum item.
This is a todo for ?JamesPerkins
Tim described that the current structure of CAN message IDs looks something like:

* Tonight's agenda:*

Flight Computer:

?JamesPerkins is trying to collapse all the various instances of TWiki State machines into one
James is also getting automated start up working and clean CAN-oriented shutdown.

Recovery Node:

Tim described a state model as follows
- Safe - can work around it, even powered up, handling pyrotechnics is safe
- Ready - sitting on Pad, want to test things, charge batteries, do not handle pyrotechnics.
- Armed - running countdown timer prior to firing, fires for a while, tries to see that they've fired and for long enough (probably multistate). Have to get out of state to stop the timer, it's always running.
- Done - as safe as safe, but you have to command it back to safe to go on.
Tim lists a list of things
- Timers set
- Real Time set
- Verifies:
- High Voltage exists
- Firing Circuits are OK
- Battery is OK
- Become Arm state makes armed timer start running
- How do we get status during arm state?
- Timers are supposed to be set for "it's darn well time we do X by now"
- Can accept "fire right now" when in Armed state
- Can generate message "I'm shorted out"

Parking Lot for good ideas:

State Model Observation:

Sequencer Discussion:

Had a long discussion about the Sequencer, looked at the existing code.
James noted that each state could have an enter method, leave method, and message recieved method. Probably the message recieved method returns a new state, and if a new state is returned, then the leave and enter methods get called.
James was speaking like the sequencer sees all, computes all, does all. Larry thought that every state change decision came from elsewhere (probably SMART). James claimed foggy thinking, but then realized that SMART is supposed to be able to decode and interpret physical information, apply Kalman filter, and issue actuator commands. As a side effect SMART can provide useful info like: launch detect, boost detect, burnout detect, apogee detect, etc. Clearly a lot of complexity will remain in sequencer.
SMART is Mr. Spock, Sequencer is Captain Kirk.
Possibly each state in sequencer deserves its own source code file e.g. seq_boosting.c
THere is a common system state respository that will be useful to all sequencer states, indicating for example counts of Z velocity positive, pressure sensor data, etc. Will need to figure this out???
See FlightComputerStateFlowSep2003

CAN bus Timer

January 1 2000 Zulu date -d 'Jam 1 2000 utc' '+%s' or 946684800
Tim suggests 32 bits of seconds, 16 bits of subseconds?
James suggests Linux 100Hz clock for 7 of those 16 bits.
Tim says why not set RTC for 1kHz or more without interrupt.
James fairly sure he read you get an interrupt on every count -oy-. Maximum rate is 8kHz (8192 s^-1).

-- ?JamesPerkins - 01 Jul 2003