Category Archives: calico

Calico Myro Robot Simulation: faster than real-time

A few Myro users have wondered what it would take to make the Calico Myro simulator run faster than real time. This is possible in the current Myro (Calico version 2.4.4 and earlier). In addition, Calico 3.0.0 has a new method, called simulate:

Myro.Simulator.simulate(duration, stepTime)

This method will move the robot for duration (given in seconds), stepping stepTime units at a time, and then update the Simulation window.

Below you will find an example of using the simulator decoupled from real time. The following uses the new ICalico notebook interface.

In [1]:
import Myro
In [2]:
Myro.init("sim")
robot = Myro.getRobot()
You are using:
   Simulated Fluke, version 1.0.0
   Simulated Scribbler 2, version 1.0.0
Hello, my name is 'Scribby'!
In [4]:
robot.setOption("show-sensors", True)
In [5]:
Myro.getSimulation()
Out[5]:
In [6]:
Myro.getSimulation().stop() # stop the simulation loop
In [7]:
robot.forward(1) # queues request to move
In [8]:
robot.update() # fires waiting requests
In [9]:
robot.setPose(100, 250, 0) # manually position robot
In [10]:
Myro.getSimulation().simulate(.1) # simulate some time
In [11]:
Myro.robot._getLocation() # normal robot.getLocation() would fire in robot.update()
Out[11]:
[151.19999694824219, 250.0]
In [12]:
Myro.getSimulation()
Out[12]:
In []:

The Future of Python

I am a big fan of the programming language Python, and was one of the first people (along with my colleagues) to write about using Python in computer science education. That year, 2003, was probably too early for many schools to even consider using Python as a language for the introductory CS courses (which we call CS1), because they were just switching from C++ to Java.

Since that time, we have fully embraced Python in our courses. Personally, I have worked for the past 8 years to make using Python easy and accessible for all students, especially those from non-traditional backgrounds and underrepresented groups. In the early years, we used the de facto standard editor for Python, called IDLE. IDLE has always had issues, but perhaps not more than the entire Python ecosystem itself. In the end, we ended up writing our own editor, and, in fact, creating our own entire “stack” of software—we package everything needed to do cool stuff, including graphics, music, text-to-speech, robotics, and more.

Python’s motto is “batteries included” because it has an extensive standard library that allows much functionality without having to download additional modules. But, if you stray from the standard library, then things get hairy quickly. Take, for example, text-to-speech. This is the functionality that allows you to take text and produce the sound waves on your speaker of a human-sounding voice. You know, like Siri or Her. Such functionality is often implemented as a low-level library, often written in C. These libraries often need to be compiled for each type of computer (Mac/Windows/Linux * 32bits/64bits  * version). On top of the low-level libraries there are often “wrappers” that allow them to be used from Python. Trying to make a simple Python interface for students to use on whatever computer they have turned into a impossible compatibility task—there were just too many variables changing too quickly.

In the end, we  created a system, called Calico, that contains all of the bits necessary, with very few dependencies on low-level libraries, and no wrappers. I’ll be writing more about Calico in the future.

In a recent post on the idle-dev mailing list, a link was posted to a video by Jessica McKellar on “The Future of Python“. Jessica points out many issues with Python, and makes many good suggestions, and I agree with most of her main points. But, I don’t think she goes far enough. For example, she says (around the 10 minute mark) that part of the problem with IDLE on Windows is that there aren’t enough developers that are invested in the problem. I would say that there aren’t enough IDLE (and Python) developers that actually have to wrestle with using Python in the classroom.

How do you install Python (say on the Mac or Windows), and run IDLE? How do you make Python say “hello, world” out of your speakers? How do you make a window and draw a shape? It is too complicated to get to the point where you can do these things.

My suggestions:

  • IDLE needs its own Guido. Someone needs to make hard decisions to make IDLE useful for beginners. IDLE should focus on doing intro CS (at all levels) well. It should have an easy-to-use stepper/debugger. This IDLE-Guido should be in the classroom everyday, and be a visionary.
  • There needs to be a complete Python environment (with easy access to graphics, audio, devices) ready for easy download and install, with IDLE (or a new editor) prominently visible.

Until we tackle these two issues, look for future “Future of Python” suggestions that aren’t that different from past ones.