Shop OBEX P1 Docs P2 Docs Learn Events
What is a good speed for a bot, trying to read sensors and do odometry on the move — Parallax Forums

What is a good speed for a bot, trying to read sensors and do odometry on the move

rwgast_logicdesignrwgast_logicdesign Posts: 1,464
edited 2013-01-07 18:18 in Robotics
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

Comments

  • ercoerco Posts: 20,256
    edited 2013-01-06 17:16
    Best to just build it and see. Too many variables, no one can answer your question accurately. You'll learn a lot in the process. Keep us posted.
  • Martin_HMartin_H Posts: 4,051
    edited 2013-01-06 17:33
    3pi's are built for speed in line following contests and they don't have wheel encoders. They use a fancy regulated power supply to ensure that the motors have a constant voltage which helps for repeatability in spite of being open loop. That robot is crazy fast too.

    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.
  • Martin_HMartin_H Posts: 4,051
    edited 2013-01-07 06:31
    Erco is correct, that ultimately there's so many variables (inertia, wheel friction, torque) to consider that trying it is probably the only way to arrive at the correct answer. For example the 3Pi is small, so its inertia is low. This allows it to accelerate and decelerate really quickly and do crazy things like the following.

    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.
  • ercoerco Posts: 20,256
    edited 2013-01-07 08:40
    OMG, that spinning line follower is AMAZING. I'm making some tweaks to the Scribbler (blue) bot for improved line following, but nothing close to that. I'm convinced the chassis geometry (wheels and sensors) is all wrong, which includes S2. The sensors need to be moved much farther forward of the axle (like 3pi) to begin to get any performance at all.

    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.
  • Martin_HMartin_H Posts: 4,051
    edited 2013-01-07 13:20
    erco wrote: »
    The sensors need to be moved much farther forward of the axle (like 3pi) to begin to get any performance at all.

    Take a look at Robot Zero http://webdelcire.com/wordpress/archives/619 which takes that concept to the extreme. Here's a video too:
  • rwgast_logicdesignrwgast_logicdesign Posts: 1,464
    edited 2013-01-07 14:38
    @Martin wow those are all some very amazing videos, there is no way a 4 wheel bot will be able to maneuver that tight at those kinds of speeds!! The product page isn't to clear but what is the scribbler 2 using for its drive train? CR servos or DC Motors? If its motors how quick is the little guy, watching the 3PI kind of make me want one but with a propeller and not an AVR, the S2 seems like a good option as long as its not using servos or can easily be upgraded to some Polulu gearmotors. I had actually just read the guys article about how to build the bot in the very last video you posted and he is using the same gear motors that are in the 3Pi, its very easy to assemble one of those guys.

    @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.
  • Mike GreenMike Green Posts: 23,101
    edited 2013-01-07 15:13
    The Scribbler 2 uses DC gear motors with a wheel encoder mostly used as a stall detector.
  • garyggaryg Posts: 420
    edited 2013-01-07 16:01
    Mr Gast
    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
  • ercoerco Posts: 20,256
    edited 2013-01-07 16:46
    @Martin_H: Yes, that is a very good example of sensors mounted way in from of the axle. At those speeds, it comes down to balancing speed, traction, and centrifugal force in the turns to avoid spinning out.

    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.
  • ercoerco Posts: 20,256
    edited 2013-01-07 16:52
    garyg wrote: »
    When I wear the Sweater, I'm the invisible man.

    Garyg

    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
  • Martin_HMartin_H Posts: 4,051
    edited 2013-01-07 17:32
    Mike Green wrote: »
    The Scribbler 2 uses DC gear motors with a wheel encoder mostly used as a stall detector.

    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.
  • ZootZoot Posts: 2,227
    edited 2013-01-07 18:18
    Isn't the stall detector the tail wheel encoder? I thought both DC motors have shaft encoders as well?

    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).
Sign In or Register to comment.