Two Robots That Talk in Tones

Two small omnidirectional robots have to do something neither can do alone. The commander has a camera: it explores a road network marked with ArUco markers, spots the ball and plans the route. The worker has no camera but has a gripper: it drives the route it's given, picks up the ball and brings it back. They have no radio link. The only channel between them is sound.

The brief asked for exactly that: localise with an on-board camera, invent a "robot language" of acoustic signals that survives a noisy room, synchronise sending and receiving without any radio, navigate on your own, and keep requirements, design, tests and history in GitLab.

1. 1.

   Seeing the road network

   The commander detects ArUco markers in the camera image and estimates their pose with the calibrated camera. Each marker stands for a junction and the directions you can take from it. A state machine turns, lines up with the next marker, drives to it and writes down what it found.

2. 2.

   Building the map

   Every junction becomes a node in a graph, with its distance, heading and open directions. Once the ball has been seen, Dijkstra gives the shortest path, which is turned into relative instructions: left, right, straight.

3. 3.

   Talking in tones

   Each 4-bit symbol is a sine tone between 500 and 4250 Hz in 250 Hz steps, followed by a separator tone, played through PulseAudio. The receiver records with ALSA, runs an FFT with FFTW and takes the strongest valid frequency. A symbol only counts once it's been heard several times in a row.

4. 4.

   Packets

   A packet starts with a fixed nibble sequence that includes the receiver's ID, then an acknowledgement, the payload and a CRC32. A misheard command gets thrown away instead of driven.

5. 5.

   Driving

   Velocity commands go to an omnidirectional controller in ROS 2. A custom ros2_control hardware interface sends the wheel commands over USB serial to an STM32G4, which generates the motor PWM.

Every component has its own test program: camera input, marker detection, the street network, the audio protocol, the microphone filter, the speaker and motor control. The integration tests are written up with logs and videos. Three things came out of them:

• Markers that weren't seen reliably. The white border around the markers was too narrow. Bigger markers with a wider border fixed it.
• Overshooting when lining up. The rotation corrections were too aggressive, so the marker jumped from one side of the image to the other. Calmer turning and a different stopping distance made gate passes repeatable.
• Testing the talking without the driving. Commander and worker ran the full logic with real audio between them but with the motors off. That way path planning and communication could be checked separately from motion.