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?
I'm using what I had on hand! at $130+, (and a good fit) also have previous experience with them. I do have a good LiPos charger set-up, and a few batteries, but didn't want the added expense (and research) to find a good LiPo fit. Where did you get your LiPo? You have a 3S, I'd need a 6S.
You use 3S2P ? I don't like paralleling batteries, unless they're well matched (by factory).
Actually I'd need 24V and 12V batteries (12V for ITX). Might save some weight!
Consider using this power supply for the ITX: http://www.mini-box.com/M3-ATX-HV-DC-DC-ATX-Automotive-Computer-car...
My unit came from there.
Then you would only need one battery. My 'bot is running on a 7.4v 3200 mAh LiPo. I will needed something larger but it was what I could get locally. I identified a 10000 mAh battery but have not purchased it.
I've got the DN2800MT Mini-ITX, it doesn't need a DC-DC converter!
I can run 8 - 19V into it. I might get a 4S x 5000 mAh LiPo for it. (14V).
I might try to find a 24V to 12V DC-DC converter, that would save weight.
What is the status of your backup parameter. My rover needs to backup to as many waypoints or it does going forward.
In general I think adding reverse support is a really important item on the way to more advanced navigation.
But there is really a problem here and the Problem I see is Rover versus Robot.
At this point a robot is sort of a general catchall concept for a machine that can do anything you might want it to.
But our definition of a "rover" is a machine specifically oriented towards navigating a "course" based on GPS coordinates.
Lately it has had very primitive object avoidance capability added which gives it the ability to steer away from an imminent obstacle.
But the reality is that as soon as you introduce reverse (except for a kind of "dancing" move) you are getting into the realm of needing more sophisticated ground/environment relative navigation in order to use it sensibly.
Ostensibly you could have it back up on purpose for a specific move.
But more likely you are going to want to use it as part of the obstacle avoidance capability and as it is now, you'd really need to back straight up a short distance only to avoid any potential reverse obstacle conflict (because no sensors behind).
To me the bottom line is yes it is a good idea to put in a simple reverse capability as you have described (with an enable parameter).
Possibly for now to produce a driver instituted reverse in auto mode what you would do (in manual drive record waypoint mode) is require that every direction reverse requires stopping at a waypoint (and recording it) then departing from that waypoint in reverse (to the next waypoint) which you would then depart from in a forward direction.
The direction of throttle stick motion leaving a given waypoint would determine if that (leg) was in forward or reverse.
This could actually make for some quite interesting, innovative and fun driving.
As we progress into more sophisticated environment relative based navigation reverse will be mandatory, but this might be a great start.
Also it might be reasonable to have a full auto reverse capability instituted by the obstacle avoidance system where the car automatically backs straight up (a user settable parameter distance) and then attempts to go forward again.
But I can see that being problematic, because you would still be relying on the primitive dual sonar object avoidance to somehow make sense out of how to proceed.
I guess basically this could help if you approach a barrier too fast to be able to correct in time.
One last think, on vehicles with reverse it would be really nice if we could ensure that even if the APM or Pixhawk "crashes" that it goes to a PWM 1500 for throttle (much safer for all involved) otherwise it can end up going full speed in reverse.
Of course, not sure how you tell a crashed flight controller to do anything, so just a thought.
Basically it usually self reboots and goes to default zero throttle PWM out and that is what needs to be able to be set to 1500 on the controller for reversable vehicles (by setting a user parameter).
On my system I have switched steering to the left stick and throttle to the right stick so I can use the self centering throttle stick to shift easily between forward and reverse.
I think this should at least be a viable (perhaps parameter selectable) option.
Clearly it is more important to get the purposeful user selected reverse mode working than any sort of object avoidance mode that used it at this time, clearly that second one is going to be a major can of worms and may well not be worth implementing till we have a much higher resolution environmental detection system operational.
Although even really stupid things like the Roomba do pretty well with the short reverse turn then try forward again trick. (that might be worth implementing.)
Gary you mention the Roomba.... doesn't it use a short distance backup to return to its base for recharging? I am hoping to give my rover the same capability.
I realize there are more pressing matters, but what is the latest regarding reverse? I'm happy to try your beta if and when it becomes available.
youre right were having some trouble while hunting a bug right now but during the first round Tridge and Paul have now added a few things to the code to get support for backwards moving vehicles on the way.
What is the current status of the reverse? What can I do to help with those new "few things"?
Many thanks for all your efforts
Unfortunately our programmer, Andrew Tridgell, has been involved in other activities and will not be available until some time in the future.
Therefore ArduRover2 firmware updates will be at a standstill until he becomes available to do the necessary programming.
TCIII ArduRover2 Developer