Project showcase
The New Velocity

The New Velocity © CC BY-NC

The New Velocity is a machine that plots the phantom Sandy Island in digital means.

  • 1 comment
  • 6 respects

Components and supplies

Apps and online services

About this project

The New Velocity is a machine that plots the phantom Sandy Island in digital means. By reproducing the same phenomenological conditions upon which the island was seen in 1876, it seeks to reinsert the charting glitch that endured in worldwide maps until 2012. The machine records new datasets that support the further existence of the island by manipulating its digital presence.

Sand piles are scanned by an infrared proximity sensor, which moves up and down over a platform replicating the movement of a ship floating over the high seas. The spacial data is mapped and visualized in realtime. The machine operates under four different preset modes, one for each dataset it records: coastline coordinates, water depth surroundings, topographical elevation and digital geotagging. Each set of datasets evidences the presence of an islet within the island’s range, and is posteriorly uploaded to Sandy Island’s open data bank for spreading.

The project investigates a charting error that persisted in cartographic maps even after the advent of digital media. It speculates how data and physical phenomena are entangled, and how in contemporaneity, the two have the same weight under digital media. The New Velocity explores how the phenomenon of Sandy Island happens only under certain speeds, when piles of sand and piles of data have the same faulty consistency.

The recorded datasets are available at:

caption (optional)

How it works:

The machine has an Arduino Uno controlling two NEMA 17 stepper motors through two low-voltage stepper motor driver carriers. One of the motors controls the "turntable" with the sand above, using a simple aluminum mounting hub. The other one controls the 1-axis slider in vertical motion, using an aluminum shaft coupler coupled to a threaded rod and a traveller. The vertical slider contains a red laser diode and a 4-30cm SHARP infra-red sensor. The controller has 4 simple red LEDs, and a button switch that pauses and plays the motion/recording of the machine.

The Arduino written program controls the motion of the motors, the controller LEDs, and listens to the controller button and the slider infrared sensor's data. The laser diode gives only a physical feedback signalling that the sensor is currently parsing data, and the LEDs are signalling which current preset/dataset is being parsed. The motors are run using the AccelStepper library for Arduino, and each one of the datasets parsed has a hard-coded preset of movement at the program. Even though the "sandy island" is the same, each preset generates different data due to the different movement of the slider and/or the turntable.

Last but not least, the data retrieved from the sensor is transferred trough an usb serial cable to a Raspberry Pi running a program written in C++ using the framework OpenFrameworks to generate the realtime generative visuals, and also to parse the Arduino's data to different datasets (available here).


It took me a while to test and find the best setup for the machine, specially regarding the motors and the way I was going to produce the movement. In the end, I chose to use two stepper motors in order to be able to control more accurately their movement, and also a low voltage driver carrier to facilitate the whole thing and more easily play with the AccelStepper library.

A tricky thing was: while running the whole setup together in the Arduino Uno, it became considerably slow. I also tried switching it for a Mega with no success. Separately everything worked like a charm, but together, I was stepping on problems. It wasn't so easy to find that the digitalWrite() and analogRead() inside the main loop were the ones mainly causing this. My first solution was to customize a "Timer" class inside Arduino, in order to call these functions only when needed. But that has only partially solved the problem. The final solution, although not preferable, worked much better than expected: using lower level commands to talk directly to the registers.

Bellow you can check some more photos (and a video) of one of the first working prototypes of the machine:



Similar projects you might like

Towards an Arduino-Powered Satellite Tracker

Project tutorial by Thomas Le Goff & Maxime Moury

  • 6 respects

RepRap 3-Dimentional Additive Manufacturing Printer with IOT

Project showcase by Team Tiny Ants

  • 26 respects


Project showcase by 3 developers

  • 29 respects

Home Automation Using Raspberry Pi 2 And Windows 10 IoT

Project tutorial by Anurag S. Vasanwala

  • 786 respects

Temp. And Humidity Sensor With A CR2032 For Over 1 Year!

Project showcase by Talk2

  • 84 respects

Automated Garden

Project tutorial by Thomas sxt

  • 89 respects
Add projectSign up / Login