Zeno’s dichotomy paradox

Recently we built and programmed an EV3 that would illustrate Zeno’s dichotomy paradox (the popular paradox arguing that one can never arrive at a destination, because one first must travel halfway there, and then again must travel half of the remaining distance, etc.).  Using the Mindstorms IDE, we created variables that were updated with each loop of the program. Here’s what the program looked like:


The primary challenge in this program, for me, was that the robot first must “learn” how great a distance it can travel when its motors make one rotation (or turn for a fixed period of time, etc.).

You might notice that our motors are moving backwards; that was a result of the way the motors were mounted relative to the ultrasonic sensor, which determined the font or face of the robot. Also, you might notice that our robot learns what distance it travels when it moves a mere 0.25 rotations. Moving a full rotation or more would have led to a more accurately performing robot, since much of the mere 1/4 rotation is lost to friction and inertia.

We also had our robot begin its illustration of Zeno’s paradox after making this initial measurement, without having it return to its original starting point. If one wished, you could have the robot move forward, make the calculation, and then back up again to the initial start.

Here, math blocks create and update variables related to distance that can be traveled given a fixed number of motor rotations, and related to the distance remaining to be traveled.

Screen Shot 2018-04-02 at 4.55.43 PM.png

We added sound effects to indicate clearly to the audience which step our robot had just concluded. The elephant roar indicates the robot has just reached the halfway point in its journey. Earlier, an insect chirp indicates the robot has learned what distance it travels after a 1/4 rotation of the motors.

The ultrasonic sensor was a major limiting factor in this project. It’s inaccurate under 1 cm, and cannot read distances beyond ~255 cm.


As a parallel activity, I recommend illustrating the paradox in Scratch. Programmatically the Scratch environment — particularly the way that variables are created and edited — is a bit more straightforward than the variables blocks in the LEGO Mindstorms environment.

Here is my Scratch illustration of the paradox.

Minimalist Challenge

We recently had a Mindstorms challenge with the following rules:

  • robot must move in a straight line
  • robot need not move quickly, nor even roll (it might crawl or drag parts of itself along the ground)
  • the winning robot is the robot made out of the fewest pieces.

We counted every piece, including every single peg and cable. Battery and EV3 brick counted as one.

Of three competing teams, a first submission was made up of 23 pieces. That team was asked to study their robot for non-essential equipment. They returned with a robot consisting of 21 pieces, and later, with a robot consisting of 17 pieces.

A second team began with a robot made with 20 pieces, returned with a robot of 16 pieces, and ended with a robot with only 11 pieces.

The winning submission had only 8 pieces, on the first try.

Can we make do even less?