What we’ve actually built

A 🎾 CHASE toggle next to the joystick. Flip it on, and:

• The robot looks for a ball in the camera feed.
• Off-center → it turns towards it.
• Small (far away) → it drives forward. Big enough (close) → it eases off and stops.
• Ball out of frame → it just stops, same as letting go of the joystick.
• Manual controls (joystick, keyboard, per-wheel sliders) go greyed-out and unresponsive while this is on, so nothing’s fighting the robot for the wheel. The ⏻ MOTOR ON/OFF buttons still work regardless — always an independent kill switch, whoever’s driving.

Finding the right brick

Same move as every other feature so far: before writing a line of code, went and read arduino/app-bricks-py to see what already exists. Turns out there’s a whole family of vision bricks — gesture_recognition, mood_detector, image_classification, object_detection, visual_anomaly_detection — and the one that actually fits is video_objectdetection: continuous detection off a live camera stream, with per-label callbacks carrying a confidence score and a bounding box.

Its brick_config.yaml lists:

model_by_boards:
    - platform: ventunoq
      model: yolox-qnn-object-detection
    - platform: unoq
      model: yolox-object-detection

UNO Q — this exact board. Not a VENTUNO-only NPU thing, unlike the neural TTS detour a couple posts back. Genuinely usable here.

No training required — just check the label list

The obvious worry: does a generic pretrained model know what a tennis ball is? Didn’t want to assume, so went and checked models/models-list.yaml in the same repo before writing any detection code — it’s a YOLOX-Nano model trained on COCO’s 80 classes, and the label list includes, verbatim:

- sports ball

That’s the actual class name (there’s no separate “tennis ball” class in COCO, but “sports ball” covers it — it’s the canonical example object for that class in the dataset). So: zero custom training, zero Edge Impulse model work. Just register a callback for a class that’s already in the box.

from arduino.app_bricks.video_objectdetection import VideoObjectDetection

detector = VideoObjectDetection(camera=shared_camera, confidence=0.5)
detector.on_detect("sports ball", on_ball_detected)
detector.start()

One camera, two features fighting over it

video_objectdetection wants its own Camera to forward frames to the detection sidecar. We already have one open, for last post’s live feed. Tried to hand-wave past this and it immediately mattered: Camera claims its physical device the moment it’s constructed — there’s an actual registry in the framework’s own source specifically so auto-selection doesn’t grab something already in use — so a second, independent Camera("usb:0", ...) for the same webcam wouldn’t just contend for bandwidth, it’d fail outright.

Good thing VideoObjectDetection(camera=...) takes an existing instance instead of always making its own. Added a small accessor to camera.py:

def get_camera():
    """Blocks until the startup attempt above has settled, then returns the
    shared Camera instance — or None if it never started successfully."""
    _ready.wait()
    return _camera

vision.py calls that instead of constructing its own, so both features share the one physical connection to the one webcam instead of racing for it.

Steering is just proportional control

No path planning, no PID tuning, nothing fancy — just “how far off-center is it” and “how big is it,” recomputed fresh on every detection message:

PID - Proportional Kp, Integral Ki, and Derivative Kd, only recently saw this video from Electronoobs and it looks complicated https://www.youtube.com/watch?v=JFTJ2SS4xyA

def _steer_towards(bbox):
    x1, y1, x2, y2 = bbox
    frame_w, frame_h = camera.RESOLUTION
    center_x = (x1 + x2) / 2
    box_h    = max(1, y2 - y1)

    offset     = (center_x - frame_w / 2) / (frame_w / 2)  # -1 .. +1
    size_ratio = box_h / frame_h                             # 0 .. 1

    turn     = max(-100, min(100, offset * TURN_GAIN))
    throttle = max(0, min(MAX_THROTTLE,
                          (TARGET_SIZE_RATIO - size_ratio) / TARGET_SIZE_RATIO * MAX_THROTTLE))
    return turn, throttle

