dead reckoning / position control

agfa

I have some questions about robot positioning, for the purpose of dead reckoning. More specifically how to stop my bot at a predetermined angle while performing a zero turn radius. I have a differential drive chassis with PM motors. I vary the motor drive with PWM. I’ve added encoders (tachs) to the motors, an effort to drive it in a straight line, compensating for changing battery levels, differences in the drive train, and different surfaces surface textures. I’ve had pretty good success with starting the bot and maintaining a path, but I can’t consistently stop the bot. I’ve incorporated a PI loop with ramping, and braking·to accomplish this.

I’ve tried turning in a radius while driving motors at different speeds, which works quite well. Though I haven’t been very successful at determining position with this type of maneuver.

The methods I’ve tried for stopping have been free wheel coasting, ramping down, and braking. Free wheel coasting is a "Smile shoot", ramping down, basically a controlled coast, performed a little better, and braking proved to work the best.

The braking techniques I’ve tried are to drive the wheels in reverse using a proportional feedback loop increasing the braking the closer I got to the goal and, I’ve also tried decreasing the braking the closer I got. Both of these worked about the same.

No matter what I’ve tried performance is still effected by battery level, and surface texture. I was hoping someone could point me in the right direction on how to overcome these differences.

agfa

W9GFO

How are you making use of the encoders? It doesn't seem like you are controlling the motors based upon the encoder counts.

What microcontroller are you using?

Rich H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Servo Boss, a 12 channel servo tester kit from Gadget Gangster.

agfa

I'm using a propeller.· I use a counter to generate a count, I vary the count rate and·use this value from the counter as a reference.· I use the difference of the counter and the actual encoder count as an error to plug in to the PI loop.· It works quite well when ramping up, and maintaining a desired speed, while maintaining a straight·path or a accurate zero radius turn.

I first tried using the speed of the motors as feedback, but it wouldn't maintain a straight path until the motors were up to speed.· I would welcome any suggestions on better/alternate methods of feedback control.

Thanks

Post Edited (agfa) : 9/27/2009 5:57:31 PM GMT

kwinn

It sounds like you are using the best method of feedback and position control possible for the hardware you have.

The error resulting from surface texture is most likely due to wheel slippage and is very difficult to compensate for. What is needed is a system that will provide precise position and orientation which unfortunately is very difficult. We have our vision which works very well for those tasks and I think something similar is needed for a robot.

The battery level problem may be simpler to deal with. A regulator and/or different PID loop values may take care of that.

agfa

Thanks for the reply.

I hadn't considered wheel slippage.· I was thinking more along the lines of the rougher texture (carpet) creating more drag on the drive system than a smooth surface.· I can get pretty good results by adjusting the braking gain for the particular texture its on at the time, but when the texture changes I have to readjust.· I·will try to find a way to determine the drag and compensate.· When I first started on this project I thought the feedback loop would be more immune to these varying conditions.· I remember, now that I type this, reading a·thread·that mentioned·a bot that could·detect the direction of carpet nap.· I'll do some searching.

Thanks again.

agfa

LilDi

Concerning the ramp up issue, a lot of brush motors don't have the same torque when running in reverse. Depending on where the armature is with respect to the brushes, at startup, can vary the ramp up speed even on the same motor. You can buy motors that specifically state they are for forward & reverse use. Stepping motors work real good at preventing ramp up differencees. The floor texture problem is a very difficult one to solve. Most everyone is still working on that one.

erco

Lots of mechanical variables in a diff-drive chassis.

Insufficient gear reduction ratio is often the culprit when the wheels won't operate consistently. Always better to have more torque than speed for precision maneuvers. Can you adjust this, or use smaller wheels?

Also, wider wheels introduce errors. Use the thinnest tire you can get. A thin disk wheel would be great, but it's not practical to run on an O-ring tire.

If you are using simple casters on the front and rear of your chassis, they skid a little bit every time they change direction. This can introduce odometry errors. Sometimes you have to introduce a fudge factor for this, based on the last direction of travel.

Finally, go as slowly as possible for a precision turn to minimize wheel slippage due to acceration & deceleration.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Whit

