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.

Make an “on/off” button using the Mindstorms touch sensor

This is a relatively simple program that turns a Mindstorms touch sensor into an on/off or start/stop button. I wrote this for a rudimentary robot that includes one motor connected to the EV3’s Port A. The touch sensor is connected to Port 1. Motors are connected to lettered ports and sensors are connected to numbered ports. Writing the program took several steps.

First, I wrote a program that simply turns on the motor.

Screen Shot 2017-09-10 at 1.07.24 PM

This program includes two programming “blocks”. The start block, which is necessary to run any program, and the large motor block. In the large motor block, I indicated Port A, because that’s the port that my motor is plugged into. The instruction to turn on the motor is sent to whatever port is indicated in the programming block.

Next, I inserted a wait block before the large motor block.

Screen Shot 2017-09-10 at 1.21.15 PM

In the wait block, I specified Port 1, selected the touch sensor (underneath the icon for the hourglass), selected “compare – state”, and then selected “2”. State “2” means that the touch sensor has been “bumped”. (“0” would mean that the touch sensor has been released, and “1” would mean that the touch sensor is being pressed and held.)

If I ran the above program, “bumping” the touch sensor would cause the motor to start revolving. However, bumping the touch sensor again would not stop the motor.

Next, at the end of the existing program, I added another wait block, and another large motor block. I configured the second wait block just like the first wait block. The large motor block, at the end of the program, is configured to turn the motor off.

Screen Shot 2017-09-10 at 1.23.44 PM.png

When I run this program, bumping the touch sensor will cause the motor to rotate (to turn on); the next time the touch sensor is bumped — whether immediately after, or twenty minutes later — the large motor will stop.

Incidentally, when the large motor block is configured to turn off the motor, you have the option to tell the motor to brake, or to let it coast to a stop.

Screen Shot 2017-09-10 at 1.23.27 PM.png

I chose to let it coast to a stop.

Now, my program allows the touch sensor to first turn on the motor, and then turn it off. However, once it turns the motor off, the motor won’t turn on again unless I re-start the program.

In order to turn the motor on again by simply bumping the touch sensor, I put all of the blocks in my program — except for the Start block — inside a “loop”. The loop is a very powerful programming tool. Anything inside of it can repeat either forever or until some specified event happens. In this case, I’m going to put my program inside a forever loop.

Screen Shot 2017-09-10 at 1.30.47 PM.png

Notice that at the end of the loop, there is a symbol for infinity (nearby the word “unlimited” appeared when I hovered over the symbol with my cursor).

This program has turned the touch sensor into an on/off button. After I download it into my EV3, I will need to start the program running before the “on/off” button works.