turn/throttle go through the exact same mix_drive() the joystick posts through from two posts ago — one function, one place that knows how a turn+throttle pair becomes two wheel speeds, whether a human or a neural network produced them. MAX_THROTTLE is capped well under full speed on purpose — this thing drives itself with nothing watching for obstacles, no reason to let it move at joystick speeds.

What actually broke on real hardware

First real test went nowhere: App.run() never scheduled VideoObjectDetection’s background loops, since the brick got built (on its own thread, after App.run() had already started) too late for the scheduler to notice — confirmed by the sidecar sitting there waiting for a connection that never came. Fixed by just running those two loops ourselves in plain daemon threads instead.

Seeing what it’s actually seeing

Once frames were flowing, the ball’s box kept flickering against other objects (a bed, a cup) even on a dead-static scene — turned out to be real per-frame confidence noise, not a “one object at a time” limitation (it’s a genuine multi-object detector, and no, it can’t be restricted to only look for balls — fixed 80-class model, no filter option). Fix: draw a box for everything it sees, not just the ball, and fade them out over a few seconds instead of hard-cutting the instant one frame doesn’t reconfirm them.

The “lost the ball” behavior that didn’t need writing

Didn’t need a lost-ball timeout — Post 1’s STM32 watchdog already stops the wheels when commands stop arriving, same as a dropped wifi connection, for free.

It worked — and then drove straight past the ball

Reacting to every single detection message overshot the ball almost every time — no braking distance. Fixed by pulsing instead: one short move, stop, pause, then decide again from a fresh look — and VideoObjectDetection’s own per-label lock already discards anything that arrives mid-pause, so no new state machine was needed to make that stick.

What’s next

Well that’s kind of it. Thrilled at how far we got to an actual auto driving EV.

The codes

• https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

What we set out to do

The pitch was simple: enter the Element14 EZ-EV challenge, build a little robot that can drive itself down a hallway, and see how far “one 15-year-old, one 18-year-old sister filling in the official entry-age box, and an Arduino UNO Q” could get in a few weeks. We even wrote ourselves a five-post plan before touching a soldering iron:

1. Basic motion primitives
2. Remote control over the web (camera + WASD, “puppy on a leash”)
3. Simple autonomy (line-following down the hallway with tape)
4. Expand driving (manual override on top of the autonomous line-follower)
5. Pick one: better telemetry, voice command, or corner-mapping

Reasonable plan. Didn’t survive contact with the actual robot.

What we actually built

• Post 1 — wheels turning. Two continuous-rotation servos, bit-banged PWM because the board’s hardware PWM pins are locked to the wrong frequency, a web page with a slider per wheel, and a 1-second no-command watchdog on the STM32 side that turned out to be the single most-reused idea in the whole project.

  

• Post 2 — a voice, a siren, and lasers. Not autonomy. Sound. A whole soundboard — effects, an air-raid siren, an AusAlert tone, text-to-speech, cruising music — because we went looking for a way to stabilize the chassis with pantograph legs, gave up on that, and got distracted by making the thing loud instead.

  

• Post 3 — one joystick instead of two sliders. Drag it, or drive with WASD/vim keys, plus every bug that comes with actually connecting two wheels at once for the first time.

  

• Post 4 — eyes. A live MJPEG camera feed, the “puppy on a leash” idea from the original plan, just three posts later than scheduled and built entirely differently than imagined.

  

• Post 5 — chasing a tennis ball. Not the line down the hallway the plan called for — real on-device object detection, a pretrained neural network finding a “sports ball” and the robot driving itself towards it.

  

Zero hallway tape was harmed in the making of this project.

Thanks for reading

Five posts, one robot, a lot more debugging than either of us expected going in. Whatever comes next for Hall-w-EV, it’ll probably also replace whatever we plan to do with something we didn’t expect — and that’s kind of the whole point.

The codes

• https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

What we’ve actually built