agfa said...
I have some questions about robot positioning, for the purpose of dead reckoning. More specifically how to stop my bot at a predetermined angle while performing a zero turn radius.

agfa,

Since you are using the Propeller, might the addition of a compass help with the stop at a predetermined angle while performing a zero turn radius? It might give you some more information on which to base your stop point. It could even be used to correct the positon made by other calculations. This info would also be independent of wheel·slipping and measure the angle·of rotation from the previous heading.·

The Hitachi HM55B Compass Module that Parallax sells - http://www.parallax.com/Store/Sensors/CompassGPS/tabid/173/CategoryID/48/List/0/Level/a/ProductID/98/Default.aspx?SortField=ProductName%2cProductName·is accurate to about 5 and a half degrees (if I am calculating correctly) and has some objects already written in the OBEX.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+


"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney

Post Edited (Whit) : 9/28/2009 7:54:27 PM GMT

erco

One accuracy trick I learned with my Scribbler encoder project is to NOT do zero radius turns. Locking one motor eliminates one variable, so I just drove one motor and pivoted around the fixed wheel. This definitely led to better results in final positioning.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

agfa

I'm probably expecting too much the hardware I have.· It had met all my expectations until I got to this point.· I'm using a toy dual motor drive gear box, I think its·called a Big Tracks, with DIY motor encoders.

LilDi,· ·I'm sure these toy motors are creating a lot of inconsistencies.· As for the carpet, I'll avoid it and stick to the hardwood floor.

erco,· I think your dead on.· I think most of what I'm fighting is a lack of·torque.

Whit,· I had looked at the compass, but was hoping for more resolution.

Thanks for all the good suggestions.

agfa

erco

Yikes! If Whit is correct in his statement about 5.5 degrees accuracy in that compass, that's REALLY bad; especially if you try to use that data alone to try to get from A to B. One or two degrees off will add up to serious position error after a few feet and a few turns. Couple that with the inconsistencies of sonar, Sharp IR distance measurement, and other fair-weather sensors, and it's pretty miraculous that we get even minor successes in the art of robotics. It's not quite science yet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

kwinn

agfa, if you are using the encoders to determine position I would not think that torque or lack of it would have much effect on the measured position. It may not get to the position you wanted it to be at, but the position calculated from the encoder should be very close to the actual position unless there has been some slippage between the encoders and the surface the unit is traveling over.

erco

Agfa: Please attach a photo of your chassis. Are you talking about the 6-wheeled Milton Bradley "Big Trak" from the 1980s, or perhaps a treaded platform? Both of these have enormous scrubbing actions while turning which will result in gross odometry·errors compared to a simple simple 2-wheel drive platform like a BoeBot or Scribbler. Any gear/wheel backlash or wear·(slop) will add to your problems. To have any chance of good accuracy & repeatability, you must always start with a solid, strong, stiff chassis with lots of torque and tight transmissions (gearmotors). For dead reckoning, all the sensors in world can't begin to compensate for a loosey-goosey chassis.

Can you tell I'm a mechanical engineer?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

LilDi

This device is probably way off base, but in case it isn't.

http://www.globalspec.com/FeaturedProducts/Detail/MicroEpsilon/ILD1402_Triangulation_Displacement_Sensor/39610/1?md=090929&mh=2e2f38&Vol=Vol9Issue39&Pub=1&LinkId=496124&keyword=link%5F496124&vid=1780&email=gbrusseau%40spokanecity%2Eorg&uh=c2a365&id=%2D398954610&frmtrk=newsletter

I did not read up on it. I'll leave that for you.

agfa

kwinn,· Yes, I was trying to get to specific position.· The actual position, based on the encoder input, appears accurate.· I am testing the amount of slippage by measuring·rotation·at the wheels, along with bot position.· Slippage dosn't appear to be the cause of the errors I am experiencing.

erco,· I believe it is the Big Trak you mention, it does have a Milton Bradley label, but its just the dual gearbox·with wheels.· There is a·small amount of backlash/slop, but I don't think its a significant cause of my errors.· I put rubber bands on the wheels, hoping it would·isolate most of the traction·to the center of the tread.· It seems to help a little.

LilDi,· Thanks for the link.· I will read up on it later.

I've attached a pic of the gearbox alone, and one with it's wheels.

