Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/timestamps on sd cards #100

Merged
merged 6 commits into from
Dec 13, 2023
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Core/Inc/roboteam_embedded_messages
Submodule roboteam_embedded_messages updated 53 files
+40 −24 README.md
+237 −44 generator/Generator.py
+47 −0 generator/README.md
+1 −1 generator/latest_rem_version.txt
+1 −2 generator/packets.py
+47 −47 include/REM_BaseTypes.h
+30 −28 include/REM_BasestationConfiguration.h
+27 −25 include/REM_BasestationGetConfiguration.h
+27 −25 include/REM_Log.h
+27 −25 include/REM_Packet.h
+30 −28 include/REM_RobotAssuredAck.h
+33 −31 include/REM_RobotAssuredPacket.h
+36 −34 include/REM_RobotBuzzer.h
+74 −72 include/REM_RobotCommand.h
+72 −70 include/REM_RobotFeedback.h
+27 −25 include/REM_RobotGetPIDGains.h
+27 −25 include/REM_RobotKillCommand.h
+58 −56 include/REM_RobotMusicCommand.h
+87 −85 include/REM_RobotPIDGains.h
+87 −85 include/REM_RobotSetPIDGains.h
+105 −103 include/REM_RobotStateInfo.h
+1 −1 include/REM_SX1280Filler.h
+18 −18 proto/REM_BasestationConfiguration.proto
+17 −17 proto/REM_BasestationGetConfiguration.proto
+17 −17 proto/REM_Log.proto
+17 −17 proto/REM_Packet.proto
+18 −18 proto/REM_RobotAssuredAck.proto
+19 −19 proto/REM_RobotAssuredPacket.proto
+19 −19 proto/REM_RobotBuzzer.proto
+31 −31 proto/REM_RobotCommand.proto
+31 −31 proto/REM_RobotFeedback.proto
+17 −17 proto/REM_RobotGetPIDGains.proto
+17 −17 proto/REM_RobotKillCommand.proto
+27 −27 proto/REM_RobotMusicCommand.proto
+32 −32 proto/REM_RobotPIDGains.proto
+32 −32 proto/REM_RobotSetPIDGains.proto
+36 −36 proto/REM_RobotStateInfo.proto
+47 −47 python/REM_BaseTypes.py
+28 −26 python/REM_BasestationConfiguration.py
+25 −23 python/REM_BasestationGetConfiguration.py
+25 −23 python/REM_Log.py
+25 −23 python/REM_Packet.py
+28 −26 python/REM_RobotAssuredAck.py
+31 −29 python/REM_RobotAssuredPacket.py
+34 −32 python/REM_RobotBuzzer.py
+72 −70 python/REM_RobotCommand.py
+70 −68 python/REM_RobotFeedback.py
+25 −23 python/REM_RobotGetPIDGains.py
+25 −23 python/REM_RobotKillCommand.py
+56 −54 python/REM_RobotMusicCommand.py
+85 −83 python/REM_RobotPIDGains.py
+85 −83 python/REM_RobotSetPIDGains.py
+103 −101 python/REM_RobotStateInfo.py
20 changes: 15 additions & 5 deletions Core/Src/robot.c
Original file line number Diff line number Diff line change
Expand Up @@ -93,6 +93,8 @@ volatile uint32_t counter_TIM_SHOOT = 0;
volatile uint32_t counter_RobotCommand = 0;
volatile uint32_t counter_RobotBuzzer = 0;
uint32_t timestamp_initialized = 0;
uint64_t unix_timestamp = 0;
bool unix_initalized = false;

bool flag_send_PID_gains = false;
bool flag_sdcard_write_feedback = false;
Expand Down Expand Up @@ -166,9 +168,11 @@ void Wireless_Readpacket_Cplt(void){
// TODO insert REM_SX1280Filler packet if total_packet_length < 6. Fine for now since feedback is already more than 6 bytes
WritePacket_DMA(SX, &txPacket, &Wireless_Writepacket_Cplt);
}

void Wireless_Default(){
WaitForPacket(SX);
}

void Wireless_RXDone(SX1280_Packet_Status *status){
/* It is possible that random noise can trigger the syncword.
* Correct syncword from noise have a very weak signal.
Expand Down Expand Up @@ -375,7 +379,7 @@ void init(void){
dribbler_Init();
// TODO: Currently the ball sensor initialization is just disabled.
// Since we will no longer use it anymore this should be fully removed from the code.
// if(ballSensor_Init()) LOG("[init:"STRINGIZE(__LINE__)"] Ballsensor initialized\n");
// if(ballSensor_Init()) LOG("[init:"STRINGIZE(__LINE__)"] Ballsensor initialized\n");
LOG_sendAll();
}

Expand Down Expand Up @@ -577,7 +581,6 @@ void loop(void){
}
if(flag_sdcard_write_command){
flag_sdcard_write_command = false;
activeRobotCommand.timestamp = current_time;
encodeREM_RobotCommand( &robotCommandPayload, &activeRobotCommand );
SDCard_Write(robotCommandPayload.payload, REM_PACKET_SIZE_REM_ROBOT_COMMAND, false);
}
Expand Down Expand Up @@ -819,7 +822,6 @@ void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {
}else if(GPIO_Pin == MTi_IRQ_pin.PIN){
MTi_IRQ_Handler(MTi);
}else if (GPIO_Pin == BS_IRQ_pin.PIN){
// TODO: make this work and use instead of the thing in the while loop
ballSensor_IRQ_Handler();
}
}
Expand All @@ -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){
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this not be && ? I guess technically it works

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also. why is not always the timestamp used from the latest RobotCommand? Would that not be more accurate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@emielsteerneman emielsteerneman Dec 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

unix_timestamp = activeRobotCommand.timestamp;
unix_initalized = true;
}

counter_TIM_CONTROL++;

// Update the dribbler at 10Hz
Expand Down Expand Up @@ -895,7 +902,7 @@ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
wheels_Update();

/* == Fill robotFeedback packet == */ {
robotFeedback.timestamp = current_time;
robotFeedback.timestamp = unix_timestamp;
robotFeedback.XsensCalibrated = xsens_CalibrationDone;
// robotFeedback.batteryLevel = (batCounter > 1000);
robotFeedback.ballSensorWorking = ballSensor_isInitialized();
Expand All @@ -915,7 +922,7 @@ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
}

/* == Fill robotStateInfo packet == */ {
robotStateInfo.timestamp = current_time;
robotStateInfo.timestamp = unix_timestamp;
robotStateInfo.xsensAcc1 = stateInfo.xsensAcc[0];
robotStateInfo.xsensAcc2 = stateInfo.xsensAcc[1];
robotStateInfo.xsensYaw = yaw_GetCalibratedYaw();
Expand All @@ -934,6 +941,7 @@ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
}

flag_sdcard_write_feedback = true;

}
else if (htim->Instance == TIM_BUZZER->Instance) {
counter_TIM_BUZZER++;
Expand All @@ -944,4 +952,6 @@ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
counter_TIM_SHOOT++;
shoot_Callback();
}

unix_timestamp += 1 ;
}