Replies to This Discussion

AdminPermalink Reply by Thomas J Coyle III on November 28, 2012 at 5:12am

Hi Tridge,

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.

Regards,

TCIII

DeveloperPermalink Reply by R_Lefebvre on November 28, 2012 at 5:46am

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.

AdminPermalink Reply by Thomas J Coyle III on November 28, 2012 at 6:24am

My CC Mamba Monster ESC requires 2 sec of no motion to be able to go into reverse if reverse is enabled.

Regards,

TCIII

Permalink Reply by zach w on November 28, 2012 at 6:48am

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.

Attachments:

• lines.zip, 30 KB

DeveloperPermalink Reply by R_Lefebvre on November 28, 2012 at 7:24am

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.

DeveloperPermalink Reply by Linus on November 28, 2012 at 6:51am

Hi Tridge,

I would let my Rover better to drive forward only.

maybe you could do reverse as optional. that would be great.

Regards,

Linus

Permalink Reply by John Hestness on November 28, 2012 at 7:05am

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.  

Permalink Reply by Derek on November 28, 2012 at 8:37am

Hi,

Just some thoughts on reversing.

• Driving Remotely by Camera - you would need to pan 180 to follow the reverse path and then steer the wheels in reverse mode.
• Loss of GPS - on trails, canyons, in wooded country makes the use of the heading and speed recordings for dead reckoning more important features.
• Different vehicle type AGV's - articulated vehicles, vehicles pulling trailers, 4 wheel drive, Rock Crawlers etc need different handling.

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?

Kind Regards,

Derek 

Permalink Reply by John Hestness on November 28, 2012 at 9:46am

Most of the Traxxas ESC's will apply a nice smooth braking action if you give a forward command while moving backward or a backward command while moving forward. If you hold that command until you stop then you have to go to the neutral position briefly before you can move again. In other words the ESC will prevent you from grinding the gears.

Permalink Reply by KM6VV on November 28, 2012 at 11:36am

@Andrew,

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:

rough

garden

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.  

Alan

AdminPermalink Reply by Thomas J Coyle III on November 28, 2012 at 12:25pm

@Alan,

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.

Regards,

TCIII

Permalink Reply by KM6VV on November 28, 2012 at 1:02pm

@Thomas,

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.

Alan

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page