This topic is a question about a contribution to ros_control.
I was working on a reconfigurable mobile robot project before and needed to have an N-wheel steering controller. Four_wheel_steering controller wasn’t very useful in this case. So, I made a package that can take any number of wheels with different configurations (position relative to the robot base frame, steering angle limitation, wheel radius) and calculate the required steering angle and angular velocity for this wheel. It takes into consideration the steering limitation and the closest path to the target (whether to get to the target angle or to its supplementary and negate wheel velocity). The configuration can be set through a YAML file and/or from the tf tree (for the wheels’ position).
If I’m not mistaken, a three-wheeled forklift has two differential (non-steerable of course) wheels in front and a steerable wheel in the back. If so, then yes it can work with it.
In fact, back then when I was working on the project tested this package (driving and odometry) with many configurations including Ackerman-like steering (simply by constraining the two back wheels of the 4WS robot from the video), differential steering, and a set of vehicles with a random number of randomly positioned wheels with random steering limitations and it worked well (despite the singularity issues discussed before).
As for the package itself, I haven’t published it. I made the topic to first ask if this would be a good contribution (of course after being well prepared and tested) for ROS control. Last time I contributed without asking first, I ended up making something useless.
It could even replace the ackermann and diff_drive controllers as you already described.
Or probably: they would use a subset of this controller. I would keep them in existence because people are familiar with that terminology.
And allow for front-wheel-driven ackermann steering (now it’s hardcoded rear-wheel drive).
Do you plan to target ROS1 or ROS2?
‘New’ robots that are in need of control are more likely to adopt ROS2 (assumption here!). So I would say your code gets a larger audience if directly implemented in ROS2.
If I’m not mistaken, a three-wheeled forklift has two differential (non-steerable of course) wheels in front and a steerable wheel in the back.
Even worse: the back wheel if sometimes off-center. Which makes it non-ackermann-ish.
To me this package sounds really useful! Would be great if you can share it!
I see that most ‘new’ robots would like a ROS2 version, but if people like your package you can benefit from the power of the community and have (parts) of the conversion be done for you
If I have a differential robot, I won’t go through the hassle of making a configuration file (that is to define the wheels positions relative to base_frame or take them from tf, wheels radii, and set the steering limits to [1-80,180] aka non-steerable wheels). same for the Ackerman.
So, can it do it? Yes … Is it the best solution to replace them? No
I’ll check those issues before I can reply to this.
Also, This work was done in ROS1 unfortunately. I realize ROS2 is the future here. So ROS2 it is.
I am definitely going to get some help from the community if we want this to be a part of ROS2.
I mentioned an issue in the odometry and it’s obvious in the video. I will be checking the paper above and see what can be done. The thing is I’m sure there are other bugs to be fixed and features to be considered.
It will take a considerable amount of work to be a ROS2 package.
In that case I would go for the ROS1 adoption first. It gets a little traction and review from others.
For ROS2 then ‘only’ the migration remains, the algorithm already passed review etc.
(We’re actually using both, so happy to test).
I mean it would take some work to be ready as a ros controller despite the ROS version (real time constraints, transferring it to Cpp… it’s written in python, clean coding, tests…etc).
I say ROS2 because from what i see I think everyone is migrating to ROS2 now.
Nice work! Indeed, this is something that could join the family of controllers that are based on the diff_drive_controller. I would not limit myself to a single version of ROS in your case though, there are plenty of users on Noetic and Melodic still and moving controllers from one to the other is not that big of a hassle. It is also easier to grasp the concepts of ros2_control when you are already familiar with ros_control!
So in order to take a step to make it join the ros controllers. What should be done first?
Like for example should it be discussed first in the group meeting announced earlier? I believe there must be some kind of organizational procedures to keep the project tidy and not just anyone can jump in and push their work.
Thank you. I will start with a ROS1 PR as it’s a ROS1 work, get the first feedback and then see if others would be interested to join and contribute too. Thanks again.
Funnily enough, I’ve actually been working on a very similar controller in ROS2. I’d be happy to work with you @MarkNaeem to align on methodology and work on the ROS2 equivalent PR.
Great to see so many people already ready to help. Someone else showed his interest to join on LinkedIn too.
I just started writing down my thoughts to build a roadmap. I think we would need to work on other points rather than just splitting into ROS1 and ROS2 teams
So… I have created a slack workspace for anyone interested in this project. You all are more than welcome to join, just let me know and I’ll add you.
Second thing, considering the problem @Timple mentioned
I added a really tiny piece of mathematics that considered an offset for the wheel in both wheel velocity calculations and odometery… I’ll modify that table-like robot I used in the demo to give its wheels some offset and will give it a try.
Might work for Neobotix MPO-700 ! We currently use our kinematics node (coupled along with the ros-controllers for Gazebo Simulation). But, yeah seems to be amazing ! We would love to add this controller to our ROS-2 Simulation!
.