DocBot: a sound-controlled delivery robot

Project details

1. 

   A medicine-delivery robotics exercise

   Our two-person team programmed an e-puck 2 teaching robot for a hospital-to-village medicine-delivery scenario. The assignment required a distance sensor, the stepper motors and an additional sensor of our choice. We chose the microphones, so that the robot could take sound commands.

2. Distance sensing and delivery sequence

   The time-of-flight sensor measures distance using the return time of an infrared pulse. We chose it over the infrared proximity sensors because it is more precise. The robot uses the detected obstacle to mark arrival, deliver the medicine and turn around. At the hospital, it is reloaded and waits for the next command.

3. FFT recognition of sound commands

   The program applies a fast Fourier transform to the microphone signal and selects the strongest frequency. A 250 Hz tone commands forward motion; 359 Hz represents a suspicious noise and triggers a stop and scan; 401 Hz represents an explosion and sends the robot back to the hospital at full speed.

4. Thread priorities and shared state

   Two ChibiOS threads handle sound processing and distance sensing. A mutex protects the shared flag indicating whether medicine has been delivered. Distance sensing has priority: when an obstacle marks arrival, the robot follows the delivery sequence even if a 401 Hz sound command would otherwise send it back to base.

5. Return distance from motor steps

   The program estimates distance from the stepper motors’ positions. Forward motion adds the average of both wheels’ step counts to a counter; reverse motion subtracts it. The robot stops when the counter reaches zero, using this estimate to return to its starting point without an external position sensor.

6. Counter resets and shared data

   Two problems required debugging. The return-distance counter was not reset after a completed delivery; resetting motor positions after the turn fixed it. The delivered flag was also read unreliably from another thread. Protecting that access with the same mutex as the write made the shared state consistent.