A list of things to work on after the competition. If there's something we have to compromise on or do not have time to do before the competition, put it here.
Please use HEADER 2 for the task titles so we can distinguish easily :))
Documents to Write
Document | Assigned To |
---|---|
SensorFusion explain the position algorithm. This should include a rundown of the math, key variables, etc. The goal is someone 2-3 years from now can pick this up and have enough context to understand the module. If not done already, also write something for the Mahoney algorithm. | Tony |
Airside Mavlink functions: While the design is incredibly intelligent, it is difficult to understand to the uninitiated. Having some documentation that can serve as an introduction to the functions will be helpful. The documents should: explain the functions, how to implemenet them, introduce key variables/structs/enums, etc. | Jingting Dhruv R (Provide examples for implementation) |
Groundstation (Similar to airside mavlink) | Bassel Andrew |
Inter-thread communication: We need some documentation covering how inter-thread communication is done. This will include explaining the key functions, how we are using MailQs, etc. | Tony |
FreeRTOS
| See bullet points |
Update the “Error codes and how to address them” doc
| See bullet points |
Telemetry manager: update document with new architecture | Dhruv R |
“Safety Architecture” notes:
| Anni |
“Sensors” document:
| Dhruv R Dhruv U Aadi Anthony |
Attitude and path manager documents: update documet with completed architecture | Dhruv R |
Sensor Fusion Modifications:
The error returns are very simple and should be changed to enums that provide more info.
The sensor fusion frequency constant could be defined in a better location for organization.
MadGWick algorithm did not work as expected. Find new one
In the
SF_GetPosition
function, there are many arrays that have not been initialized on declaration.See if we can abstract the GPS coordinate conversion methods so both waypoint and SF can use them
Safety
It’s just weird. Bad function names, bad comments, redundant functions… There’s not that much of it, but it’d be realllly nice to go thru the whole thing and clean up.
main.cpp
should just be main.c in safety. CubeMX is bad with C++. We’ll need to write interfaces to the c++ crap eventually.
Telemetry Manager
Tests do not mock static getInstance() method in XBEE class. Instead we use preprocessors to get by. We need to figure out how to mock static methods
Telemetry manager FSM test, the sendToInitialThroughDataValid and sendToObtainThroughDataValid need to pass in a struct so the tests in analyzeDataMode::execute() don’t cause the test to fail.
Fix documentation to get rid of reports.
Clean up analyzeDataMode::execute()
Write documentation for airside mavlink
Write more unit tests for airsideMavlinkencoding/decoding to test failure cases
Inter-thread Communication
We need to rename the functions such as `SendFromPMToAM()`. These names are hard to understand
GPS Sensor
Use the UBlox IDE to configure GPS so we don’t use 24 KB of buffers
Altimeter
We could not get an I2C interrupt working, as a result we are using a polling driver which blocks processors for 125 us every 5000 us (2.5% of time). We need to get the I2C interrupt working
Styling
Style guide
Consistent function naming scheme: are we capitalizing the first letter or not?
Consistent file naming scheme: are we capitalizing the first letter or not?
0 Comments