UPDATED ISSUE: by comparing with CAN logger board logs, 63.TXT aligns with the pre-flight tests when the injector valve open was tested at the launchpad. After this test, processor board was reset (as it should). There appear to be 0 logs in the sd card after this moment. WHAT HAPPENED???? It seems like processor did still run during flight as there were CAN msgs from it. There are also extension cmds, so presumably it successfully detected flight phases in the actual flight. However none of this was logged. WHY??
PREVIOUSLY THOUGHT-TO-BE ISSUE:
For still unknown reasons, trajectory prediction never reached this line of code where it's supposed to log predicted apogee. It also likely did not run the next line of code which unblocks apogeeQueue, because the controller task never received anything from this queue.
I can't tell where exactly the trajectory task got stuck, but it must be somewhere before those 2 lines mentioned above.
possibilities we've thought of so far:
altQueue never got unblocked, because the rest of the task depends on this happening. This would mean CAN handler never received altitiude msgs, or it did receive alt msgs but failed to update altQueue somehow.
angleQueue never got unblocked, because the rest of the task depends on this happening after CAN. This seems unlikely, because this is a QueuePeek, meaning any valid angle would've unblocked it, and stateest definitely did send things to angleQueue. More likely, it unblocked
Combination of the timing of unblocking from those 2 queues not working somehow?? But shouldnt be issue cuz angleQueue is a QueuePeek.
the INT_MAX thing didn't work. What if this line set prev_alt to INT_MAX everytime by accident so the if(prev_alt != INT_MAX) never passed? CAN corruption could cause this
divide by 0 error happened at some point and caused the whole thing to malfunction. Idk how or if this could affect further lines though
steps to take:
use usb debug + parsley to send altitude msgs to make sure the queues are getting unblocked properly. This would also require mocking a send to angleQueue somewhere.
determine how to check for all the above possibilities
celery6
commented
1 month ago
UPDATED ISSUE: by comparing with CAN logger board logs, 63.TXT aligns with the pre-flight tests when the injector valve open was tested at the launchpad. After this test, processor board was reset (as it should). There appear to be 0 logs in the sd card after this moment. WHAT HAPPENED???? It seems like processor did still run during flight as there were CAN msgs from it. There are also extension cmds, so presumably it successfully detected flight phases in the actual flight. However none of this was logged. WHY??
PREVIOUSLY THOUGHT-TO-BE ISSUE: For still unknown reasons, trajectory prediction never reached this line of code where it's supposed to log predicted apogee. It also likely did not run the next line of code which unblocks apogeeQueue, because the controller task never received anything from this queue.
I can't tell where exactly the trajectory task got stuck, but it must be somewhere before those 2 lines mentioned above.
possibilities we've thought of so far:
steps to take: