IMU data published as a ros2 topic

[pondersome]

This is a request to get the imu data from the general driver board's built-in imu and published at a configurable rate as a ros2 raw imu message.

A bonus would be to also publish as a standard ros2 imu message:
https://github.com/ros2/common_interfaces/blob/humble/sensor_msgs/msg/Imu.msg

Though we could use the madgwick filter for that:
https://index.ros.org/p/imu_filter_madgwick/

This would help a great deal when the RoArm is mounted on a moving chassis.

[pondersome]

You closed this as completed, but I don't see a commit associated with this. Do you mean to say that this request will not be considered?

[DUDULRX]

I would like to ask, what function do you want to use this imu data for?
There is a project that feeds back imu data here, but the project is for ugv. The original position of the robot arm LED was replaced by a car motor.

[pondersome]

This would help when the RoArm is mounted on a moving chassis. This adds value in that another feature of the general driver board become useable for a moving robot, which typically use an imu for short-term yaw sensor fusion in the navigation stack. Not all robot chassis platforms come with an imu. It is ok to "close as not planned" if you determine the imu is unsuitable or you feel this feature would not be used.

[DUDULRX]

Should the robotic arm and the mobile chassis share a drive board, or should there be two separate drive boards?

[pondersome]

This use case is about activating the otherwise unused imu on the arm's general driver board as a resource for whatever purpose it might be needed for whatever robot the arm might be mounted on. It could mean, for example, then another imu doesn't have to be incorporated because there is one already available. If the chassis already has an imu (like if it has its own controller with an incorporated imu), then this use case is less important. Though it never hurts to have another imu to cross reference. The point of this use case is to make the arm more valuable in a mounted situation since it could displace the direct cost of adding an imu and more importantly displace the integration time needed to add an imu.

…

On Fri, Dec 27, 2024 at 7:56 PM DUDULRX ***@***.***> wrote: Should the robotic arm and the mobile chassis share a drive board, or should there be two separate drive boards? — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPGRRCQFPFU6NRBVXGIJ632HYAL7AVCNFSM6AAAAABR4EAHB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGEZTKNBZG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>