sfwa / fcs Goto Github PK

The CDCE62002 should be programmed with the following configuration:

REGISTERS
0   55200080
1   8389A061
2   00000002

The result should be a 150MHz LVDS clock signal to the DSP.

The latest packet value should be stored in shared memory, such that it can be parsed to initialize the UKF on restart.

Without control input, having no dynamics model at all yields better results. See if there's a static control input value that will improve that, otherwise look at re-integrating control input monitoring when under manual control (failsafe device to I/O board aux?).

Add a triggerable calibration mode (exited automatically if gyro or accelerometer readings exceed a certain threshold) which determines a baseline gyro bias value (assuming vehicle is stationary) and then runs TRICAL on the accelerometers and magnetometers.

Also work out relative orientations of each sensor — maybe UKF with 3x orientation quaternions and angle between magnetic field and gravity vectors as the measurement model?

Enforce a minimum attitude angle between successive magnetometer calibration updates to prevent gyro drift resulting in magnetometer orientation calibration change over time in static use.

The last I/O board recordings use a different packet format, so they'll need to be converted to use the new one (including accelerometer readings divided by 2). Take a ~2 minute sample and store the data in the test directory so accuracy tests can be included in the unittest script.

The AHRS loop will need the facility to read I/O board streams from files rather than the UART buffers via DMA, as well as the facility to output state packets to a file/stdout.

During calibration mode, the pitot and barometric pressure sensor bias should be estimated.

If more than 2ms have elapsed since the last sensor packet, and more than 100ms have elapsed since the last reset, the I/O board reset line should be asserted.

This needs to be updated in the CPLD bitstream as well as ahrs.c.

Python script that interfaces with a main.c-less library version of fcs. On startup calls the various init functions (single-process/single-core), then enters the main loop and calls the tick functions each timestep.

All I/O goes through stubbed versions of the serial drivers, so each of the four streams has its own independent input buffer and output buffer. Bytes are read whenever there's space in the stream read buffer, and written whenever there are bytes available in the stream output buffer.

Should support multiplexed I/O on stdin/stdout (Python string literals?), as well as raw binary file I/O per stream (4 input files / 4 output files).

Look into comparing current measurements against the measurements predicted by the UKF, and see if statistical tests can be used to identify and reset/ignore malfunctioning sensors.

Support path management commands over the CPU or comms links.

The parser has issues when dealing with a mixed RFD900/GCS status stream. Move to an integrated state machine driven approach.

http://docs.swift-nav.com/wiki/SBP
https://github.com/swift-nav/piksi_firmware/blob/master/src/sbp.c
https://github.com/swift-nav/piksi_firmware/blob/master/src/sbp_messages.h

Add a comms packet type to support sensor calibration updates. Also consider ack/confirmation approach.

Parse GCS packets and use the altitude and pressure to calibrate the on-board barometric pressure sensors.

Should be 0V, currently 0.5-0.8V.

See http://malcolmdshuster.com/Pub_2002a_J_TWOSTEP_scan.pdf

Should be used to determine magnetometer bias (3-vector) and scale (3x3 matrix).

EVM6657 uses CCS to write program data to DDR3, then copies it to the NOR.

Compare that approach with writes from the CPU (Linux), plus whatever TI tools are required.

Also investigate SPI boot configuration tables and determine best way to generate these.

It's possible to get a valid deserialization result from a packet containing out-of-range values which, if serialized, would result in assertion failure.

Avoid this possibility by restricting deserialized field values to the same range required by serialization. Any packet with field values outside the valid range will result in an FCS_DESERIALIZATION_ERROR.

GCS packets should be transferred to CPU and vice versa. If no packet is received from the CPU in > 1s, display a warning.