Gas station without pumps

2013 June 30

Robots in physics

Filed under: Robotics — gasstationwithoutpumps @ 13:34
Tags: , , ,

I just watched the Global Physics Department of Matt Greenwolfe showing his use of Scribbler 2 robots as physics education tools.  See also Matt Greenwolfe’s blog, starting with The Robot Lab (formerly known as the Buggy Lab). It may be easier to get the content from the Matt’s blog posts than from the Global Physics Department recording, which had a lot of technical difficulties.

Scribbler 2 robot.  Picture copied from the Parallax web site that sells the robot.

Scribbler 2 robot. Picture copied from the Parallax web site that sells the robot.

He did some modifications to the code for the Scribbler 2 to provide precise control of the robots (1 mm/sec velocity and 1 mm/sec/sec acceleration accuracy) and made some nice graphical interfaces for students to control the robots with x vs. t, v vs. t, and a vs.t plots (plus one interface that does 2D motion).

One big problem with the Scribbler 2 was the limitation to about 18.5 cm/s velocity, which is pretty slow. The cool thing about them is that they have wheel encoders that allow 0.491 mm resolution with 507.4 counts per revolution. One limitation that is a complete deal killer for me is that the Scribbler 2 library is only available for Windows machines, so porting to a Mac platform would be a major effort.

I was looking to see whether one could easily build such a robot from easily available parts. One cool new part is an integrated wheel, motor, controller, and shaft encoder called the HUB-ee (available for $35 from SparkFun):

The HUB-ee is a type of robot servo but designed for wheels, in fact it is a wheel, but it is also a motor, a sensor and a motor controller. What’s that? Did we just blow your mind?
When you want to add wheels to your robot you would normally start with a whole collection of parts: The motor and gearbox, a motor driver board, and maybe some sensors for measuring wheel speed and a controller to count revolutions or provide closed loop speed control. Well, the folks over at Creative Robotics thought it would be handy if you could just buy a wheel that had all of those things built in, so they designed HUB-ee – just bolt it onto a chassis, apply power and away you go!
The HUB-ee is easy to mount, too! There are two threaded inserts for M3 bolts built in, there’s also a right angle bracket included for situations when you can’t go horizontal into the chassis. The mounting holes are even LEGO® lug compatible!! HUB-ee uses Micro-MaTch connectors to keep electrical connections tight and easily changed, check out the related items for mating connectors.

HUB-ee wheel picture copied from Sparkfun web page

HUB-ee wheel picture copied from Sparkfun web page, which says that images are licensed by CC BY-NC-SA 3.0.

The HUB-ee has a resolution of 128 counts per revolution of the wheel (1.473 mm resolution, 3× the step size of the Scribbler 2). The HUB-ee runs at 120rpm no load at 7v, which would be 37.7 cm/s, about twice the speed Matt reports for the Scribbler 2.

Although Matt reports 18.5 cm/s, the Parallax spec for the Scribbler 2 claims up to 80RPM, which would be 33.2 cm/sec, but that is probably with a 12V power source, rather than 6AA batteries. I suspect that Matt’s need for very precise control and operation with batteries limited the top speed he could use.  He does say that he would have liked a voltage controller (which would have added a $3–15 part cost to the robot, so a $7–40 increase in retail cost, based on the designs by TI’s WebBench tool or the PTN78000W module from TI) in order to have better speed control without having to worry so much about keeping the batteries fully charged.

The Hub-EE takes up several pins on a microcontroller (1 PWM pin, 2 output pins to control direction, 2 input pins for the quadrature encoder feedback) in addition to power and ground.  Two HUB-ee wheels would cost $70 and use 10 pins on a microcontroller—doable with an Arduino, but not leaving a lot of pins for other functions like sensor inputs.  There aren’t enough interrupt pins on the standard Arduinos to have all 4 wheel encoder pins triggering interrupts (which would be the highest-precision way to use the feedback information to get precise motor control).

Internally, the HUB-ee wheels use a Toshiba TB6593FNG motor controller, an H-bridge designed to work with 1.0A average current, with an on-resistance of about 0.35Ω for the output low.  The Toshiba data sheet doesn’t give the on-resistance of for high voltages directly, but if I’m interpreting their “Vsat” parameter directly, the on-resistance for each leg is about 0.5Ω, about a sixth that of the popular L293D H-bridges.  At under $3 a H-bridge (in single units), the TB6593FNG does not look like a bad choice for a small H-bridge.

Of course, to use the HUB-ee, one would have to build the rest of the robot (chassis, microcontroller, battery, … ). The Hub-EE is designed to mount to Lego beams, which could make chassis building easy, at least for prototyping.

