What is a good speed for a bot, trying to read sensors and do odometry on the move
![rwgast_logicdesign](https://forums.parallax.com/uploads/userpics/245/nS7IEA13OBKXG.png)
Ok so ive been workiung hard to design this bots drive train and frame strong and efficent for it purposes. Right now ive been going back and forth on tbe max rpm i will need for the wheels i intend to use. It all comes down to speed, when I first started out I wanted lower end rc car speeds, as ive done more research ive found that accuracy will be a huge issue at higher speeds so ive dropped that for now. so my question is, what is a good speed for a bot a bit bigger than a boe bot.
I worked out a boe goes about .5ft/sec and found a polulu 3pi goes around 3ft/sec. Right now im looking at pushing about 1ft/sec to 3ft/second depending on voltage and wheels. What exactly is a good speed for accruatcy when it comes to things lime odometery and smoothly reading ir/ping sensors while moving. Searching around bots go at various speeds from boe slow to pretty fast so im just trying to guage a good speed thats entertaining while not causing me to rip my hair out
I worked out a boe goes about .5ft/sec and found a polulu 3pi goes around 3ft/sec. Right now im looking at pushing about 1ft/sec to 3ft/second depending on voltage and wheels. What exactly is a good speed for accruatcy when it comes to things lime odometery and smoothly reading ir/ping sensors while moving. Searching around bots go at various speeds from boe slow to pretty fast so im just trying to guage a good speed thats entertaining while not causing me to rip my hair out
Comments
For odometry is top speed isn't the big issue, wheel slip is the big problem. If you ramp up to top speed and ramp down to a stop you'll be fine. However, the faster you go the more likely that your robot will encounter an obstacle and need to react. A BS2 quickly gets it's hands full tending motors, encoders, sensors, and doing the odometry calculations. In the video below my CBA robot uses trigonometry to compute headings and travel there, but at times has its hands full.
I've seen an S2 do more impressive things, but that robot's encoders are higher resolution and its processor is much better.
Spinning to follow a line:
http://www.youtube.com/watch?v=nAU_IQgiggM
Maze solving with really tight corners:
http://www.youtube.com/watch?v=mJV-KDqHgDQ
There's a certain appeal to small robots because even a robot a little bit bigger couldn't do that. It would skid off the course if it tried to jam on the brakes on one wheel while accelerating with the other. Think about a car. It has over a ton of mass so you need to plan out your acceleration and deceleration very carefully.
BTW, don't mention the 3pi robot to the haterz in the "Pi is Wrong" thread, or they'll make Pololu rename it 1.5Tau.
Take a look at Robot Zero http://webdelcire.com/wordpress/archives/619 which takes that concept to the extreme. Here's a video too:
@Erco, you are probably right about just experimenting to figure it out, Ive left my self enough head room to get get up to the 3Pis speed witch seems fast enough. Seeing the 3Pi running less than its 3ft/sec is a pretty good gauge for speed, it almost seems extreme, funny to think my old chassis ran around 5-7ft/sec with a planned 10ft/sec, that would have been a mess to get any kind of accuracy out of.
I'm tending to follow Erco's suggestion about trying what you have, to see if you can control it.
My Scarecrow platform runs at 1ft/sec now.
I reduced its speed from 70ft/min while attempting to get my software under control with my BS2 controller.
The Scarecrow platform is still running too fast for me to get a handle on EXACTLY why I keep crashing.
My goal is autonomus roaming.
The only sensor I'm using at this time is my Servo rotating Ping sensor.
I feel that the Ping Sensor is working as designed, but the Ping does not see some things.
For instance, the Sweater I wear in my shop.
When I wear the Sweater, I'm the invisible man.
The Scarecrow platform is really too large for navigating around my small shop.
A foot of Snow in my yard keeps me from running it in the back yard, where it is intended to be used.
It's like trying to turn a Semi-Tractor-Trailer rig around in my 25ft driveway.
I run my platform, look at how it behaves and modify my program to hopefully eliminate the crashes.
I'm working on attempt8 at the moment.
I'm also attempting to set up some whisker switches in a similar manner to the Boe-Bot whisker switches that Parallax sells.
My scale is actually too large, which I know is causing some of my troubles in my basement workshop.
I learn a bit more each day.
That's just my 2 cents worth.
Good Luck with your endevor.
Garyg
IMO just moving the existing sensors forward on the S1/S2 would be a big improvement.
Here's a new 3pi-ish robot: http://www.ebay.com/itm/Cooqrobot-Smart-A-Robot-car-Android-bluetooth-control-line-following-for-arduino-/160857254666?pt=LH_DefaultDomain_0&hash=item2573d6eb0a
Here's another robot with a similar chassis layout to your Robot Zero: http://dani.foroselectronica.es/silvestre-line-following-robot-122
I can make a good case for car-type steering over differential steering for a track consisting only of curved lines, with no sharp 90 corner angles.
Your sweater and Duane Degn's sofa befuddle all the PING robots. When the robot rebellion starts on judgement day, I'm putting on a sweater and sitting on the upstairs sofa, just to be safe.
http://www.youtube.com/watch?v=ASoCJTYgYB0&feature=player_detailpage#t=55s
Isn't the stall detector the tail wheel encoder? I thought both DC motors have shaft encoders as well?
@Erco, I've seen that Cooqrobot on ebay before. The documentation on it is pretty scanty. Like which pins do what being the most important thing.
The "stall" detector in the S2 is actually a virtual sensor that synthesizes counts from the tail wheel and monitors current usage through the motor drivers. Too few tail wheel counts and/or excessive current usage triggers a "stall" flag. In both cases, thresholds and counts are used to decide before setting the flag. At least, that is how PhiPi's S2 object (that ships with the S2 and is used with the S2 GUI) works. Custom programs can do what they want.
The shaft encoders on each DC gearmotor in the S2 are used for straight line driving and odometry (x, y, theta, etc) to about .5 mm precision.
Unfortunately, the photos posted on Parallax's S2 page of the guts of the S2 are not accurate and don't include the shaft encoders (and a few other small changes between the photographed prototype and the final product).