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

MicroRos does not publish imu data in higher rates #1781

Open
ugurxun opened this issue Jun 6, 2024 · 10 comments
Open

MicroRos does not publish imu data in higher rates #1781

ugurxun opened this issue Jun 6, 2024 · 10 comments

Comments

@ugurxun
Copy link

ugurxun commented Jun 6, 2024

Issue template

  • I am working on ESP32 WROOM 32
  • RTOS: It is running on (PC) linux ubuntu 20.04.6 LTS via
  • Installation type: Arduino micro_ros_arduino library
  • Version or commit hash: ROS2 galactic

Steps to reproduce the issue

I am using "Bolder Flight Systems MPU9250" library to read MPU9250 imu data. I created a imu publisher and message type was sensor_msgs/msg/imu. The sensor normally can run in 200 hz rate. I configured the timer callback for 200 hz, so timer_timeout was 5 ms and I used RCL_MS_TO_NS function to convert it nanoseconds. I used "rclc_publisher_init_best_effort" while creating the publisher and it spinned 1ms via "RCSOFTCHECK(rclc_executor_spin_some(&executor, RCL_MS_TO_NS(1)))". I updated the imu data and assigned imu data to imu publisher messages in the timer callback. I also published in the timer callback.

Expected behavior

I expected 200 hz publisher rate.

Actual behavior

It is published in approximately 34 Hz when i checked with "ros2 topic hz /imu_data"

Additional information

@hippo5329
Copy link

The default serial baudrate 115200 is too slow for IMU msgs at higher rate. You will need to change the serial baudrate to 921600 or 2M if the serial USB bridge on esp32 supports. C340/ CP2102N support up to 2M, while CP2102 supports only 921600.

ESP32-S3 or PICO use on-chip CDC protocol, ttyACM0l. Buadrate setting is ignored. They will have better serial speed.

@hippo5329
Copy link

The default i2c clock is 100KHz. You should set the i2c clock to 400KHz or 1MHz if the IMU supports.

@ugurxun
Copy link
Author

ugurxun commented Jun 7, 2024

Hello,

I tested my board and it is working with 921600 baudrate without any problem. I set the baudrate as 921600 and i2c as 400khz but nothing changed. It still publishes in 34 hz even though I expect 200 hz.

@hippo5329
Copy link

You may try two tests.

  1. Check the micro-ros topic rate without reading the IMU. ie, comment out the reading of IMU and just pass a dummy msg to micro-ros.

  2. Check the reading speed of IMU without micro-ros. Loop reading the IMU and find the maximum rate of the IMU driver.

@hippo5329
Copy link

The i2c bus sda scl need 2K pull up to 3.3V.

@ugurxun
Copy link
Author

ugurxun commented Jun 10, 2024

Hello,

When I assigned dummy values to sensor messages, I still saw 34 Hz.
I tested the IMU rate by the way of you described, I saw approximately 700 Hz max rate. It can also be sampled up to 1000hz, when i check the data sheet.

@hippo5329
Copy link

So it should the problem in control loop. Have you tried init_default and spin_some 100?

@hippo5329
Copy link

I would suggest some exercises on the publisher example.
https://github.com/micro-ROS/micro_ros_arduino/tree/galactic/examples/micro-ros_publisher

Remove the delay(100) in the loop(). And change the timer timeout to higher rate. Try to find the upper limit of publish rate.

@ugurxun
Copy link
Author

ugurxun commented Jun 11, 2024

When i worked witk init_default, i saw 30 hz max for sensor msgs. Delay(100) was already removed and spin_some was 100. However when i worked with std msgs as the example you had shared, the problem was disappeared and i saw higher rates (200 hz). The problem is probably related with sensor msgs.

@hippo5329
Copy link

You may change the massage type of the publish int example to msg/Imu, and check the publish rate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants