I am writing on my blog an analysis of Explicit Steering which is when a robot has 4 independently steered wheels, like the Mars rovers. This is in conjunction with the NASA Space Robotics Phase 2 competition. I’m not looking for assistance in creating the driver for this rover, although the driver is a requirement in the qualifying round.
My first post recognizes that there are ROS packages that control explicit steering but they are based on speed control while this rover uses effort. After a lot of consideration I may asses how to map the speed to effort to use that code for the driver.
I have examined number of research papers that discuss this topic. In part I’m trying to reduce the academic work to a more friendly presentation.
Mainly interested in comments on the blog about the analysis I’ve done so far and additional future material.
Nice blog post. I would like to know what control setup you will end up using.
The most easy way to convert torque into velocity is using cascaded control. I could not find that term in your blog post. It works by having a faster inner loop that uses velocity as input and control the torque to achieve that (for example a controller on each wheel). Then it as a slower outer loop on velocity level (for example the ROS packages you mentioned).
The kinematic structure of such a robot is also known as swerve drive. In this blog there are nice presentations on how to compute the kinematics:
As indicated by Rayman, you can use cascade control to convert speed references to efforts. The output of the outer loop controller is then converted to a pivot and speed setpoint for each wheel, which can be controlled locally.
A more sophisticated control strategy that uses torque distribution is about to be submitted to a journal (as part of a PhD study of a student at Eindhoven University of Technology). When I am allowed to share i will let you know.
I haven’t into the control loop except for some small experiments. The four wheel effort / speed PIDs are daunting. Your comment implies you can go from velocity setpoint to torque output. Is that possible?
I’ve read about the cascading control schemes. I have scanned Academia.edu for material but, as I mention in the blog, going from the academic presentation to internalized understanding for programming is an uphill battle.
I think with four steerable wheels you really have to adapt the path planner.
The basic concept with ROS steering is the “twist” message with has only speed and rotational rate. But your robot can drive sideways. “Twist” assumes the direction is always forward along the robot longitudinal axis. But now you can drive at an angle to the axis. The path planner will have to choose an angle. It seems a wast to let it default to zero.
Twist is not limited to forward and yaw, which I think your message applies. I address twist in a fourth post. Twist can be used for 3 dimensional movement for quad-copters.
For this moon rover I didn’t explore all the possibilities for sideways movement because the rovers sensors only face forward. Unless other techniques, e.g. mapping, can assure the area to the sides is clear it would put the rover at risk to do much crab movement.
Ok, if you only intend to drive the vehicle parallel to the longitudinal axes then control is easy. It is basically just like Ackerman steering with the pivot point being where the extended axels of all four wheels intersect. You choose that point along a line that crosses the midpoint of the robot. If the point is on other lines then you are doing this kind of “crab walk” you say your sensors can’t support.
Four-wheel steering (that is restricted to only “forward” motion) is just Ackerman with the wheelbase shorted to 1/2 and symmetric steering with from and back wheels. It is just two Ackerman systems stuck back to back with steering shared symetrically.
But what is gained over fixed rear wheels? Sharper turns. The pivot point can be anyplace on the line that crosses the robot’s midpoint. True Ackerman places the same line coincident with the rear axel. Bringing the line forward allows a “turn on place” like a tank but without the skidding.
But if you allow the “crab walk” then the pivot point can be literally anyplace and is not restricted to either line. This is why I said you’d need to re-think path planning to take advantage of the nearly holonomic platform.
I still think it is a bit of a waste to have a nearly holonomic platform and use a nonholonomic path planner.
It is the risk of collisions that limits the use of holonomic movement. With a rover 250,000 miles away from a repair capability preventing damage is important.
Additionally, given the deadlines for the competition using existing packages is advantageous.
If this is actually going to drive on the Moon, what I’d do is dust-off the RATLER proposal from Sandia National Labs. This was a proposed rover for the Moon or Mars that was developed by Sandia in the 1990s They got as far was driving full-sized rovers in the dessert.
The key concept or idea is that “The Chassis IS the Suspension”. There is no separate suspension that is bolted to a chassis. This eliminates most of the parts and is much stronger too.
The major risk, I think, is driving into a hole either with the entire vehicle or just one wheel in a “hole” between a pair of rocks. The one thing that really matters is the wheel diameter. Be as smart as you like with rover design and it matters less than simply having bigger wheels. So for a given mass, the Ratler has larger wheels than a Mars rover. The other thing Ratler has is simplicity. There is very little that can go wrong. The rover is just four wheels and a central pivot axel. and impotently all the parts are inside a strong shell.
I’ve been (slowly) working to develop a Ratler clone that can be 3D printed. My goal is that I want it larger than 1/2 meter wheelbase and strong enough to tumble down a full flight of stairs front over back. This last part has forced a redesign using larger axels and wheel bearings.
One thing both Mars Rover and Ratler have in common is a guarantee of equal weight on each wheel. This dramatically improves traction but they are at opposite ends of the complexity spectra. The Mars rover is the most complex design possible white Ratler is the simplest possible for equal weight distribution.
Have a look. Sandia did much of the work already and their papers show the optimal geometry and this has been tested at different scales. They are also cheap to build even at one meter wheelbase size.
Ho, simulation. Then you can simply use Ackerman and “fudge” the parameters to tell the software the rear axel is more forward than it realy is and then cut the steering commands in half and apply them to each wheel. Ackerman steering is well used, ROS has it covered. My current robot project is a ride-on toy car, big enough for two children to ride in and it uses Ackerman steering just like a “real car”. ROS handles this pretty much ou of the box.
If you must model this your self, Make a line cross ways at the robot mid point. To turn at radius = R meters. creat a point on that line “R” meters from the robot center. Now command all four wheels so that their extended axels interects at the point
Note the argoithum is exactly like for a nomal car except that the crossway line is coincident with the rear axel in a car and so the rear two weels intersect every point on that line and don’t need to be steered.
I hope this is clear, likely not. If it seems complex it’s my explanation
I had a quick peruse of your blog and I like what you’re up to!
I thought I’d send your attention to this PR that some of us are working on for 4WIS within the ROS Controls framework. It’s almost ready for merge so you can trial it out and provide feedback. Note that it is designed for velocity control like pretty much every other driver but I am heavily considering effort (torque) based control for the drive motors.
I would also be happy to look into some more complicated control strategies for things like traction control or whole body effort control like @cesar-lopez-mar is talking about since they would be very useful in off road situations.
@ingtux, I did a quick look at your code and will dig into it more deeply, especially the odometry. Some additional points to consider:
As I mentioned, the simulation is the NASA Space Robotics 2 competition which is on the moon. The gravity is less than on the Earth so between lower friction and dust the surface is slippery.
The low friction means the wheels slip easily, even sideways on a slope. This requires a PID for each wheel to maintain speed. It also wreaks havoc on encoder odometry. Every wheel can report a different movement and averaging them is insufficient.
Acceleration and deceleration need to be very controlled. Stopping by slamming on the brakes is a disaster. That makes obstacle avoidance a challenge since obstacles must be detected sufficiently in advance to slow to a stop or turn without sliding.
I expect some of these problems can be experienced with a robot on snow, ice, mud and other terrestrial situations.
Because of low friction I implemented a PID controller for each wheel. See my post in reply to my original post for more info.
I used speed as the setpoint for the PID but the output is speed. This seems to work okay. It should since most industrial PID control the input and output are different variables, e.g. tank level vs valve position.
@Rud_Merriam let me point you toward this paper. It talks about using feedback linearization to cancel nonlinearities and get wheel velocities. It works well but I suppose you would still need an inner PID loop to calculate torques.
Swerve steer is great! Because it can crab steer, pivot in place, or anything in between. Can’t beat it, I think.
Did you ever end up implementing your swerve controller? I’m curious to know if you or @Rud_Merriam have a list of useful controller implementations that might help us advance the state of swerve controllers.
As it currently stands there is no good real implementation (in something like ros controls) that people can contribute to so it would be great if we could find some other implementations and see if there’s anything in them worth moving into the ros_controllers repo.
I agree with Andy that swerve steer is the best but unfortunately it won’t see proper adoption without a good stable controller!
Your comment implies you can go from velocity setpoint to torque output. Is that possible?