psas/av3-fc

Event driven flight computer for rockets. Flown on L-10 and L-11.

av3-fc's Issues

Implement Roll Servo Test

In the previous iteration the roll control algorithm wiggled the fins back and forth at start up.

We should do something like this as a command.

Test And Configure Telemetry Using Broadcast Packets

How do we get WiFI data in the test setup (rocket cart)? If not built with flight tags can we then also pipe the data over the wire network? That way a laptop plugged into the rocket cart can debug/watch data over the wire rather than setting up wireless.

Handle RNH data

The RNH will be generating launch detect and a bunch of information about power use and batteries. The FCF should be equipped to deal with this.

FC packets have different timestamp than ethernet packets

In the Launch-12 log, the VERS, SEQN, ROLL, and MESG packets had a different timestamp base (about 0x2EFF3C4, but possibly just 0) than packets coming in over ethernet (about 0x6824606CA712). These four messages are generated by the flight computer, and thus had timestamps originating from clock_gettime(CLOCK_MONOTONIC), whereas ethernet messages obtained the timestamp from the SO_TIMESTAMPNS metadata of incoming recvmsg() packets. We open the socket with setsockopt(s, SOL_SOCKET, SO_TIMESTAMPNS, ...), however according to documentation I found, the sub-options of SOF_TIMESTAMPING_RX_HARDWARE | SOF_TIMESTAMPING_RX_SOFTWARE | SOF_TIMESTAMPING_SYS_HARDWARE are only used if we instead choose socket option SO_TIMESTAMPING. And in any case apparently none of these use the same time-base as CLOCK_MONOTONIC; they either use standard system time or an ethernet card clock.

Also, since these were on different time bases, our policy of subtracting a monotonic start time from the ethernet packet timestamp in to_psas_time() was probably useless.

Rename repo

The FCF isn't actually specific to AV3. The name should reflect that.

Roll control needs a timeout

And possibly apogee detect, so that the roll system doesn't stay on during decent and more importantly the ground.

Investigate Real Time Kernel Patch

How much can we guarantee latency?

Implement Roll Control

Need to recreate a roll control implementation for the FCF.

Revisions on README.md

Found some spelling and grammar issues.

SEQN messages need the actual timestamp

See line 142 of logger.c: message_header header = { .ID="SEQN", .timestamp={0,0,0,0,0,0}, .data_length=htons(4) };

.timesamp shouldn't be all 0s.

Receive error messages from RocketNet devices

RocketNet devices will implement separate error sockets to send errors to the flight computer. The FC should know what to do with this.

Is this project still active?

I'm going through the list of projects on the PSAS website, making a list of the active/old projects. Is this still a thing? Is it going on LV3? It hasn't been pushed to in like 2 years.

Fix Venus 8 GPS binary message processing

Old Venus 6 structures (for message A8) had elements that were all two times too large, so it was obviously untested. Write code to split and verify GPS binary packets. Message tags are of form V8xx, where xx is the Venus hex packet ID.

Fix psas_packet and telemetry viewer to match.

Limit when to record GPS data

GPS generates a lot of data, we only really care about it during launch. We should have some way of limiting the recording of it, for example only recording when the FC is armed.

Get FC operating info

We should at least collect CPU temperature data, are there other things that we want? This should be a module in the FCF.

Turn Off Fins After ~45 Seconds Of Flight Time

The Servo should turn off after the flight. The ascent can never be longer than 45 seconds.

Refactor utils_sockets

They do strange things and could use a rewrite.

Method To Fin Test For Sanity

How do we test that the fin servo comes on successfully in the field?

Handle PSAS Data type sequence counters

All PSAS Data types now have sequence counters to indicate things like UDP packet loss. The FCF should know what to do with them.

Launch Detect From IMU

We're unlikely to have hardware launch detect, so it needs to be implemented as looking for high g's while in ARM state.

If g > threshold and ARM == true, then 'launch detect'

We expect threshold to be around 4 g 'up'. No debounce.

Debug: There also needs to be a debug backdoor to trigger it for testing.