A live video feed right on the same page as the joystick — the “puppy on a leash from your phone” post the original plan called for, minus the actual leash. Point the robot somewhere without needing to be in the room with it.

Checking what the framework already gives you

Same move as the TTS detour: before writing any camera code, went and read arduino/app-bricks-py to see what Arduino already ships. Turned out app_peripherals/camera is a whole unified abstraction — one Camera class covering CSI, USB (V4L), IP, and even WebSocket sources, same family as the Speaker peripheral the sound system already uses:

from arduino.app_peripherals.camera import Camera

camera = Camera("usb:0", resolution=(640, 480), fps=15)
camera.start()
frame = camera.capture()   # numpy array, or None
# or: for frame in camera.stream(): ...

Since Speaker was already confirmed bundled in this app’s base container with zero extra install, betting Camera is too — no new brick, no sidecar container, just a normal peripheral call from our own code. The only actual new dependency is opencv-python-headless, for turning each frame into a JPEG.

The dumbest frontend that works

The tempting-but-overbuilt version of this involves a <canvas>, a WebSocket, and a JS render loop pulling frames off it. Skipped all of that:

<img id="cameraFeed" src="/api/camera/stream" alt="Live camera feed">

That’s the entire client-side video pipeline. GET /api/camera/stream returns multipart/x-mixed-replace — a boundary-delimited stream of JPEG frames — and browsers have known how to render that straight into an <img> tag since basically forever. No JS needed for the video itself, just a listener on the error event for when there’s no camera to show:

cameraFeed.addEventListener('error', () => {
  cameraFeed.style.display = 'none';
  fetch('/api/camera/status').then(r => r.json()).then(data => {
    cameraError.hidden = false;
    cameraError.textContent = data.error || 'camera stream unavailable';
  });
});

Same “surface the real reason, not a cryptic broken icon” instinct as the sound system’s error banner from a couple of posts back.

Starting the camera without blocking everything else

Camera.start() has its own connection retry loop with exponential backoff — reasonable for “give the USB device a moment to enumerate,” bad if it’s sitting on the same startup path as the wheel and sound APIs. A slow or missing camera shouldn’t hold up driving the robot.

So python/camera.py kicks off Camera(...).start() on a background thread at import time, mirroring sounds.py’s general shape:

def _start():
    global _camera, _error
    try:
        cam = Camera(SOURCE, resolution=RESOLUTION, fps=FPS)
        cam.start()
        _camera = cam
    except Exception as e:
        _error = str(e)

threading.Thread(target=_start, daemon=True).start()

status() reports (ok, error) off that shared state, and the stream route just checks it before handing back the actual multipart response:

@web.route('/api/camera/stream')
def camera_stream():
    ok, error = camera.status()
    if not ok:
        return jsonify({'ok': False, 'error': error}), 503
    return Response(camera.mjpeg_frames(),
                     mimetype='multipart/x-mixed-replace; boundary=frame')

mjpeg_frames() itself is a small generator wrapping Camera.stream(), JPEG-encoding (cv2.imencode) each frame as it comes.

What’s next

Camera’s on, joystick works — next logical step is doing something with the two together: point-and-drive, or finally trying that on-device object detection now that we know UNO Q supports in it’s demo bricks.

The codes

• https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

What we’ve actually built

Since Post 1, driving meant dragging two independent vertical sliders. Well actually up till now we haven’t connected both servos but yeay a slider per wheel like driving a tank, and how do you even control 2 controls with 1 mouse? So the control page now has:

• An on-screen joystick pad — drag the stick in any direction, let go and it springs back to center and stops, same “throttle stick, not a light switch” feel as the wheel sliders had.
• WASD and vim’s hjkl both drive the same stick — whichever one you reach for first works, and they combine, so forward + turn gives you a proper diagonal instead of a hard pivot.
• The old per-wheel sliders are still there underneath, now relabeled “Manual Wheel Control” — occasionally useful for trimming one wheel on its own, but the joystick is the one you actually want to drive with.

