Feature/timestamps on sd cards #100
Conversation
…on the recieved packet and write it to the transmitting packets which we are sending. In the control loop, to avoid the problem where we write multiple times to sd card with the same time stamp we increament at the end of the control loop byy 10
Core/Src/robot.c
Outdated
| @@ -831,6 +833,11 @@ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { | |||
| if(htim->Instance == TIM_CONTROL->Instance) { | |||
| if(!ROBOT_INITIALIZED) return; | |||
|
|
|||
| if (!unix_initalized & activeRobotCommand.timestamp != 0){ | |||
There was a problem hiding this comment.
Should this not be && ? I guess technically it works
There was a problem hiding this comment.
Also. why is not always the timestamp used from the latest RobotCommand? Would that not be more accurate?
There was a problem hiding this comment.
Also. why is not always the timestamp used from the latest RobotCommand? Would that not be more accurate?
A request from the control subteam.
For analyzing the acceleration of the robot the difference between 2 timestamps of 2 consecutive packets should align with the real world. So if in real time 10ms has passed, that should be reflected in the timestamp. But if you always take the most recent timestamp from robotCommand you will see from time to time that 20ms has passed. This is due to the fact that the incoming timestamp is rounded to the nearest 10. Even if you would not round it will be a problem, as the incoming packets come at 60Hz, whilst the robotFeedback runs at 100Hz. Meaning that there will still be some misalignment between time stored in the packet and real time passed.
There was a problem hiding this comment.
I understand what you are saying. However, a timestamp should not be needed between consecutive packets stored on the SDCard because we know they are 10ms apart. However, if the clock between a robot and the computer are running at different speeds, then at some point, data on the SDCard and data from the vision system can become misaligned, which might make it useless.
If the latest timestamp is used, SDCard data will always be able to be overlayed with other data such as vision, while also being able to accurately measure acceleration because we know packets are 10ms apart.
Updating REM packets to version 5.
Adding code on how timestamps are set for REMFeedback and REMStateInfo