I'd like to add support for the rover using reverse in auto mode, so if it can get somewhere faster by going backwards it will. So I'm looking at how reverse is setup in the ArduRover code, and wondering what the best way to handle it is from a user point of view.
On my rover the motor goes in reverse with a PWM below 1500, and forward above 1500. So I setup RC3_MIN=1000, RC3_MAX=2000 and RC3_TRIM=1500. I then setup my transmitter to have a "reverse" switch that changes the throttle from going between 1500->2000 and 1500->1000. That seems to work quite well for manual driving.
The question is how to handle it from a setup point of view with the parameters. I think we'll need a REVERSE_SUPPORT parameter, which you would need to enable for the auto navigation to try to use reverse. If enabled then auto would have the option of driving backwards by setting a negative throttle, which would give a value below the RC3_TRIM value.
Does that seem like a good approach? Any other suggestions for supporting reverse?
Your logic sounds sensible to me. I believe that it is a good approach to start with until it is emperically validated one way or the other.
Tridge, I think you're going to need to add a "reverse pump" feature. Many ESC's commonly available require you to hit reverse, back to neutral, then reverse again before they will actually engage in reverse. If you just go to reverse and hold it the first time, it doesn't do anything. It will just sit there. You have to do this double-pump thing. It's a safety measure so that it's harder to tear the geartrain out of your vehicle by hitting reverse accidentally at high forward speed.
You just need to pulse it for about 1 second.
My CC Mamba Monster ESC requires 2 sec of no motion to be able to go into reverse if reverse is enabled.
yeah me too, dodgy brushed esc won't go reverse until the car has stopped. I think sending reverse while travelling forward has some weak brake effect like tying the motor terminals together.
Measuring wheel rotation is very useful. Makes determining "am I stopped" fairly easy and odometry + ahrs yaw is surprisingly accurate for location
* I read a few sparkfun avc cars rely on odometry.
* I've been playing with this kind of setup with normal arduino, chr-um6 imu, haven't used an APM.
Maybe helpful: the attached processing sketch has a little car steering animation to show one method of using reverse to drive at a waypoint. The rule is, if difference between current heading and target heading is between 45 and 135 degrees, invert steering and reverse throttle, otherwise go forward, turning towards target.
I would let my Rover better to drive forward only.
maybe you could do reverse as optional. that would be great.
I think the second biggest difference between aircraft and ground vehicles is the much larger number of obstacles on the ground compared to in the air. Probably many rover developers will be using obstacle avoidance systems. I suspect a lot of those obstacle avoidance systems will be more heavily oriented towards the front of the vehicle.
I would like default autopilot mode to only use reverse in special cases like getting stuck in a corner or on rough ground, or I suppose it could be an option in mission planner, like go from waypoint A to waypoint B in reverse.
Thank you for asking for user input and for stepping up to lead the way to some proper rover code.
Sending reverse while moving forward has more than a weak brake effect. It's a HUGE brake effect! back in the day with mechanical speed controllers, we use to do this all the time. It would cause the car to spin out. I think that is one of the reasons they did this delayed reverse thing. Control. You wouldn't want to accidentally go in reverse. But I also suspect the electronics can't handle the current surge either.
Actually, it's probably more about control, because you can go from reverse, directly into forward. This is how you pop a wheelie. I can do it with my son's Wheelie King.
Just some thoughts on reversing.
Recording an accurate 'Snail Trail' on a complicated competition course or in free running is as important on the ground as in flight. Being able to 'reverse' along that trail is probably more important with the UGV rather than a return to base flight option.
Is being able to reverse the 'Snail Trail' a possibility with the setting up of the REVERSE_SUPPORT parameter?
It sounds like most are using an ESC on their 'bots. This may be fine, but a more "robotics" approach (no offense intended) is to use a dual motor controller. Controllers like the Sabertooth and RoboClaw can use R/C-type PWM signals to drive differentially steered 'bots (drive motor for each side). These controllers also accept steering and throttle signals. I'd like to see a a "DIFFERENTIAL_STEERING" mode in addition to S/T. They are probably more flexible. Ground vehicles need to be able to back up a short distance, back with a little turn, and other tactics to get out of jams.
Actually, I'd like to have the APM2 generate a string of serial command words; they would be received by my mini-ATX PC, and I'd let ROS use the information as input. I'll add obstacle avoidance, and switch over to commands from a camera when I'm close enough to my goal (Robomagellan) .
I modeled my 'bot after JBOT after conversing with DPA. Watch the videos! It will give you a great demo of an autonomous rover. Couple of examples:
Actually, I thought about it some more, and all I want from APM2 is simple serial differential messages; I'll handle the reverse and obstacle avoidance in ROS.
My 6WD rover Sabertooth ESC works fine in the R/C mode using steering and throttle input. It goes forward, backwards, and performs right and left skid turns just fine. Using my MINDS-i obstacle avoidance control system coupled to my Sabertooth ESC, my rover backs up and makes turns with no problems.
Just a thought.
Yeah, OK for inputs from an R/C receiver, I think my RoboClaw works the same way. Not bad for initial tests. I could do the same with a Mega Arduino, but I'd prefer to move that code into the mini-ATX. Your MINDS-I controller is a Mega, right? I suppose I could get that working, and possibly port the algorithm into a node under ROS.
What are you doing for encoders? I didn't think the Sabertooth handled encoders. My RoboClaw can. Otherwise, I might have used the Sabertooth; as it seems to be more reliable.