This is rather frustrating - the thing spins right faster than it spins left and the calculated distance for a 180 degree spin is not double that for a 90 degree and a
45 degree spin distance is not half the 90 degree...
There is no consistency or proportional response happening here! Servos are so much easier to deal with.
@Ron: When in doubt: slow down, use dynamic braking, and add plywood!
Doing one-motor turns (leave one motor stopped and pivot around that) slows everything down and makes things easier than 2-motor turns (pivot in place).
But you knew that!
Let's see up & back 4 times, and see how close you get to the original position. Say the word and I'll bust out my Retrobot so we can have a Stamp/Prop shootout!
@Ron: When in doubt: slow down, use dynamic braking, and add plywood!
Doing one-motor turns (leave one motor stopped and pivot around that) slows everything down and makes things easier than 2-motor turns (pivot in place).
But you knew that!
Let's see up & back 4 times, and see how close you get to the original position. Say the word and I'll bust out my Retrobot so we can have a Stamp/Prop shootout!
erco,
My spin turns are much better but I also programmed a different sort of turn - instead of pivoting on one stopped wheel, I pivot on one stopped wheel and then pivot on the opposite wheel in reverse to complete the turn - kind of "swagger" turn.
It is pretty accurate. In this video I turn 45 degrees left then right, 90 degrees left then right, 135 degrees left then right and 180 degrees left then right.
Then it makes a little forward trip and back using the "swagger" turns...
Very nice Ron! Great looking bot, and accurate moves.
I have a question for anyone who would like to chime in. There seems to be a lot of focus on accurate stopping, for the sake of dead rekoning. Is it to reduce accumalative errors when navigating using a method such as: 1st move forward a set distance then stop, 2nd move turn 180 degrees then stop, 3rd move forward a set distance hopefully returning and stopping at your beginning location?
I like the swagger! Great results and a great looking bot!
Thanks Whit!
It is still a little frustrating because I had to use a table of values for specific degrees because the encoder counts are not proportional:
e.g. 45 degrees=750, 90 degrees=1720, 180 degrees=3640
I'm confident that the Quadrature Encoder object is accurately counting the pulses (3200 per wheel revolution) but I can't really explain why the relationship isn't linear...
It does appear to be linear. You may be fighting coast. If your shutting off the motors then coasting to the desired position that would explain the values that you are getting. If you take the 1720 (90 degrees) and 750 (45 degrees) the difference is 970. Using 970 as a 45 degree reference then you have a relatively consistent error of 220 to 240 tics.
That could be confirmed by resampling your encoder count values after the bot comes to a complete stop.
It does appear to be linear. You may be fighting coast.
agfa,
Coast is not the issue. The Pololu driver board lets you drive the H-Bridge in two modes drive/coast or drive/brake. I am using the drive/brake method.
Also, you may notice the four digit/seven segment display on the robot's bread board.
It displays the encoder counts at the end of the move. It is rarely off by more than a few counts which is insignficant when a one millimeter move generates roughly 8 ticks.
This spreadsheet shows the pulse counts for various angles. The "per degree" column shows how non-linear the results are.
I use this board marked with lines at various angles for testing turns
That's great Ron. It was just a suggestion because I had fought it. I did a quick graph and it appeared to be linear.
agfa,
I did have a coast problem early on before I discovered that I was using the wrong method on the Pololu board. I guess there are various mechanical factors coming into play here.
For example, on turns, is the wheel pivoting on the exact center of the wheel or the edge - or is it variable. Then you have play in the gears, wheel slippage, inertia, etc...
As erco stated, accuracy is improved when driving one wheel at a time in turning situations.
Am I expecting too much? This latest video shows it making a couple of 50"x15" rectangles, but it obviously gets off a little on a relatively smooth concrete floor.
Haven't tried it on a rough driveway but it is pathetic on thick carpet.
I think you did a pretty good job, myself. You may be able to fine tune it, and get closer, navigating a specific route. When you change the route things may change. The bots I played with had a lot of back lash, so I thought any maneuver that including stopping and/or reversing, maybe even braking, increased the errors. My goal became to use forward slow turning maneuvers without any stops or reversing and to use other navigation techniques such as using a compass, position triangulation, or wall following.
Keep posting your progress, I think your doing a great job.
The bots I played with had a lot of back lash, so I thought any maneuver that including stopping and/or reversing, maybe even braking, increased the errors. My goal became to use forward slow turning maneuvers without any stops or reversing and to use other navigation techniques such as using a compass, position triangulation, or wall following.
There certainly are a lot of factors at work. There is some wheel wobble, play in the gears, inertia, surface irregularities...
A lot more to it than I anticipated. I want to get a certain level of consistency and then move on to adding sensors, etc
Ron: Looks great to me! Even if it's off slightly in the end, does it end up in the same spot each time? I still say repeatability is more important & useful than hyper-accuracy for path following. I got very satisfactory results with my Retrorobot and software that recorded the path as I drove it with an IR remote, MUCH easier than hard-coding the path. http://www.youtube.com/watch?v=PX0IhUqnwrk
And I agree, lower speeds through more gear reduction are key to achieving repeatable results.
Ron, I thought that double rectangle path looked pretty good. Keep at it!
Frankly I've found repeatability and calibration with the physical world to be the thorniest part of robotics. In the end there are always plenty of measured fudge factors I need to add because theory only goes so far.
Ron, I thought that double rectangle path looked pretty good. Keep at it!
Frankly I've found repeatability and calibration with the physical world to be the thorniest part of robotics. In the end there are always plenty of measured fudge factors I need to add because theory only goes so far.
Thanks! Ultimately it will be directed by sensors (Ping, IR distance sensors, etc) not programmed patterns but I figured I need get the basics figured out before delving into responding to sensors.
Actually, don't knock plain old dead reckoning. There was (still is) a sensorless robot named CYE that got around just fine by dead reckoning, occasionally reorienting itself against a wall or corner to zero out accumulated errors. Excellent repeatability for the year 1999.
I am with erco and agfa! Pretty darn good. I think that removing all error is pretty difficult - unless you had a very heavy, very slow moving robot - so that there was no slipping or chatter at all. Keep striving for something better, but what you've achieved is impressive.
I've made some progress - I attached a Ping and two Sharp IR Distance sensors with double sided tape. An MCP3202 A/D converter is used to read the Sharp sensors analog output.
The program starts a separate cog to monitor the sensors and sets three bits in a byte variable to indicate which sensors have detected an object ahead.
I had to place boxes, etc around because it keep closelining itself on my grass trimmer shaft and other hard to detect objects...
The program then makes a determination whether to make a 30, 45, 90 or 180 degree turn and of course, which direction. The Sharp sensors have trouble when reflecting off angled surfaces so I may replace them with Pings.
Here are some excerpts from the program:
repeat
sensors := CheckSensors
case sensors
0: Forward(12, 60) 'no sensors triggered
1:
stop
Spin_Right(deg30, 30) 'left sensor
waitms(pausetm)
4:
stop
Spin_left(deg30, 30) 'right sensor
waitms(pausetm)
2:
stop
Spin_Right(deg90, 30) 'Ping Center
waitms(pausetm)
3:
stop
Spin_right(deg45, 30) 'left and center
waitms(pausetm)
6:
stop
Spin_left(deg45, 30) 'right and center
waitms(pausetm)
5:
stop
Spin_Right(deg180, 30) 'left and right but not center ??
waitms(pausetm)
7:
stop
Spin_Right(deg180, 30) 'left, right and center
waitms(pausetm)
waitcnt(clkfreq / 500 + cnt)
PUB SensorCog | i, ticks, ch, t
'' runs in a separate cog
adc.init(CS, CLK, DIO) ' start adc driver
waitcnt(MS1 + cnt) ' let objects load
t := cnt
repeat
repeat ch from 0 to 1
SensDist[ch] := adc.read(ch, adc#SE) ' get channel value
SensDist[2] := ping.Inches(PING_Pin)
waitcnt(t += constant(MS1 * 100)) ' update every 100ms
PUB CheckSensors | Sensors
' returns value with bits 2..0 indicating which sensors have detected objects
Sensors := 0
if SensDist[0] > 1600 'left IR sets right bit
Sensors |= %001 'set bit 0
else
Sensors &= %110 'clear bit 0
if SensDist[1] > 1600 'right IR sets left bit
Sensors |= %100 'set bit 2
else
Sensors &= %011 'clear bit 2
if SensDist[2] < 16 'Ping sets center bit
Sensors |= %010 'set bit 1
else
Sensors &= %101 'clear bit 1
Seg7.tx(ClearScr)
Seg7.bin(Sensors, 3)
Return Sensors
Good effort, Ron. But don't stop there! I must admit, I don't "get" random roaming with pings or IR; I'm not convinced that it shows much technical mastery all by itself. Everybody's doin' it, but what's to gain? Short of hitting something, there's no accuracy requirement, no goal, no right or wrong. Your dead reckoning stuff was IMHO much more of an achievement.
Now having said that, combining this roaming detection with dead reckoning, THAT'S HUGE. Think of mapping a room and moving mainly from dead reckoning, but needing to detect and maneuver around some random objects, then get right back on track.
Easy to say, hard to do. Hey, I'd make a great Futurist! Soon these robots will be cooking scrambled eggs and bringing us breakfast in bed!
I must admit, I don't "get" random roaming with pings or IR; I'm not convinced that it shows much technical mastery all by itself. Everybody's doin' it, but what's to gain? Short of hitting something, there's no accuracy requirement, no goal, no right or wrong. Your dead reckoning stuff was IMHO much more of an achievement.
erco - I have similar opinions of line-following robots - how useful can that really be? OTOH, object recognition would be a neat (but expensive) avenue to explore...
Since this is my first robot (since my BOE-BOT from early 2000) I am just trying to learn and experiment with no specific goal in mind. I have considered adding an XBEE, NetCam, robotic arm, etc but really don't know what direction I'll take.
I can't really afford to throw a lot of money at it unless I want to come out of retirement - and then I wouldn't have as much time to tinker.
Agreed on line following. I hope I didn't sound too critical, you're doing great work and I'm enjoying your thread. All these technologies are useful in various ways. Useful navigation is an incredibly complex task, made up of many little parts (dead reckoning, object detection & avoidance, path planning, etc), and it is definitely important to understand each one's place in the big scheme. A fairly overwhelming task. But just like Bill Gates & Windows, we gotta start somewhere! Keep up the good work!
I'm following your homemade Stingray with renewed interest... great work! My newest project, Orville, is using the prop board, motors and wheels from the Stingray albeit in a somewhat different configuration. I suspect I'll be dealing with some of the same problems as you.
#erco - I agree with your thoughts on navigation. I will admit it's still fun to watch Bob wander around the house and try to get out of various predicaments, but there is much more potential to be tapped. Obstacle avoidance is fine, but not if that's the only goal. There's a difference between going anywhere and not running into things and going =somewhere= and not running into things.
I have a pair of similar Pololu motors but mine are 100 RPM with encoders.
Could you please post your code?
I would like to know how you wired encoders, and how you are reading them with the Propeller.
Thanks,
zappman
The encoder wires are connected directly to Propeller pins 4 thru 7. I use the Quadrature_Encoder object to read them using the ReadDelta method.
I haven't looked at the code in a while but I am attaching the latest version which uses a Ping and two Sharp sensors to roam without bumping into objects.
Comments
Darn erco you jinxed me! (just kidding)
This is rather frustrating - the thing spins right faster than it spins left and the calculated distance for a 180 degree spin is not double that for a 90 degree and a
45 degree spin distance is not half the 90 degree...
There is no consistency or proportional response happening here! Servos are so much easier to deal with.
Doing one-motor turns (leave one motor stopped and pivot around that) slows everything down and makes things easier than 2-motor turns (pivot in place).
But you knew that!
Let's see up & back 4 times, and see how close you get to the original position. Say the word and I'll bust out my Retrobot so we can have a Stamp/Prop shootout!
erco,
My spin turns are much better but I also programmed a different sort of turn - instead of pivoting on one stopped wheel, I pivot on one stopped wheel and then pivot on the opposite wheel in reverse to complete the turn - kind of "swagger" turn.
It is pretty accurate. In this video I turn 45 degrees left then right, 90 degrees left then right, 135 degrees left then right and 180 degrees left then right.
Then it makes a little forward trip and back using the "swagger" turns...
Seriously, very good results!
I have a question for anyone who would like to chime in. There seems to be a lot of focus on accurate stopping, for the sake of dead rekoning. Is it to reduce accumalative errors when navigating using a method such as: 1st move forward a set distance then stop, 2nd move turn 180 degrees then stop, 3rd move forward a set distance hopefully returning and stopping at your beginning location?
It is still a little frustrating because I had to use a table of values for specific degrees because the encoder counts are not proportional:
e.g. 45 degrees=750, 90 degrees=1720, 180 degrees=3640
I'm confident that the Quadrature Encoder object is accurately counting the pulses (3200 per wheel revolution) but I can't really explain why the relationship isn't linear...
It does appear to be linear. You may be fighting coast. If your shutting off the motors then coasting to the desired position that would explain the values that you are getting. If you take the 1720 (90 degrees) and 750 (45 degrees) the difference is 970. Using 970 as a 45 degree reference then you have a relatively consistent error of 220 to 240 tics.
That could be confirmed by resampling your encoder count values after the bot comes to a complete stop.
agfa,
Coast is not the issue. The Pololu driver board lets you drive the H-Bridge in two modes drive/coast or drive/brake. I am using the drive/brake method.
Also, you may notice the four digit/seven segment display on the robot's bread board.
It displays the encoder counts at the end of the move. It is rarely off by more than a few counts which is insignficant when a one millimeter move generates roughly 8 ticks.
This spreadsheet shows the pulse counts for various angles. The "per degree" column shows how non-linear the results are.
I use this board marked with lines at various angles for testing turns
agfa,
I did have a coast problem early on before I discovered that I was using the wrong method on the Pololu board. I guess there are various mechanical factors coming into play here.
For example, on turns, is the wheel pivoting on the exact center of the wheel or the edge - or is it variable. Then you have play in the gears, wheel slippage, inertia, etc...
As erco stated, accuracy is improved when driving one wheel at a time in turning situations.
Haven't tried it on a rough driveway but it is pathetic on thick carpet.
It's not like I expect it to compare to a da Vinci surgical robot but...
I am ramping the speed up and down on straight runs and it is pretty precise.
I am using 50% PWM duty on the straight runs.
Turns are still bothersome - too slow can be worse than too fast. Maybe I should have bought a higher gear ratio (these are 50:1 250rpm).
I think you did a pretty good job, myself. You may be able to fine tune it, and get closer, navigating a specific route. When you change the route things may change. The bots I played with had a lot of back lash, so I thought any maneuver that including stopping and/or reversing, maybe even braking, increased the errors. My goal became to use forward slow turning maneuvers without any stops or reversing and to use other navigation techniques such as using a compass, position triangulation, or wall following.
Keep posting your progress, I think your doing a great job.
There certainly are a lot of factors at work. There is some wheel wobble, play in the gears, inertia, surface irregularities...
A lot more to it than I anticipated. I want to get a certain level of consistency and then move on to adding sensors, etc
And I agree, lower speeds through more gear reduction are key to achieving repeatable results.
Frankly I've found repeatability and calibration with the physical world to be the thorniest part of robotics. In the end there are always plenty of measured fudge factors I need to add because theory only goes so far.
Thanks! Ultimately it will be directed by sensors (Ping, IR distance sensors, etc) not programmed patterns but I figured I need get the basics figured out before delving into responding to sensors.
http://www.personalrobots.com/home.html
I am with erco and agfa! Pretty darn good. I think that removing all error is pretty difficult - unless you had a very heavy, very slow moving robot - so that there was no slipping or chatter at all. Keep striving for something better, but what you've achieved is impressive.
The program starts a separate cog to monitor the sensors and sets three bits in a byte variable to indicate which sensors have detected an object ahead.
I had to place boxes, etc around because it keep closelining itself on my grass trimmer shaft and other hard to detect objects...
The program then makes a determination whether to make a 30, 45, 90 or 180 degree turn and of course, which direction. The Sharp sensors have trouble when reflecting off angled surfaces so I may replace them with Pings.
Here are some excerpts from the program:
repeat sensors := CheckSensors case sensors 0: Forward(12, 60) 'no sensors triggered 1: stop Spin_Right(deg30, 30) 'left sensor waitms(pausetm) 4: stop Spin_left(deg30, 30) 'right sensor waitms(pausetm) 2: stop Spin_Right(deg90, 30) 'Ping Center waitms(pausetm) 3: stop Spin_right(deg45, 30) 'left and center waitms(pausetm) 6: stop Spin_left(deg45, 30) 'right and center waitms(pausetm) 5: stop Spin_Right(deg180, 30) 'left and right but not center ?? waitms(pausetm) 7: stop Spin_Right(deg180, 30) 'left, right and center waitms(pausetm) waitcnt(clkfreq / 500 + cnt) PUB SensorCog | i, ticks, ch, t '' runs in a separate cog adc.init(CS, CLK, DIO) ' start adc driver waitcnt(MS1 + cnt) ' let objects load t := cnt repeat repeat ch from 0 to 1 SensDist[ch] := adc.read(ch, adc#SE) ' get channel value SensDist[2] := ping.Inches(PING_Pin) waitcnt(t += constant(MS1 * 100)) ' update every 100ms PUB CheckSensors | Sensors ' returns value with bits 2..0 indicating which sensors have detected objects Sensors := 0 if SensDist[0] > 1600 'left IR sets right bit Sensors |= %001 'set bit 0 else Sensors &= %110 'clear bit 0 if SensDist[1] > 1600 'right IR sets left bit Sensors |= %100 'set bit 2 else Sensors &= %011 'clear bit 2 if SensDist[2] < 16 'Ping sets center bit Sensors |= %010 'set bit 1 else Sensors &= %101 'clear bit 1 Seg7.tx(ClearScr) Seg7.bin(Sensors, 3) Return SensorsNow having said that, combining this roaming detection with dead reckoning, THAT'S HUGE. Think of mapping a room and moving mainly from dead reckoning, but needing to detect and maneuver around some random objects, then get right back on track.
Easy to say, hard to do. Hey, I'd make a great Futurist! Soon these robots will be cooking scrambled eggs and bringing us breakfast in bed!
erco - I have similar opinions of line-following robots - how useful can that really be? OTOH, object recognition would be a neat (but expensive) avenue to explore...
Since this is my first robot (since my BOE-BOT from early 2000) I am just trying to learn and experiment with no specific goal in mind. I have considered adding an XBEE, NetCam, robotic arm, etc but really don't know what direction I'll take.
I can't really afford to throw a lot of money at it unless I want to come out of retirement - and then I wouldn't have as much time to tinker.
I'm following your homemade Stingray with renewed interest... great work! My newest project, Orville, is using the prop board, motors and wheels from the Stingray albeit in a somewhat different configuration. I suspect I'll be dealing with some of the same problems as you.
#erco - I agree with your thoughts on navigation. I will admit it's still fun to watch Bob wander around the house and try to get out of various predicaments, but there is much more potential to be tapped. Obstacle avoidance is fine, but not if that's the only goal. There's a difference between going anywhere and not running into things and going =somewhere= and not running into things.
Great robot, hand crafted BOTs are neat.
I have a pair of similar Pololu motors but mine are 100 RPM with encoders.
Could you please post your code?
I would like to know how you wired encoders, and how you are reading them with the Propeller.
Thanks,
zappman
The encoder wires are connected directly to Propeller pins 4 thru 7. I use the Quadrature_Encoder object to read them using the ReadDelta method.
I haven't looked at the code in a while but I am attaching the latest version which uses a Ping and two Sharp sensors to roam without bumping into objects.
Thanks very much for posting your code.
Regards,
zappman