Post Edited (agfa) : 9/29/2009 11:40:00 PM GMT

LilDi

Who are all your little buddies in the background. They don't look well....

W9GFO

I think the Big Trak has just one encoder and only counts wheel revolutions. There is a magnetic "clutch" inside the gearbox that is intended to keep the wheels in sync, yet allow them to turn separately when pivoting. Did you disable the clutch?

Rich H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Servo Boss, a 12 channel servo tester kit from Gadget Gangster.

agfa

I have disabled the clutch, and added encoders(tachs) to the motors.· Encoder resolution is 170·pulses·per wheel revolution.

Post Edited (agfa) : 9/30/2009 4:37:20 AM GMT

erco

You are definitely undergeared. Those wheels are significantly bigger & heavier than the cheap plastic wheels that came on the Big Trak. They are like flywheels, and have lots of rotational momentum to overcome when accelerating & decelerating. I'm guessing you're also getting chassis flex and axle flex, which is not helping your odometry efforts. IMHO you would do better with smaller lightweight wheels. Stroller or lawnmover wheels might work, you want the smallest, lightest·& narrowest wheels possible, with rubber tires.·Your motor module should be almost scraping the ground with minimum ground clearance. Lowering everything down also drops your CG to increase stability, which will lead to improved accuracy & repeatability.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Post Edited (erco) : 9/30/2009 4:23:35 PM GMT

erco

So you're not using the encoder disks on your wheels in the photo? They sure aren't giving 170 eps per revolution.· Speaking of eps, have you seen PhiPi's excellent writeup at··http://www.parallax.com/dl/docs/prod/datast/ApplyEncoder.pdf ?

Also see my Scribbler encoder thread at http://forums.parallax.com/showthread.php?p=772850

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

SailerMan

I got this from seattle robotics years ago... It was easy to port to the propeller.

Take a look... It is designed for differential Drive robots.

/***********************************************************/
/* odometer.c - Copyright (C) 2000, Dafydd Walters         */
/***********************************************************/


/********************/
/* define constants */
/********************/

/* User defined constants */
#define WHEEL_DIAMETER 0.069
#define PULSES_PER_REVOLUTION 48.0
#define AXLE_LENGTH 0.125

/* Fixed constants */
#define PI 3.14159


/*********************/
/* define structures */
/*********************/

struct position
{
  float x;        /* meter */
  float y;        /* meter */
  float theta;    /* radian (counterclockwise from x-axis) */
};


/********************/
/* global variables */
/********************/

struct position current_position;


/********************/
/* define functions */
/********************/

void initialize_odometry()
{
  current_position.x = 0.0;
  current_position.y = 0.0;
  current_position.theta = 0.0;
}


void odometer_thread()
{
  float dist_left;
  float dist_right;
  int left_ticks;
  int right_ticks;
  float expr1;
  float cos_current;
  float sin_current;
  float right_minus_left;
  float MUL_COUNT;

  MUL_COUNT  = PI * WHEEL_DIAMETER / PULSES_PER_REVOLUTION;

  while(1)
  {
    enable_interrupts(0);         /* Ensure we don't lose any odometer counts */
    left_ticks = left_count;
    right_ticks = right_count;
    left_count = 0;
    right_count = 0;
    enable_interrupts(1);

    dist_left = (float)left_ticks * MUL_COUNT;
    dist_right = (float)right_ticks * MUL_COUNT;

    cos_current = cos(current_position.theta);
    sin_current = sin(current_position.theta);

    if (left_ticks == right_ticks)
    {
      /* Moving in a straight line */
      current_position.x += dist_left * cos_current;
      current_position.y += dist_left * sin_current;
    }
    else
    {
      /* Moving in an arc */
      expr1 = AXLE_LENGTH * (dist_right + dist_left)
              / 2.0 / (dist_right - dist_left);

      right_minus_left = dist_right - dist_left;

      current_position.x += expr1 * (sin(right_minus_left /
                            AXLE_LENGTH + current_position.theta) - sin_current);

      current_position.y -= expr1 * (cos(right_minus_left /
                            AXLE_LENGTH + current_position.theta) - cos_current);

      /* Calculate new orientation */
      current_position.theta += right_minus_left / AXLE_LENGTH;

      /* Keep in the range -PI to +PI */
      while(current_position.theta > PI)
        current_position.theta -= (2.0*PI);
      while(current_position.theta < -PI) 
        current_position.theta += (2.0*PI); 
    } 

    sleep(0.1); 
  } 
}

