search

gazebosim / gz-msgs

Messages for Gazebo robot simulation.
https://gazebosim.org
Apache License 2.0
21 stars 45 forks source link

Add support for AckermannDrive message #435

Closed retinfai closed 6 months ago

retinfai commented 6 months ago

🦟 Bug fix

Fixes #433

Summary

Add support for AckermannDrive and AckermannDriveStamped messages http://docs.ros.org/en/jade/api/ackermann_msgs/html/msg/AckermannDrive.html http://docs.ros.org/en/jade/api/ackermann_msgs/html/msg/AckermannDriveStamped.html

Checklist

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

🎉 New feature

Closes #

Summary

Test it

Checklist

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

➡️ Forward port

Port to

Branch comparison: https://github.com/gazebosim//compare/...

Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

🎈 Release

Preparation for <X.Y.Z> release.

Comparison to <x.y.z>: https://github.com/gazebosim//compare/...

Needed by <PR(s)>

Checklist

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

bperseghetti commented 6 months ago

@retinfai I'm curious what the overall goal is of adding this message, is it not already covered by existing messages? Is there a plan for using the other Ackermann plugin you previously mentioned in the associated issue to be upstream?

What do you view as missing from the current Ackermann plugin?

Is this related to this other PR?: https://github.com/gazebosim/gz-sim/pull/2018

Also it appears this message is based off this slightly weird use in teleop?: https://github.com/UOA-FSAE/f1tenth/blob/47f2b198bdba8711fa491ae13905f77eeeb8aa69/f1tenth_bringup/config/joy.yaml#L13

retinfai commented 6 months ago

Currently, we are trying to build the F1tenth robot in gazebo. The specifications for the actual robot are given here Driving the F1tenth Car -> Autonomous Control -> Drive Topic. The vesc use the AckermannDriveStamped messages to drive the robot. I believe this has been standardised for the F1tenth robot.

We are trying to use reinforcement learning to drive the f1tenth in simulation, and port that over to the real thing. The current ackermann steering plugin uses twist which may create a disconnect, between the interface the RL learns to predict and the real thing. This is the problem I'm trying to address – I asked that question in a seperate PR to be able to recreate this behaviour using the existing plugin (https://github.com/gazebosim/gz-sim/pull/2315) but decided it may produce issues to maintain two separate topics for both joint velocity for the driving and the steering topic.

I've now decided to create my own gazebo plugin that uses this message. However, I do now realise that perhaps, this isn't the correct route. However, I wasn't too confident on how I can create my own custom message that Gazebo would accept in simulation for my new plugin.

As for the other PR, I wasn't too involved with that, so not too sure what's going on there. But I think the intention/problem that it was trying to solve was adding what's shown in the image below although after a quick skim of their PR, I see that they are adding other stuff.

Screenshot 2024-03-20 at 1 46 43 PM

What do you think?

bperseghetti commented 6 months ago

Currently, we are trying to build the F1tenth robot in gazebo. The specifications for the actual robot are given here Driving the F1tenth Car -> Autonomous Control -> Drive Topic. The vesc use the AckermannDriveStamped messages to drive the robot. I believe this has been standardised for the F1tenth robot.

We are trying to use reinforcement learning to drive the f1tenth in simulation, and port that over to the real thing. The current ackermann steering plugin uses twist which may create a disconnect, between the interface the RL learns to predict and the real thing. This is the problem I'm trying to address – I asked that question in a seperate PR to be able to recreate this behaviour using the existing plugin (gazebosim/gz-sim#2315) but decided it may produce issues to maintain two separate topics for both joint velocity for the driving and the steering topic.

I've now decided to create my own gazebo plugin that uses this message. However, I do now realise that perhaps, this isn't the correct route. However, I wasn't too confident on how I can create my own custom message that Gazebo would accept in simulation for my new plugin.

As for the other PR, I wasn't too involved with that, so not too sure what's going on there. But I think the intention/problem that it was trying to solve was adding what's shown in the image below although after a quick skim of their PR, I see that they are adding other stuff.

Screenshot 2024-03-20 at 1 46 43 PM

What do you think?

I think you might be targeting the wrong level of abstraction, VESC does not "speak" ROS 2, there must be a ROS 2 -> VESC translation node somewhere (VESC is shown here in the docs you shared).

VESCs only input/outputs are PPM, PWM, CAN and Serial, it already has a defined dataframe/message that is uses for control (none of which is ROS 2). In your case you are using serial over USB. For instance we use VESCs with it's native CAN interface with FOC control of a hub motor and quadrature encoder feedback.

At the end of the day you feed the VESC an eRPM and it does the best to get to that eRPM based on the tuning parameters it has internally. It also appears that there is no encoder on the motors used that are provided so it makes it even more of a black box making the "Ackermann message" used even more meaningless from a control perspective.

Here's how I would go about it:

I would write a ROS 2 node that listens to the Ackermann msg on the ROS 2 side and converts that message (like what is done on the VESC controller) to control the simulated actuators (joints) directly simulation.

For that purpose you can either use the direct approach of setting the joints with the actuators command by taking eRPM->rad/s and PPM steer angle -> rad (considering your setup that's my suggestion), or the more indirect approach of calculating what that would be as a body rate and converting that to a twist message for cmd_vel. The current plugin supports both of those approaches.

Then you run the RL with the input of the ROS 2 side Ackermann input message and can take the odometry/world pose output from simulation.

bperseghetti commented 6 months ago

@retinfai actually, here it is, it's super simple: https://github.com/f1tenth/vesc/blob/1952e799110f5c4eed82c68a6172bfcafd9998ac/vesc_ackermann/src/ackermann_to_vesc.cpp That output almost exactly mirrors the actuator msg approach in the current ackermann plugin. So my personal opinion is that I do not think adding these messages would be of any benefit from a simulation perspective for the intended use.

retinfai commented 6 months ago

Thank you heaps for clearing up that misunderstanding :) I now understandd what it is I should do. I'll give those approach a go.

Sweet as, that makes sense. That is my bad: closing related issue/PR.

Thanks for your help. I'll give that approach a go