Skip to content

Modeling and Robots—on a Mac!

June 19, 2013

I’ve written a lot about the value of computational modeling and physics. To me, it’s a natural fit in the modeling physics curriculum to give students a tool that allows them to create and explore simulations using a computer, which greatly expands the scope and depth of problems that students can explore.

One of the things Matt Greenwolfe introduced me to last fall was that these simulations don’t just have to live on a computer screen—it’s not too hard to program them into robots into small, easy to use robots. Now would be a good time to go and check out some of the awesome work Matt has done with the Scribbler 2 robot in his modeling physics classes:

He’s also given a great presentation to the Global Physics Department.

One big problem for me with all of this is that all of Matt’s work has been done on a PC, and I use a mac, and it turns out that it’s non-trivial to adapt his work to a different platform.

My idea for integrating robots into the classroom

I really like all of Matt’s creative uses for robots in his classroom, but I’d like to add one more thing. I want students to be able to take a program they’ve created to model the motion of an object in VPython, say a car moving with constant acceleration, and very simply translate that program so that a robot can physically reproduce the same motion they see on screen, with the obvious velocity and acceleration limits of the robot platform. I also want students to be able to explore some of the more typical kinematics and vector problems we do with a robot component. Could students write a program to have an robot travel a distance of 1 meter in a time of 10 seconds while the robot has a constant acceleration? Could they use the robot to trace out a series of vector displacements to help understand vector addition? Could the robot use it’s marking functions to create real ticker tapes that show a record of its motion?

The Myro library that is used to control the robots in python is very low level. It simply allows you to tell the robot basic commands of forward, backward, turnRight and turnLeft specifying the speed of the motor (on a scale of 0 to 1) and the duration of the command. Thus it’s going to require some significant work to turn this into a series of more useable commands that allow students to directly set and modify the velocity of the robot. I’m hoping that perhaps that work has already been done elsewhere, and I just need to search harder to find it.

Controlling a Scribbler2 robot using a Mac via Bluetooth

Note: Unless you are looking to setup a Scribbler2 on your a mac, you can probably skip this section, as it’s mostly for me to remember how to set up the robot.

I’m going to try to document the steps I took to get the Scribblar 2 robot working with a mac for my own future reference, and to help anyone else who might be confused by all of the different directions that are out there on the internet. As popular as these robots seem to be with intro compsci classes, the documentation is very spotty—the instructions that were mailed with my robot contained numerous errors and were impossible to get working.

First, you’ll need to order a Scribbler 2 robot and Fluke Board. Total cost is around $200 for a new robot and board, and slightly less if you are willing to buy used. The Fluke card allows for bluetooth communication with your computer, and also sports a high resolution color camera.

    1. Download Calico

Calico is a framework/IDE for computer science. It’s chief advantage is that it comes with its own version of python preloaded with the myro library for controlling the scribbler robots.

Installing Calico on a mac running 10.8 is mostly straightforward, except that you need to manually copy a frameworks folder from the download to your /Library/Frameworks folder, which requires authentication.

    1. Connecting your robot

Next you’ll need to pair the robot with your computer. This involves going to your bluetooth settings, setting up a new device (the Fluke2-XXXX), and then changing the serial port (in the settings gear under the list of devices in the preference pane).

System Preferences

Once you do that you can rename the serial port connection something simpler, like “scribbler”.

Screen Shot 2013 06 19 at 3 08 38 PM

Also note that the full name for the serial port will now be /dev/tty.scribbler. You’ll need this in a bit.

One other handy tip: if you ever want to list all of the serial connections on your mac using the terminal, simply use the command, ls /dev/tty.*.