Keeping the mixing in one place

The tempting shortcut was to do the “turn this drag angle into two wheel speeds” math in JavaScript and post straight to the existing /api/wheel/<n> endpoint per wheel. We didn’t do that — the frontend has no business knowing how many wheels this thing has or how they’re mixed. Instead the page posts one thing, {x, y} (turn, throttle, both -100..100), to a new POST /api/drive, and the actual arcade-mixing math lives entirely on the Python side:

def mix_drive(x, y):
    x = max(-100, min(100, int(x)))
    y = max(-100, min(100, int(y)))
    return max(-100, min(100, y + x)), max(-100, min(100, y - x))

One function, one place that knows wheel1 = throttle + turn and wheel2 = throttle - turn. If we ever add a third wheel, a different chassis, or want to curve the turn response, that’s a one-function change, not a hunt through frontend code.

Mirrored servos, mirrored bug

Software done, so time to actually push the stick forward with both wheels connected at once — first time we’d had them both hooked up and driven together rather than one at a time. Robot spun in place instead of driving forward. Wheel 1 was doing exactly what it should; wheel 2 was going backward.

Both servos are the same part, wired the same way, running the same firmware — but they’re bolted to opposite sides of the chassis, mirror image of each other, the same way your left shoe and right shoe are mirror images built from the same last. “Spin clockwise” looks like forward from one side and backward from the other, so the exact same pulse width that drove wheel 1 forward drove wheel 2 in reverse. Nothing wrong with the mixing math from the last section — mix_drive() was handing out perfectly correct forward speeds for both wheels, it’s just that one wheel’s servo interprets “forward” backwards from the other.

Fixed it at the one point in the firmware that turns a commanded speed into an actual pulse, not by touching the mixing math or anything upstream of it:

#define WHEEL1_REVERSED false
#define WHEEL2_REVERSED true
...
servoFrame(SERVO1_PIN, speedToPulseUs(WHEEL1_REVERSED ? -wheel1Speed : wheel1Speed),
           SERVO2_PIN, speedToPulseUs(WHEEL2_REVERSED ? -wheel2Speed : wheel2Speed));

wheel1Speed/wheel2Speed themselves — the values the Bridge handlers store, the values the Python side and the joystick’s arcade mixing both reason about — still mean “positive is forward” for both wheels. The mirroring correction is a single negation right at the pulse-generation step, isolated to the one wheel that’s actually mounted backwards. If it turns out a future chassis needs the other wheel flipped too (or flipped back), it’s a one-line change, not a rethink of the mixing.

A real OFF switch

With the direction sorted, one servo was still making a faint noise even sitting at commanded speed 0 — the same self-correcting buzz Post 1 first ran into, just quieter now that both servos are trimmed better. Trimming the pot gets you close to the servo’s true center, not exactly onto it, and a held 1500us “stop” pulse still gives the servo’s internal position-holding loop a target to compare itself against. Close-but-not-perfect is still enough for it to keep nudging.

So instead of chasing the trim pot further, we added a real motor power toggle — a button per wheel that does something a commanded speed of 0 can’t: stop sending that servo a pulse train at all.

static void servoFrame(int pin1, unsigned int pulse1Us, bool enable1,
                       int pin2, unsigned int pulse2Us, bool enable2) {
    if (enable1) {
        digitalWrite(pin1, HIGH);
        delayMicroseconds(pulse1Us);
        digitalWrite(pin1, LOW);
    }
    // ...same for pin2/enable2
}

No pulse means nothing for the internal loop to react to — quieter than any stop pulse we could trim to, held or not.

Worth being upfront about what this isn’t: it’s not a real power switch. The board only ever drove the servo signal line — the 5V rail has always come straight off the shared supply with no relay or MOSFET in between , so “motor off” here can’t cut actual voltage to the servo. That would need new hardware — a MOSFET or relay switched from a spare GPIO — not just a firmware change, so we deliberately scoped this to the signal-only version rather than reaching for a soldering iron mid-feature. Given the noise was coming from the signal being held near-but-not-quite-center rather than from anything drawing power at true idle, it’s also very likely the actual fix for the buzz, not just a consolation prize.