I wonder whether, in a couple of years, we’ll be seeing integrated wheel units like the HUB-ee with an SPI interface, with registers that say how many steps to make, with specified velocity and acceleration curves.  That would provide very simple interfacing with fewer wires and could allow much tighter servo loops, at the price of putting a microcontroller at each wheel (probably adding $10 to the retail price of the wheels).


  1. Looks very interesting. I’ll have to check it out! The reported .491mm resolution on the scribbler II is incorrect. It is actually half that, as I verified by direct measurement when developing my project. So the top speed of 18.5cm/s is unfortunately correct. This does make the encoders on the sparkfun wheel six times less precise than the scribbler encoders. My goal was to make an apparatus that would be precise and reliable enough that students could check the correctness of their ideas with the robot. Once the error approached a centimeter, it is perceivable by eye that the motion is off and students then have to wonder whether their understanding of physics or the robots are the cause of the error. These new wheels would fall right on the boundary. They might or might not work for my educational goals However, there is still a great deal that could be done with them.

    The idea of the voltage regulator would be to boost the approx 8V from the 6AA battery back to closer to 15V and keep that top voltage constant even as the batteries discharged. It wouldn’t improve the precision of the motor control, but would make it go almost twice as fast. According to spec, the motors in the scribbler II can handle the increased voltage. Not sure about some of the electronic components in the path between the motors and batteries. Trying this out would risk frying them. Just haven’t had time to investigate that yet.

    The fine print: Parallax has a mysterious and uncommented factor of two in the assembly language motor driver. In the higher-level spin-language code, they put in the .491mm encoder resolution that is also off by a factor of 2 and compensates for the previous error. Hence the incorrect published spec for their encoder resolution.

    Comment by Matt Greenwolfe — 2013 July 1 @ 05:38 | Reply

    • Thanks for the correction about the encoder resolution. There are usually 4 events in a quadrature encoder cycle (A rise, B rise, A fall, B fall), and software is not always written to take full advantage of that resolution. It is unusual for the specs to be wrong in that direction though—more often companies claim the full resolution of the hardware, then throw away the resolution with sloppy software. It is rare that they only claim the resolution that the sloppy software gives them.

      The TB6612FNG motor controller they are using is limited to 13.5v for the motor, and (more importantly) 1.2A per channel continuous. The on-resistance of 1/2 Ω (upper+lower, so less than I had thought) and power dissipation of 0.78W, 0.89W, or 1.36W (depending on how much copper heat sink is on the PC board) limits the TOTAL current for both motors to 1.25A, 1.33A, or 1.65A. The Parallax specs claim the 0.78W limit (no extra copper for heat sink), so straight-line running is probably limited to 0.63A/motor. They claim to have designed for a max of 0.55A/motor, but they were basing that on an on-resistance of 0.7Ω (based on the max, rather than the typical, saturating voltage at 1A, so a much safer design point).

      I can’t find any information about what motor they used, but you probably can’t raise the voltage much over 10V without hitting the current limits of the controller chip, unless they were unusually conservative in their design, which they don’t seem to have been. A TPS55430 boost DC/DC converter would let you do that boost with about 93% efficiency for about $3 in parts. If you wanted to be able to handle the same peak currents as the motor controller (you probably should to keep high acceleration), then you’d need a bit beefier converter, probably about $4–5 in parts.

      Comment by gasstationwithoutpumps — 2013 July 1 @ 08:39 | Reply

  2. Thanks. That’s useful. And at physics teacher camp last weekend, I did some work with John Burk ( and we made a lot of progress on porting my software over to the MAC. It’s pretty certain we’ll have a working MAC version in time for the start of the school year in the fall. I’ll post a blog post with details soon.

    Comment by aphysicsmicrocosm — 2013 July 1 @ 09:44 | Reply

  3. […] There are other ways that programming helps them—for example, Matt Greenwolfe spent a lot of time programming Scribbler 2 robots to be better physics lab tools than the usual constant-velocity carts. Other physics teachers are doing simulations, writing video […]

    Pingback by In defense of programming for physics and math teachers | Gas station without pumps — 2013 July 3 @ 09:15 | Reply

  4. I have created a way of doing something similar with NXT robots. I’ve written up what I have here:

    Comment by Sam Terfa — 2013 July 22 @ 06:38 | Reply

    • Nice! Matt Greenwolfe reported the precision with which he could control the Scribbler2 robots. How precisely can you control your NXT robot? For example, what error do you get when trying to move precisely 3m? How precisely is the velocity and acceleration controlled?

      Comment by gasstationwithoutpumps — 2013 July 22 @ 11:03 | Reply

  5. I’m adding some results to the site. I’m doing 5 video analyses right now each for 1 meter. I can work on a 3-meter test. In general, the slower the car goes, the more accurate it is. It’s very hard to get rid of the initial error when your initial velocity is supposed to be 25 cm/s and it starts from rest but it’s going well. I’ve mostly been testing 1-2 meters just for times sake, but I’ll try a couple 3-meter tests too.

    Comment by Sam Terfa — 2013 July 22 @ 11:35 | Reply

    • I believe Matt handled the startup problem by not allowing specification of infinite acceleration in his user interface. By limiting the specified acceleration to actually achievable ones, the match between intended behavior and observed behavior should be much tighter.

      Comment by gasstationwithoutpumps — 2013 July 22 @ 11:58 | Reply

  6. The algorithm is doing really well! I have an semi-automated calibration set up to determine the effective wheel diameter of the car, and good starting motor speeds for different initial velocities. Calibrating at 10 cm/s for 30 seconds, and running it several times, gives me really good results at other speeds in that the car moves within half a cm, and many times to a couple millimeters, of what it thinks it moved. However, tuning the PID variables so that the actual distance exactly matches the intended distance is the trickiest and most time-consuming part. I can find a set of parameters that works well at 10 cm/s, but when I try them at, say 20 cm/s, they don’t work as well. I can progressively change the parameters but I’m not sure in what specific way to do that yet. I will keep working on that part. I hope someone else tries this out at some point because it’s really cool!

    Comment by Sam Terfa — 2013 July 24 @ 12:23 | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: