Question on monitoring the rotation of continuous servos

I am trying currently trying to covert a project I did with NXT using Lejos to Arduino. I am using a Parallax BOE shield bot and Parallax continuous rotation servos.

In the NXT/Lejos project I was able to map the robot in 2d space by using the compass and counting the rotation of both servos in a differential setup.

I am very close to getting the Arduino based robot to do the same but I cannot figure out how to accurately count the servo rotations. It seems that the NXT servos allowed for this as all api's for the NXT servos provided some form of getTachoCount() method that would return the current count of the servo. It was also possible to rotate the continuous servos a particular amount of degrees

Can anyone suggest a way to do this? I have not been turning up much in my searching, but i might not be looking for the right thing so any terms you can think of that might be helpful to my searching would be appreciated as well. At this point my best guess is to find the amount of time it takes the servo to rotate once at full speed and then do the math. But I have a feeling this will become in-accurate rather quickly. Are there any clever libraries already in existence?

I am open to completely new approaches but would like to work with what I have if possible.

Thanks,

Brian

A 3-pin 'continuous rotation servo' gives much less feedback than a 6-pin NXT motor. To get the kind of control you want you should use a gearmotor with rotary encoder feedback.

Thank you very much, reading up on gear ratios, etc.

Can anyone suggest a way to do this?

Perhaps as a troubleshooting/isolation thing put a serial print statement printing out the raw joystick measurements you are getting from your analogRead commands to see what raw values it is seeing when you have the servo hunting problem. Many joy sticks have pretty poor centering qualities so you need to try and isolate the problem to being a joy stick or servo problem. Also post your code for better possible analysis. What are the pot ohm values used in your joystick?

Lefty

Or you need to add a switch to you servo that trips once or twice or 4 times every revolution. The based on what direction it it running you add or subtract from a counter to get some position information. Either that or add an encoder (more expensive...)

The LEGO NXT motor is not like a normal servo motor, in that you can get feedback from it through a built in encoder. If you want to recreate this with a normal servo then you have to attach a rotary shaft encoder to your servo and monitor that through the arduino. This is not an easy thing to do but it is possible.

http://playground.arduino.cc/Main/RotaryEncoders

thank you all again for taking some time to respond. I have been doing a bit more research and i think i have narrowed my choices down to 2:

Because my project is based on the BOE-BOT the easiest choice would appear to be: the digital encoder kit made by parallax http://www.parallax.com/Store/Robots/RoboticAccessories/tabid/145/ProductID/80/List/0/Default.aspx?SortField=ProductName,ProductName
I have some reservations though that it will not be the most accurate system. But I do believe it will be the most economical when considering time and other factors.

The other way I am thinking of going is with new gearmotors such as these: Pololu - 75:1 Metal Gearmotor 25Dx66L mm LP 6V with 48 CPR Encoder (No End Cap)
They are slightly longer then my current servos so I think they will require some amount of modification to the BOE bot chassis, in addition if I am understanding correctly it seems i could not run them off the regulated 5v provided by my boe bot arduino shield because it provides up to 1A and each gearmotor is listed as using 40ma running and 2.2A stall. Am I understanding correctly that I need to provide for 2.2 X 2 or 4.4A regulated 6V? (although the motors would run ok on 5V) Also with regards to the motor controller I would think I would need to have one to control the motor RPM?

Is it likely accurate then that to go the gearmotor route I would be looking at getting the motors, doing chassis modification (or replacement), would need some form of DC motor control board and possibly another batter pack depending on consumption and the input range on what ever is regulating the voltage to the gearmotors?

I am leaning towards the parallax encoders and am curious if anyone here has tried them out and has any feedback about their error rate. I am thinking i will start there and for the next project plan ahead for the gearmotor / encoder route.

Thanks again,

Brian

Have you thought about just using the Lego NXT motors?

http://www.robotc.net/wiki/Tutorials/Arduino_Projects/Mobile_Robotics/Lego/Connecting_A_Lego_Motor

That shows how you can get the motor turning; you'll have to figure out how to use the encoders in some other manner.

http://shop.lego.com/en-US/Interactive-Servo-Motor-9842?CMP=KAC-SAHGOOGLEUS&HQS=9842&adtype=pla

$20.00 USD from the Lego store; that's cheaper than some standard servos (although I doubt the Lego device is as robust?)...

In the NXT/Lejos project I was able to map the robot in 2d space by using the compass and counting the rotation of both servos in a differential setup.

I'm supprised that any reasonable amount of location accuracy was maintained over time by monitoring wheel rotation. Any wheel slippage will introduce error that will continue to accumulate over time.

Any wheel slippage will introduce error that will continue to accumulate over time.

True but the wheel is integrated in the lego motor so slippage does not occur.

Grumpy_Mike:

Any wheel slippage will introduce error that will continue to accumulate over time.

True but the wheel is integrated in the lego motor so slippage does not occur.

I thinks he means that the wheels slipping on the floor will cause loss of absolute positioning in the dead-reconing system. If a wheel slips then the fact that the wheel turned one revolution does not mean it made Pi*D progress along the floor.

There was some error on the nxt's (there were 2 of them) when there was wheel slip (generally it only happend when the side clipped an obstacle. For the application it worked surprisingly well. Basically I had to use 2 nxt bots in an obstacle coures the first robot was a seeker and was allowed to have an IR sensor. It had to find multiple IR beacons around the course and communicate the location back to the second one. The second robot was not allowed an IR sensor but had to have a way to retrieve the IR beacon (spherical). The retriever used the x,y co-ordinates sent by the seeker to get the ball then return it to 0,0 (home). Here is a video i took of the process a bit before the final version, but all in all it shows how it was intended to work. https://plus.google.com/103670107949098796410/posts/A96iapotHns

Now I have ported the software to the Arduino, but this time around I am adding a android phone to the mix that will receive the sensor data and "assumed" x,y position info from the arduino and attempt to reconcile it against it's own mapping and localization. It then could pass back a x,y destination to the ardiuno as an attractive field and possibly modify the arduino's own x,y location if there is reason to believe it is off.

My big concern with the parallax encoder setup for the boe-bot is that it will not be accurate even when there is no wheel error, but I will be finding out soon, because i decided to order it.

Also I did consider using nxt motors, I even looked at a shield that is available for nxt gear, but the nxt bots belonged to the school where I am taking my masters (the arduino stuff is mine) so I would have had to purchase new nxt motors anyway..

Thanks again for everyone help

Brian

Accuracy is a relative term. It depends on how much accuracy you need. More accuracy than you need doesn't return anything for the added cost. How big is the IR source and how big is the box you are picking it up with?

For the robots - you do some testing to determine the repeatability of moves and add some fudge factor and it comes out close enough (generally that is what is meant by accuracy - is it close enough to work under the required conditions. Does that machined part need to be within 1", or 1/4" or 0.005" or 0.0005". More precision costs more money and time.) A pulse or 2 (or 4 or 8)for every revolution of the motor may work and also doesn't require a lot of processor overhead. An encoder requires more overhead and may require the rest of the process run slower. Whats the goal? to get there and back, or get tehere and backe the fastest?

Since all you have to measure from is the wheels, then you have to figure out how to keepthe slipage down. Things like don't accelerate too fast and slip the wheels. FIgure out the best way to corner. Is it better to stop one wheel and pivot around it, or is it better to keep the inside wheel turning slowly so it sticks better? Do you also know the measurements of the maze? you can use bumps of the maze to reset position info and correct for slippage.