agfa

Thanks to everyone for·the replies, suggestions, and insight.· I have some new ideas to try.

erco,· I·enjoyed reading·that thread, and· I will re-read Phil's write-up.· I have taken steps to minimize chassis and axle flex.· I agree with you, not enough torque and flywheel like wheels.· I have had pretty good success with ramping up and down, but I just couldn't·stop with·the positional accuracy I was shooting for.· Kwinn pointed out that, even though I couldn't get the desired stop·position, I still have the actual position indicated by the encoders.· I want to see if I can use that.· Thanks again. ·I do appreciate your time.

Kwinn,· Thanks

SailerMan,· Thanks, looks like good stuff.· I will try to digest it.· Would you be willing to·share·your ported results?

Thanks again.

erco

One last thought is that you are using motor encoders instead of wheel encoders. There is always some backlash (slop) even in the best transmission. Even if you stop your·motors or intermediate gears in the exact right location,·all that·backlash·getting down to the wheels introduces position uncertainty, which shows up in distance and turn accuracy. I prefer medium-resolution encoders right on the wheels, which is the most direct method of feedback. You already have low-res encoder disks on your wheels in the photos. I have had good results with differential and tricycle-drive robots using black/white encoder stripes each·~1/8" wide, read with a Hammamatsu IR reflectance sensor. Even my Scribbler's BS2·can keep up with counting pulses at moderate speeds, as seen in·the video at http://www.youtube.com/watch?v=5r2En4hLUBI·. This video also shows the Scribbler making non-zero radius turns on the fly·(mentioned previously)·by·simply stopping·one wheel instead of reversing it. This robot doesn't use ramping or dynamic braking, just a "zero speed" command sent to the inside wheel and a fixed speed to the outside wheel. By counting & comparing encoder pulses, she knows when the turn is finished and returns to "drive straight" mode.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Sandgroper

I had problems using a zero speed approach for differential drive.· Zero speed means it takes a while for the wheel to come to a stop, which·produces a skewed curve.· The radius of the curve depends on how long it takes the wheel to come to a stop.

You mentioned that·you've catered for different surfaces.··Was this for straight-line speed, or for differential turning based on rolling resistance?··If the surface·has relatively low rolling resistance, the driving wheel will tend to push the 'bot forward, resulting in a larger turn radius.· On the other hand, a surface with a high rolling resistance (e.g. carpet) partially brakes the free wheel, causing the 'bot to change direction more quickly.· The·surface type can affect the turn radius.·

The amount of lateral force required·to turn the robot makes a difference too.· If, for instance, the centre of gravity is more towards the front castor and not over the drive axle, it will take longer for the robot to change direction.··In effect it acts like a horizontal fly wheel.· The same applies if the C of G is left or right of the centre line, in which case the turn radius on one side will be different to the other.

If the front castor doesn't pivot freely it·too will affect the turn radius.· The harder it is to deflect, the larger the turn will be.

Braking the inside wheel reduces a lot of the variables.··The robot will be more responsive than if the inside wheel is allowed to coast.· Also, the momentum of the robot coupled with the braking assists the turn.

Reversing the direction of the inside wheel will make the 'bot more·turn more quickly, but·it causes excessive wear & tear on the drive train.·

Sandgroper

If the steering doesn't perform well until the motors are up to speed, a little more power might do the trick.

You could try starting the acceleration loop at a higher count. When both motors ramp up from zero, one motor will overcome inertia before the other. This causes the robot to wander on startup. Start ramping up from a higher value so that both motors begin turning at the same time.

erco

Great PID info at http://www.seattlerobotics.org/encoder/200108/using_a_pid.html

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

agfa

Thanks Sandgroper, I appreciate your replies.