“Holding a key” isn’t a real browser event

First pass: listen for keydown, send the drive command once. Worked for about half a second — press w and the robot lurches forward, then stops on its own even though the key’s still very much held down.

Turns out keydown fires once per press, and after that the browser’s own key-repeat kicks in — which is inconsistent across OSes, has a noticeable initial delay, and isn’t something we should be relying on for “keep the motor running.” Worse: [Post 1][14-post-1-wheels] built a 1-second watchdog into the STM32 side specifically so a dropped connection stops the wheels instead of leaving them spinning — and a keydown that fires once and then goes quiet for a while looks exactly like a dropped connection to that watchdog.

Fix was the same pattern the wheel sliders already used for drag events, just driven by a timer instead of input events — track which keys are currently down in a Set, and re-send the current vector on a plain interval for as long as any of them are held:

setInterval(() => {
  if (keyboardDriving) drive(...keyboardVector(), false);
}, SEND_INTERVAL_MS);

keydown/keyup just add/remove from the set; the interval is what actually keeps commands flowing often enough to stay ahead of the watchdog.

The keyup that never comes

Second gotcha, found by alt-tabbing away mid-drive without letting go of w first: the robot kept driving. keyup only fires if the browser is still the one listening — alt-tab, clicking outside the page, anything that steals focus, and the browser just stops delivering key events altogether. No keyup, so our held-keys set never clears.

window.addEventListener('blur', () => {
  if (pressedKeys.size === 0) return;
  pressedKeys.clear();
  keyboardDriving = false;
  drive(0, 0, true);
});

Losing focus now stops the robot immediately instead of waiting out the watchdog’s full second — which, at “robot with wheels in a hallway,” felt like the actually-important version of this bug, not just a nice-to-have.

What’s next

The joystick makes driving nicer, but you’re still driving blind — next up is the camera, so this actually becomes the “puppy on a leash from your phone” post the original plan promised.

The codes

• https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

What we’ve actually built

The control web page now has a “Sound System” panel underneath the wheel controls:

• A grid of sound effects like laser blasts and guns reloading
• An Air Raid Siren, and an AusAlert tone (853Hz and 960Hz played together) inspired by Australia’s emergency phone-alert system
• Text-to-speech (TTS) announcements — inspired by “Giant Voice” systems we’ve seen in videos from Middle East conflict zones and school lockdown drills, telling you to “shelter in place”. Partly inspired by the new Arduino App Lab update, which mentions TTS bricks.
• A volume slider, and a big SHUT UP button, because once you give a robot a siren you will absolutely need a way to make it stop

And most recently: cruising music, so it can play a track while it drives around. More on why that one was trickier than it sounds in a minute.

Hardware distraction

The Braitenberg vehicle chassis we’re using is inherently unstable. Two wheels and a stopper meant it would often tip during testing. Inspired by the pantographs on trains that pass our back yard, as well as drones that can land and stick to a moving object, we tried to build a self-correcting leg system for our EV.

https://www.instagram.com/p/DboDwK_gXT7 credit Zaruba

This took a bunch of experimenting and time. In the end the results weren’t that good, and we realised that once we finally attached a camera to the setup, we’d also need to compensate and auto-correct the camera to point at the horizon.

In the end we dropped the idea and moved on with a couple of wooden blocks.

TTS no work

As the UNO Q updated to the latest firmware of Arduino App Lab, we got briefly excited that there might also be a neural text-to-speech option built in (an actual AI voice model instead of the classic robot monotone) — and there is one, arduino:tts. Got all the way to testing it before finding out it’s built specifically for the new Ventuno Q board and not supported by the UNO Q.