If video instructions are more your thing, then this video has everything right, though you probably need to update your firmware before you can get the robot to respond.

  1. Connect to your robot with Calico
  2. You should now be able to run Calico, open the shell prompt and type init("/dev/tty.scribbler") to initialize the robot. I got the following message in response:


    python>>> init ("/dev/tty.scribbler")
    You are using:
    Fluke, version 3.0.9

  3. Update the firmware for the Robot and Fluke Card
  4. Once you’ve connected for the first time, you probably won’t be able to run any commands, since the firmware on the robot and card have a tendency to be out of date.

    Here’s a pro tip: naturally there’s a wonderful python library for updating the firmware of the robot. It took a lot of searching and wondering what I was doing wrong when the upgrade("scribbler") command wasn’t being recognized. After some searching I found the following commands did the trick:


    python>>> from firmwareupgrade import upgrade
    Ok
    python>>> upgrade("fluke")

    Upgrading fluke...
    Connecting to Fluke for firmware installation...
    3.0.9
    Version of fluke [3, 0, 9]
    Looking for Fluke upgrade at http://www.betterbots.com/upgrade/fluke/...
    Considering /fluke-upgrade-2.9.1.hex ...
    Considering /fluke-upgrade-2.7.9.hex ...
    Considering /fluke2-upgrade-3.0.5.hex ...
    ['3', '0', '5'] [3, 0, 9]
    Considering /fluke2-upgrade-3.0.9.hex ...
    ['3', '0', '9'] [3, 0, 9]
    Nothing found to upgrade!
    Ok

    The fluke card was already updated


    python>>> upgrade("scribbler")
    Upgrading scribbler...
    using robot: SCRIBBLER-2

    Looking for Scribbler upgrades at http://www.betterbots.com/upgrade/scribbler2/…
    Opened url…
    Considering scribbler2-upgrade-1.0.0.binary …
    Considering scribbler2-upgrade-1.0.1.binary …
    Considering scribbler2-upgrade-1.0.2.binary …
    Considering scribbler2-upgrade-1.1.2.binary …
    Considering scribbler2-upgrade-1.1.4.binary …
    Considering scribbler2-upgrade-1.1.5.binary …
    Loading http://www.betterbots.com/upgrade/scribbler2/scribbler2-upgrade-1.1.5.binary
    3.0.9
    Version of fluke [3, 0, 9]
    Sending magic key
    Program size (bytes) = 14776; scribbler version = 2
    Storing program in memory…
    Programming scribbler 2…
    sending magic key
    Wait for the robot to reboot!
    Please start myro to connect onto robot
    Done upgrading!
    Ok

  5. Enter commands

Now that you’ve done all that, you should be able to simply issue commands either via the Calico shell, or by writing and running python scripts in Calico.