You mention problems with "zero speed approach".· Did you change your approach to deal with this, such as braking instead of zero speed, or did you find a way to better deal with it?· The biggest inconsistencies I've noticed were all with controlling deceleration, whether coasting, ramping down, or braking.· I was under· the impression that the use of a good feedback method to either brake of ramp down would overcome the effects of different surface textures, battery levels,·and different maneuvers.· I thought that because, it appears to me, that it·overcomes them in acceleration and maintaining a fixed speed.

Through the process of··troubleshooting the cause of my inconsistencies, I removed as many of the variables that I could.· I tried reducing the effects of slippage by measuring wheel rotations instead of distance traveled.· I resorted to testing only on a smooth surface instead of multiple surfaces.· I made my observations and adjustments on one type of move at a time.· First with straight line moves, then zero radius turns, and finally with "differential turns".

I hadn't considered the effect that CG would have, but now that you mention it, I've noticed, what appears to me, as more inertia when performing a stop in a zero·radius turn, than a straight line stop.· I'm assuming this is due to "the horizontal flywheel effect".·

I tried the method you suggested of starting the loop at a higher count.· It seems to have the opposite effect for me.· When I tried It, I get uneven motor acceleration, I think because the differences in drag in the motors and drive train that when the loop starts it·accelerates the motors beyond the control of the loop.· I don't know.· It makes me question my method of PID (PI).· Motor startup was one of my biggest hurtles.· If I don't ramp up I get feedback oscillations.· If I lower the gains to minimize the oscillations then I don't get enough control of motor speed.

The more I work with this the more difficult it becomes.· But I am enjoying it.

erco,· the link to the write-up on PID based odometry·was one of my inspirations to implement PID.· I am impressed with the accuracy that you got with your scribbler in the video.· My attempts at odometry with lower res wheel encoding was not nearly as successful.· Just more reinforcement that the problems I'm having are with my methods, not the mechanical variables.

agfa

Sandgroper

The·problem I had with a zero speed approach was a simple one.··My project is to get my trike to navigate from a set origin in one room to a set destination in another while carrying a full cup of coffee - without spilling it.· To do this I'm using wall following coupled with very basic odometry.· I haven't had to implement PID because the robot relies on the walls·for direction and sonar coupled with landmarks for resetting distances.· There are separate encoders on each motor and the distances are averaged.· The robot uses a variety of techniques for finding, acquiring and orientating itself to different walls.

If I use·zero speed turns, the robot isn't responsive enough to negotiate 90·degree turns through doorways at corners.· It under steers.· This·causes it to skip across narrow doorways in straight walls instead of cornering through them.· It also causes it to drift too close to the wall when navigating· internal corners, and drift·away from the wall when navigating external corners.· The effect is almost doubled when executing two external corners, e.g. turning 180 degrees around the end of·100 mm wide nib wall.

I use active braking of the inside wheel to make the robot stick to the walls.··To solve the·cumulative distance errors,· I reset the·robot's distance variables at a suitable internal corner.··The robot only needs three or four waypoints for each "journey" when wall following.· If the last waypoint is, for instance, 5 metres, I·code the 'bot to travel 4.5 metres and then stop at the next internal·corner.· This method allows the robot to achieve its objective without the need for high precision.· It also·saves a heap of code, which leaves more space for memory maps.

Without PID control or deadband, my trike ripples along the wall because the motors are simply on / off. That means spillage.· I "solved" that problem by reducing the speed a little and placing the coffee cup over the centre point between the two drive wheels.··Very unsophisticated but it works.

Zero speed turns (or more accurately, differential velocity turns) do have some advantages over active braking.· The course corrections are smoother and the average speed is higher.· I found I could get the best of both worlds by combining zero speed turns for straight line travel and active braking for 90 degree corners.· Unfortunately it came at the expense of·program memory because every corner·had to be coded into the waypoints.· There wasn't enough memory left over for creating the necessary "maps" for navigating between multiple end points.

I'm not quite sure what you mean by "it accelerates the motors beyong the·control·of the loop".· I have the inital pulse set so that it's just below the level required to turn the motors.· It still ramps up and down as normal, only it doesn't start from a zero pulse width on the first pass.··I·found that the·robot didn't move until the pulse width got to a certain level.· All I did was set the inital pulse to just below·that.· Maybe there's some flex or torquing in the·drive train?