...
PICPilot Path management can be mostly ported over
Issue: single-threaded, which made it really messy and hard to follow
FreeRTOS should be used to create separate threads
Have a particular fn (function), assign a thread to that fn w/ infinite while loop
Issue: Cannot run FreeRTOS on PC
Should be able to unit test each individual thread - abstract everything into higher level fns and test those higher lvl fns. FreeRTOS should provide stubs to those fns
Initial Idea: 2 threads for state machine (Attitude/Path), 1 thread for managing coms, subthreads for each sensor
Sensor thread will update its results automatically
Only thing to worry abt is data syncing
Another thread for managing the coms
Ex: GPS thread fires off every 100 ms, IMU fires off every __ ms
Telemetry thread:
Downlink/Uplink thread?
Could pick up Battery voltage/current measurements
PICPilot telemetry code is one of the more complicated ones - avoid heap allocations on an embedded system
MavLink option: Use standardized protocol so that anything can act as Grounstation. Would require changes to the way data is packaged.
SensorInterface:
Have sensor status report back to groundstation on bootup so that everything is working before flying
Sensor struct should include timestamp field to determine how new data is - or include sensor cound
For future debugging:
Unit Testing:
Works on MAC, Linux, Window subsystem for Linux
Getting it to run on Windows could make it more accessible for future recruits
Get TRAVIS to run everything on Windows as well
...
- Hide CV Bootcamp + inform interested CV recruits that there are on their own
- Update design architecture docs - upload them onto Confluence
- Push Unit Test framework to devel branch