Verification of control cycle times
Closed this issue · 3 comments
2 main issues:
-We need to verify control cycle times to make sure that they are not consistently late or displaying "cascading" lateness (where one task is late and causes all subsequent tasks to also be late)
-We need to make sure that the num_lates field in the timed control task is accurately counting the number of late tasks.
Some issues were observed when reading multiple gomspace state fields over a period of two minutes which causes an excessive number of tasks to be late in HITL. In HOOTL, the quantity of late tasks is lower but still consistently increasing which is a problem. Shown Below:
HITL:
HOOTL:
These times were found after running the gomspace logger ptest case which just reads a collection of gomspace fields for two minutes. However, when running the Magnetorquer test case in HOOTL similar behavior was found, the difference is the late tasks weren't increasing, which is due to the nature of the test.
- Verify that if Flight Software is faster than 170 ms that we lower bound at 170 ms
- Add verifications to hardware checkout cases that every control task executes at 170ms
- Allocate debug task as much as we can up to letting everything sum to 170 ms
- Allocate for quake worst case (40k micros)? + gather more data
Edu Sat 70min Ditl Case Cycling:
