I am attempting to integrate a real hardware IMU with the quadruped simulation, but I'm facing issues where the robot does not react to the IMU data and instead immediately falls and struggles to balance (It's unable to stand once it has fallen).
What I'm Trying to Achieve:
Basically, I am trying to have everything in simulation, except the IMU (It will be a real hardware IMU) and the quadruped should ideally react and balance itself according to changes in IMU.
Here’s a summary of what I’ve tried so far:
Introduced the "use_realimu" flag to conditionally handle real IMU data in the robot_driver.cpp.
"use_realimu" is set to true and is used in places where "ishardware " flag is used, since the system expects all hardware to be available when ishardware flag is turned on, so i used use_realimu flag to handle only IMU data.
Modified conditions in the updateState method to process real IMU data, including adding a call to recv() to receive the IMU data (commented out joint and user data to avoid hardware dependencies).
The real IMU is publishing data correctly to the /robot_1/state/imu topic, but the robot does not seem to adjust its movement based on this data.
Without the real IMU (use_realimu false), the robot functions normally, suggesting the real IMU integration is causing instability.
IMU Callback and TF Broadcasting:
Created a custom IMU callback function in robot_driver.cpp to subscribe to /robot_1/state/imu and broadcast the TF from robot_1_ground_truth/body to imu::link
last_imumsg seems to be populated correctly
Changes in SDF/URDF Files:
Commented out virtual IMU sensor tags in spirit.sdf, spirit_rotor.sdf, and spirit.urdf
Recv Function in SpiritInterface:
I initially tried using the recv() function to receive the real IMU data. However, this function expects both joint and IMU data. When called, the robot failed to stand.
I attempted modifications to the recv() function to only handle IMU data, but this did not resolve the issue.
Questions:
1)Are there specific configurations or steps we’re missing to fully integrate the real IMU into the control loop? Is there an issue with how the state estimator or control logic is using the real IMU data in my case?
2)Could there be anything still using simulated data, despite commenting out virtual IMU sensors?
3)Do we need to modify any part of the control system to ensure it’s using real IMU data for stabilization?
4)I see warnings that motor efforts are exceeding thresholds, even though the IMU is stationary. Could this indicate an issue with the control logic or how the real IMU data is being applied?
5)I am not using mocap data currently. Could this be causing issues in the robot’s balance or state estimation?
Any guidance on resolving this would be highly appreciated!
Hello,
I am attempting to integrate a real hardware IMU with the quadruped simulation, but I'm facing issues where the robot does not react to the IMU data and instead immediately falls and struggles to balance (It's unable to stand once it has fallen).
What I'm Trying to Achieve: Basically, I am trying to have everything in simulation, except the IMU (It will be a real hardware IMU) and the quadruped should ideally react and balance itself according to changes in IMU.
Here’s a summary of what I’ve tried so far:
Introduced the "use_realimu" flag to conditionally handle real IMU data in the robot_driver.cpp. "use_realimu" is set to true and is used in places where "ishardware " flag is used, since the system expects all hardware to be available when ishardware flag is turned on, so i used use_realimu flag to handle only IMU data.
Modified conditions in the updateState method to process real IMU data, including adding a call to recv() to receive the IMU data (commented out joint and user data to avoid hardware dependencies).
The real IMU is publishing data correctly to the /robot_1/state/imu topic, but the robot does not seem to adjust its movement based on this data. Without the real IMU (use_realimu false), the robot functions normally, suggesting the real IMU integration is causing instability.
IMU Callback and TF Broadcasting: Created a custom IMU callback function in robot_driver.cpp to subscribe to /robot_1/state/imu and broadcast the TF from robot_1_ground_truth/body to imu::link
last_imumsg seems to be populated correctly
Changes in SDF/URDF Files: Commented out virtual IMU sensor tags in spirit.sdf, spirit_rotor.sdf, and spirit.urdf
Recv Function in SpiritInterface:
I initially tried using the recv() function to receive the real IMU data. However, this function expects both joint and IMU data. When called, the robot failed to stand. I attempted modifications to the recv() function to only handle IMU data, but this did not resolve the issue.
Questions: 1)Are there specific configurations or steps we’re missing to fully integrate the real IMU into the control loop? Is there an issue with how the state estimator or control logic is using the real IMU data in my case? 2)Could there be anything still using simulated data, despite commenting out virtual IMU sensors? 3)Do we need to modify any part of the control system to ensure it’s using real IMU data for stabilization? 4)I see warnings that motor efforts are exceeding thresholds, even though the IMU is stationary. Could this indicate an issue with the control logic or how the real IMU data is being applied? 5)I am not using mocap data currently. Could this be causing issues in the robot’s balance or state estimation?
Any guidance on resolving this would be highly appreciated!
Thank you!