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: http://thesandyislandreports.net/

Project Perspective

The New Velocity is a sophisticated exploration of artistic technology and kinetic interaction. By focusing on the essential building blocks—the motion-to-generative-plotting mapping and robust high-performance Processing-to-Servo-dispatch logic—you'll learn how to communicate and synchronize creative tasks using a specialized software logic and a robust high-performance setup.

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.

Technical Implementation: Motion Vectors and Generative Coordinates

The project reveals the hidden layers of simple sensing-to-motion interaction:

• Identification layer: The SHARP IR sensor acts as a high-resolution spatial eye, measuring each point of the sand pile's surface to generate coordinate data for the generative-dispatch.
• Conversion layer: The system uses a high-speed digital protocol to receive high-speed PWM data chunks to coordinate mission-critical sensing tasks.
• Kinetic Interface layer: Two NEMA 17 Stepper Motors provide high-definition visual and mechanical feedback for each artistic status check (e.g., Plotting Movement).
• Visual Interface layer: An OpenFrameworks application (Generative) provides a manual data-dispatch or automated cloud-sync status check during initial calibration to coordinate system status.
• Processing Logic: The server code follows a "state-to-plotter" (or artistic-dispatch) strategy: it interprets the sensor inputs and matches the servo and projector states to provide safe and rhythmic phantom-island plotting.
• Communication Dialogue Loop: Note codes are sent rhythmically to the Serial Monitor during initial calibration to coordinate system status.

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).

Hardware-Creative Infrastructure

• Arduino Uno: The "brain" of the project, managing the multi-directional sensor sampling and coordinating the stepper motors and Processing sync.
• SHARP IR Proximity Sensor: Providing clear and reliable "Trigger Link" for every point of the sand pile scanning experience.
• High-Precision Stepper Motors (NEMA 17): Providing high-capacity and reliable physical interface for each successful "Kinetic Mission."
• Custom mechanical Gantry (Slider & Turntable): Essential for providing clear and energy-efficient protection for every point of the hardware in the frame, as seen in the project images.
• Projector Overlay (via Raspberry Pi/OpenFrameworks): Essential for providing clear and energy-efficient visual feedback for every point of the data sensing art.
• Micro-USB Cable: Used to program the Arduino and provides the primary interface for the system controller.

Prototyping:

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:

Future Expansion

• OLED Identity Dashboard Integration: Add a small OLED display to show "Total Plots Count" or other system status.
• Multi-sensor Climate Sync Synchronization: Connect a specialized environmental sensor to perform higher-precision data logging.
• Cloud Interface Registration Support Synchronization: Add a specialized web-dashboard on a smartphone over WiFi/BT to precisely track and log the total social history of the plots.
• Advanced Velocity Profile Customization Support: Add specialized machine learning to the code to allow triggers to be changed automatically based on user interaction patterns.

The New Velocity is a perfect project for any science enthusiast looking for a more interactive and engaging creative tool!

[!IMPORTANT] The Stepper Motors require an accurate Torque load mapping (e.g., for a heavy plotter mechanism) in the setup to avoid power system failure; always ensure you have an appropriate Fail-Safe flag in the loop if the serial bus overloads!