8 Comments leave one →
  1. June 23, 2013 11:02 am

    Hi John,

    One thing I’ve been playing with is using Scratch for computational modeling. Pretty much all inspired by your blog, btw. The extension to this is that I’m also using Scratch to program Lego Mindstorms NXT. I don’t know what your budget is like, but the NXT isn’t that much more than $200.

    The same can be done with Vpython and python, there are 2 ways to use python for programming the NXT.

    I know that Matt has talked about the scribbler being the only robot that is accurate enough for the labs he was doing, so maybe the NXT is too expensive and not suitable. I have one here, so maybe I’ll bring a motion detector home and try it out myself (or video record it and use tracker).

    • June 23, 2013 10:28 pm

      I tried the NXT, and found it not to have the precision I wanted. To be clear, all of these educational robots are terrific at what they do, teaching problem-solving, electronics, programming, logical thinking, engineering, applying physics principles, etc. I wanted something that would serve as a physics apparatus, so I wanted the graphical interface the students used to be intuitive, to use the position, velocity and acceleration vs. time graphical representations, and for the robot to faithfully and reliable perform the motion as programmed, to within 1mm/s and 1mm/s^2 accuracy. The idea is that using robotics, the apparatus could be so good that students could use it to test their own understanding without the complicating factors of non-constant acceleration, taking of steps, uneven surfaces, friction on sliding objects, rolling with slipping, etc.

      A teacher or other person who already has a constant velocity or constant acceleration model, can easily look at imperfect real-world motions and see the model plus some systematic or random noise. But a student who has not yet constructed the model for themselves lacks the necessary filters. They see everything and don’t have a reliable enough mental construct yet to see the signal for the noise. When instructed to ignore the noise and told what signal to focus on, they can all to easily get the impression that the experiment “did not work” and that the teacher had to tell them what it was supposed to show. This is why I want something really precise and reliable, and felt that robotics should be able to produce this. To be sure, students should also be exposed to other less-than-perfect examples of motion, and let to apply the model and see the real motion as matching it with some error. But the precision robots allow this to happen later in the unit, when they already have already constructed a robust mental model that will help them do this.

      So yes, you could so some things with the lego system, but not the kinds of things I’ve been showing on my blog. With every other robotics system I tried, the performance fell short of my goals. I felt if students were using them to learn kinematics equations and graphs that too many complicating factors would creep in and confuse them. I spent a couple months of basically full time work testing different systems, reluctantly and gradually trying more and more sophisticated things until I figured out what was necessary to do what i wanted and was able to recognize that the S2 fit the bill. It can’t be the only thing that would work. It should be possible to build a robot specifically for use as a physics apparatus that would do better, but finding something already built and at a reasonable price is not easy.

      And then, when I did find a robot with the right hardware, sensors (wheel encoders) and processor, I found that it was not programmed to move very precisely at all. For most of these educational systems, the goal is to complete some autonomous task like running a maze, avoiding obstacles, wrestling or fighting, mapping a space, etc. Usually, all the programmers care about is that the task is complete in a reasonable time or perhaps as fast as possible, but they do not care what the exact velocity is, what the exact acceleration is, or whether the acceleration is even constant. So they haven’t written motor drivers with the necessary precision. So for the S2, I had to write a new motor driver to run it with the required precision.

      The pulse width modulation frequency is typically 20kHz, and my motor driver (as well as the original s2 motor driver written by Phil Pilgrim) polls the wheel encoders every pulse (that’s every 50-micro-seconds) and adjusts the width of the **very next pulse.** Using assembly language and some programming cleverness, all of the computations can be done in less than 50 micro-seconds (much less, in fact) so that the width of the next pulse can be determined before the current pulse is over.

      Other systems like the Arduino-based robots, legos, etc. offer only higher-level, courser access to the sensors and the pulses of the PWM. They only poll the wheel encoders after many pulses have passed, and once they set the PWM frequency, it is maintained also for many pulses before it can be reset. The computations are not optimized to give more precise control. That is, if they have wheel encoders at all. And if they do have wheel encoders, the precision is likely to be several mm rather than the 0.25mm precision of the s2.

      Sorry this is long-winded, but hope it helps answer the question. I don’t want to discourage anyone else from trying, but want to pass along my experience as well. I also started out thinking that among all the robotics systems out there, it must be fairly easy to do what i wanted. I figured any of them, or many of them would do. Just didn’t turn out that way.

      Matt

      • June 24, 2013 11:37 am

        Awesome information Matt!
        I read on your blog about your trials and tribulations, but I wasn’t sure if you had tried the NXT (I would have guessed yes, but it is a bit expensive). That’s interesting to hear more specifics about controlling the PWM.

        This morning I was thinking about bringing home a motion sensor to test out the NXT, and my first thought was, “first I have to figure out an easy way to calibrate speed,” because as you mention, the controls are higher level go-to commands. And while I can do this quite easily, it would mostly be voodoo for the students. It could also be a very worthwhile and interesting problem for them to work on, but would take them away from the specific learning objectives of motion (darn you, full curriculum!).

        I also agree with your thoughts on the need for accuracy when building new models. Another place I’ve been frustrated with this is in the constant force model and the modified Atwood apparatus experiment. That’s a whole other discussion, but the work needed to tease out the relationship was excruciating with the equipment (and skills) I had.

        A bit OT, but I’m curious… what level of programming did you have before venturing into the motor driver?

        I may buy an S2 this summer and I’ll be emailing you for software 😉

      • June 24, 2013 12:56 pm

        Good to know about the wheel encoders, as most low-cost robots don’t have encoders, but rely on much cruder schemes. Did any of the robots you looked at use stepper motors or brushless motors? Both of those can be set to provide high positional accuracy without needing an external encoder, and brushless motors can be controlled to get high accuracy on the velocity. Using a brushed motor and PWM is cheaper, but harder to get the precision you wanted without a very tight servo loop (which seems to be what you implemented). Did you need to implement a PID controller, or was a simpler controller adequate?

      • Michael Mannix permalink
        July 8, 2013 5:10 pm

        Matt,

        Wow…I wish I had this to chew on before I wrote my grant proposal to Toshiba to fund my purchase of the new Lego Mindstorm kits (EV3 not NXT). I was awarded the grant and I will get the kits in early August. I think some of my ideas will work, but I am now prepared to adjust my expectations for performance of the EV3s in terms of motion precision.

        Great site, John. Valuable input from many fellow physics teachers.

  2. July 3, 2013 5:04 pm

    John, can you provide some indication of why the USB interface doesn’t work on a Mac? Doubling the price for Bluetooth equals ouch!

    • July 3, 2013 8:26 pm

      Actually Brian, Matt and I are able to get it to work using the USB to serial connector this past weekend. I’ll be posting more details soon.

  3. July 22, 2013 9:44 am

    I have this kind of thing working on the NXT’s! It’s working very well. It’s based on a PID algorithm to control the motor power. I just wrote it up briefly here: https://sites.google.com/site/nxtkinematics/

Leave a comment