Turns out Arduino just announced the VENTUNO Q. Our UNO Q has 2GB of RAM and no AI chip. VENTUNO Q packs a Qualcomm Dragonwing IQ‑8275 — a proper 40 TOPS neural processor — plus 16GB of RAM, specifically so it can run real local AI: computer vision, offline AI assistants running local speech models, that kind of thing. The neural TTS brick we found needs that NPU to run at all, so on our board it was never going to work — not a bug, just the wrong hardware for the job. There are a couple of overview videos from embedded world if you want to see it in action: developer walkthrough, demo reel. But let’s not let the inspiration of TTS go to waste, after scrounging around we worked out we can use the unix espeak-ng for the talking instead.

Here’s where it got interesting. The siren and the AusAlert tone worked first try. Wav/MP3 Sound effects and text-to-speech? Dead silent. No errors, no sound, nothing.

First theory: volume. Turned out to be half right — the board’s speaker volume genuinely was too low by default, and cranking it with amixer fixed some of it. But effects and TTS still didn’t work, even after that.

Second theory, once we actually looked: the programs we needed (mpg123 for mp3s, espeak-ng for the talking) just weren’t installed. Fair enough, we thought — sudo apt-get install them and done. Except we did that, and which mpg123 on the board clearly showed it existed. So why couldn’t our own code find it?

Turns out: the robot’s Python code doesn’t actually run directly on the board’s Linux. It runs inside a Docker container — basically a little sealed box with its own separate copy of everything. We’d installed the programs onto the board itself, not into the box our code was actually running in. Two completely different places, both called “the board” if you’re not paying attention. Once we docker exec‘d into the actual container and installed things there instead, everything clicked into place — almost. Even that had one more gotcha: the container’s default user isn’t allowed to install anything (Permission denied on a folder called apt/lists/partial, if you’re curious), so it needed:

docker exec -u root hall-w-ev-main-1 apt-get install -y espeak-ng

-u root = “no really, let me actually install this.” Small thing, cost us an hour.

Finding the good stuff

While we were down in that container digging around, we found something way better than what we were looking for: Arduino ships their own official audio tools baked right in — arduino.app_peripherals.speaker.Speaker. It’s a proper Python class for playing sound directly, no external programs needed at all.

As mentioned above, the VENTUNO Q’s TTS brick was kind of cool to stumble into by accident while debugging a sound effect — but a dead end for now. We’re sticking with the classic robot voice, which honestly suits an emergency-siren robot better anyway.

Since the TTS brick’s code is public, we went and actually read it out of curiosity, and it turns out it does basically the same chunk-and-check-cancelled trick we were about to build by hand, just with a lot more going on underneath:

• It doesn’t run the AI voice model in the same program at all — it makes a network request to a separate always-on service and streams the audio back as the model generates it, piece by piece, instead of waiting for the whole sentence to finish.
• Long text gets split at up to 1024 characters, cut on the last ./!/? it can find before the limit, so it doesn’t chop a sentence in half — smarter than our “just cut it off at 300 characters and hope.”
• Cancelling has to happen in two places: locally (stop feeding audio to the speaker) and remotely (tell the AI service currently mid-sentence over the network to actually stop generating).
• There’s even a “warmup” — the instant it starts up, it quietly synthesizes the word “ok” to itself, just so the neural network is already loaded by the time you need it for real, instead of your first sentence being the slow one.

Kind of validating, honestly. The “cut it into pieces, check a flag between each one” idea wasn’t a hack we made up — it’s the same shape of solution the actual Arduino engineers reached for. Theirs just has a neural network and a network request bolted on the front of it.

The Speaker class was the real win though. The simple way to use it plays a whole sound start-to-finish with no way to interrupt it — fine for a short laser blast, useless for “stop the siren right now.” So instead we feed it small chunks (a tenth of a second each) in a loop, and check “should I stop?” between every single chunk:

def _stream_pcm(speaker, sample_rate, channels, samples, stop_event):
    chunk_len = max(1, int(sample_rate * 0.1)) * channels
    for i in range(0, len(samples), chunk_len):
        if stop_event.is_set():
            break
        speaker.play(samples[i:i + chunk_len])

That’s the whole trick behind the SHUT UP button, and behind “press the siren again while it’s already going” restarting it cleanly instead of two sirens fighting each other.

Making espeak-ng actually stick around

Remember that docker exec -u root ... apt-get install espeak-ng fix from earlier? It worked great — for one restart. Then we rebooted the board again and it was just gone. Turns out installing something into a running container by hand doesn’t actually stick — the container gets rebuilt from scratch every time you redeploy, and “by hand” doesn’t survive being rebuilt. Cool, so our talking robot’s voice box was actually a ticking time bomb this whole time.

We did not want to just re-run that command forever every time we updated the code. So: real fix time.

We remembered seeing a brick_compose.yaml mentioned in Arduino’s own code while we were poking around earlier, and it turns out there’s a whole custom bricks feature for exactly this — you can package up your own little service, container and all, as part of your app. Every example of it we could find online only used pre-built images though, never a Dockerfile you write yourself, so we genuinely didn’t know if that part actually worked or if we’d be wasting an evening.

Quick test first: a throwaway folder with just a Dockerfile that installs espeak-ng and then does nothing (sleep infinity), wired up as a brick. Restarted the app to see what would happen.

It built the Dockerfile. For real. Docker log spam and everything, right there in the deploy output — our own robot, building its own container image, from a text file we wrote, installing a package with full root access and zero permission drama, because this time it’s happening at build time, not sneaking in through docker exec afterward.

So we built the actual thing: a tiny container that does nothing but run espeak-ng behind a dead-simple web server —

# POST /synthesize {"text": "...", "voice": "en-us+m3", "speed": 150}
result = subprocess.run(
    ['espeak-ng', '--stdout', '-v', voice, '-s', speed, text],
    capture_output=True, timeout=10,
)
# ...and send result.stdout back as the response body

— and now the main robot code just sends it a sentence over the network and gets a WAV file back, instead of running espeak-ng itself. Since the whole container gets rebuilt from that same Dockerfile every single time we deploy, there’s nothing left to mysteriously vanish. Tested it properly too — full restart, both containers rebuilt from nothing, and the robot could talk again immediately, no manual fixing required. That’s the actual fix, not a “seems fine for now.”

Cruising music (without a 50MB file)

Last thing: we wanted the robot to play a music track while driving around — cruising music. Obvious approach: convert the song to the same format as the sound effects. Except the effects are only a few seconds long, and this song is almost 5 minutes — converted the “simple” way, it would’ve turned a 7MB mp3 into something like 50MB sitting on the robot for no reason.

So instead of converting the whole song upfront, it gets decoded a tiny piece at a time, right as it’s needed, and each piece goes straight into the same chunk-player from before. The song is never sitting fully unpacked in memory or on disk, and we get to reuse all the cancel/restart logic we’d already built.

What’s next

• Camera + remote driving — the “puppy on a leash from your phone” post

The codes

• https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

What we’ve actually built

The brains of the robot are an Arduino UNO Q — it’s got a Linux side and a real-time STM32 side glued together, which is pretty cool because it means we get a full web server and precise motor timing on the same board.

For wheels, we’re using two continuous-rotation servos. If you haven’t met these before: they look exactly like a normal hobby servo (the kind that turns to a specific angle and holds it), except someone’s popped the case open and disconnected the little potentiometer that tells the servo where it’s pointing. Without that feedback, the servo can’t “aim” anymore — so instead of turning to an angle, it just spins continuously, and the angle signal becomes a speed-and-direction signal instead. That makes them perfect cheap wheel motors: no separate motor driver board needed, just a signal wire straight from the STM32.

Here’s the whole trick, in code. Each servo wants a pulse every 20 milliseconds (50 times a second) — 1.5ms means “stop”, 1ms means “full speed one way”, 2ms means “full speed the other way”, and everything in between is a speed in that direction:

#define PULSE_STOP 1500
#define PULSE_FWD  1000
#define PULSE_BACK 2000

static unsigned int speedToPulseUs(int speed) {
    speed = constrain(speed, -100, 100);
    // speed=100 -> 1000us (full forward), speed=-100 -> 2000us (full back)
    return (unsigned int)(PULSE_STOP - speed * ((PULSE_STOP - PULSE_FWD) / 100));
}

One thing that tripped us up: the UNO Q’s normal PWM hardware pins are locked to 500Hz in the board’s config, which is way too fast for servos — they expect a pulse every 20ms, not every 2ms. So instead we’re “bit banging” it — just toggling the pin HIGH and LOW ourselves with precise microsecond delays, in a loop, which turns out to work great and means we can use basically any digital pin, not just the “official” PWM ones.

The web page

We didn’t want to have to plug a laptop into the robot every time we wanted it to move, so the STM32 side exposes two functions — set_wheel1(speed) and set_wheel2(speed) — over the UNO Q’s built-in bridge, and the Linux side runs a little Flask web page with a slider for each wheel. Drag a slider up, that wheel spins forward; drag it down, it goes backward; let go, and it springs back to the middle and stops — like a throttle stick, not a light switch. There’s also one big STOP ALL button because, well, it’s a robot with wheels and you should always have a big red button.

We also added a small safety net that I’m pretty proud of: if the web page loses its connection (phone goes to sleep, wifi drops, whatever) and no command has arrived for a full second, the STM32 stops both wheels on its own. So the worst case if my browser tab crashes isn’t “robot drives itself off the desk,” it’s just “robot stops.”

The mystery clicking noise

Here’s the annoying bit. With both sliders sitting dead center at “stop,” the wheels are supposed to just… sit there. Instead we’re getting a faint little clicking sound, like the servo is “self-correcting” even though nothing is telling it to move. Turns out this is a pretty well-known thing with continuous-rotation servos: because they’re built from a normal position-holding servo, there’s still a tiny bit of the original control circuit inside trying to hold a “center” position. If our 1500us stop signal doesn’t land exactly on the point the servo was trimmed to when its feedback pot got disconnected, it thinks it’s very slightly off target and keeps nudging the motor to correct — click, click, click.

The fix isn’t code so much as calibration — most of these servos have a tiny trim potentiometer on the back for exactly this. But since we’d rather tune it in software than hunt for a jeweler’s screwdriver every time, next step is adding a per-servo trim offset so we can dial each one in separately without touching the hardware:

#define SERVO1_TRIM_US  0    // tweak until wheel 1 is silent at speed=0
#define SERVO2_TRIM_US  0    // tweak until wheel 2 is silent at speed=0

static unsigned int speedToPulseUs(int speed, int trimUs) {
    speed = constrain(speed, -100, 100);
    return (unsigned int)(PULSE_STOP + trimUs
                           - speed * ((PULSE_STOP - PULSE_FWD) / 100));
}

A few microseconds either way should be enough to quiet it down completely.

What’s next

Right now the robot can be driven around from a phone or laptop on the same network, which already feels like magic. Next up, roughly in order:

• Camera + remote driving — stick a camera on it and add WASD/on-screen controls to the web page, so it’s basically a little puppy on a leash you can drive from anywhere.
• Simple autonomy — a strip of tape down the hallway and some basic light-sensor logic so it can follow the line by itself.
• Manual override — a mode switch so it can drive itself but I can grab the wheel (well, the sliders) whenever I want.
• Telemetry / a face — battery level, current mode, maybe even a little animated face on an OLED screen so it has some personality.

Long term, the goal is a robot that can scoot around the house on its own and do small useful things — not just drive in a straight line, but actually be handed simple tasks. One step at a time though. Wheels first!

The codes

• https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)