Getting the truck following the line again
Robo Bump Truck — Log 4. The driving comparison was recorded on October 2, 2026.
Watch the companion video on YouTube · Previous: kitchen laps · All robotics posts
Why there is a blue line in my kitchen
I am building a truck that can follow a trail. The blue-tape track in my kitchen gives me corners I can repeat. I can drive the same section, change the setup and see whether the next run follows it better.
On October 2, the truck leaves that line and hits the cabinet. That is the problem in the opening clip. The camera view moves into the wood and stays there.
I was frustrated because this had worked before. I tried restoring what I thought were the exact recorded controller, camera and frame settings, but I could not reproduce the earlier behavior. I believe I eventually got near the previous configuration; I have not verified that every setting matched. That failed restoration is part of the story, rather than proof that the hardware or model alone had changed.
It was a setback after earlier progress. In September, a path I had taught by driving it by hand, combined with camera correction, had helped the truck lap the kitchen in both directions. That earlier result was assisted and assessed from phone pose. That earlier progress made another failed corner frustrating.
“Teach and repeat” here means I manually drove a reference route, recorded that path, and used it together with camera correction on later laps. It is separate from training the vision head offline. That head learned from camera images and labels projected using recorded pose: a small trained head on a frozen DINOv2 backbone, as described in Log 3. It did not retrain live. The selected October 2 clip does not establish whether the reference path was active in that run.
Three changes meant to improve it
After the attempted restoration, I re-seated the camera, reduced the native stream from 30 to 15 frames per second and used a different model head. I made those changes together, hoping the truck would follow the line better.
| Recorded condition | Failed run | Later run |
|---|---|---|
| Camera pitch | Approximately 11° | Approximately 21° |
| Native stream setting | 30fps | 15fps |
| Model head | OVAL4+faa865a0c6 | OVAL4 |
The heads' logged hash prefixes are 8d0322650991 and cc2ca195ad16. The camera measurements and stream figures are historical recorded conditions, not a new calibration. The saved source videos are 15 fps; the video output is 30 fps by frame duplication. Those rates describe different stages.
Changing three things together gives me a comparison with an important limit: I cannot give one change all the credit. It still lets me see whether the later recorded behavior is more useful.
Camera angle changes how the tape appears in the image. Stream rate can affect how much work the receiving pipeline has to handle. The existing comparison report also found queued images and older pictures under some conditions. These were useful reasons to inspect the setup, rather than keep turning knobs without comparing the result. Coding agents helped put those conditions and logs next to each other. The failed and later clips have several differences, so this video cannot isolate a queue, pitch or model effect.
The later stretch is a success
Later that night, the selected footage follows the blue line through the corners more successfully. Wandering remains visible, but useful line-following is back. That counts as progress.
The video keeps a continuous 60-second stretch at normal speed. “Later successful stretch” describes the improvement shown. It is not the name of an autonomous recovery feature, a count of complete laps or a claim that the truck is now reliable everywhere.
The steering readout gives context while I watch those turns. CAMERA STEERING REQUEST, with FROM CAMERA PERCEPTION underneath, shows the calculated curvature request after gain, clamp and smoothing, including a possible held value. It precedes the separate asynchronous sender snapshot. A HELD label means a previous request may remain; a readout gap means the frame-to-record association was not qualified. The bar is not measured wheel angle or confirmed FC acceptance. Image-to-log age describes one processing stage.
The useful comparison is clear: the earlier run went off the line into the cabinet; the later stretch follows corners more usefully.
Now make the comparison better
The next question is which changes mattered. I want to compare them systematically, keeping the other conditions fixed and preserving the failed attempts alongside successful runs.
The kitchen track gives me a repeatable place to do that. The improvement shown here is a useful starting point for the next comparison. The next chapter, “From kitchen corners to real trails,” turns to a separate October 18 Ruby Hill daylight passage.
Sources and limits
- Picture and human observation: the comparison uses failed run 225538 and later run 233546. I reported the cabinet hit, and the on-truck sequence is consistent with it. The exact contact point is hidden, so the footage does not establish impact force or a mechanical cause.
- Control and interventions: the retained readouts show jointly checked logged assist/override/throttle states. Those software states do not independently certify uninterrupted autonomy, no takeovers, actual wheel position or FC acceptance. This is a bounded selected stretch.
- Unresolved evidence: an earlier review reported gate activity, held commands and false-positive points, but that account has not been independently rechecked. These clips therefore cannot rule out perception errors, establish a single cause or confirm that the mechanical setup was sound. Other reported checks—a native 30 fps A/B comparison, mount movement and a hand-lock test—lack matching retained footage.
- Outside view: the narrow check found no qualified synchronized overhead/side match for these exact October 2 clips in the known sources. The September 13 overhead and September 12 truck/phone photo now shown are dated setup references, not matching run evidence. No synchronized outside view was found among the sources checked.
- Crop and reference pictures: the displayed camera view uses this crop: x80/y288, 576 × 432 from the original 960 × 720 viewport, enlarged uniformly by 5/3 to 960 × 720. The full-size displayed viewport and right telemetry panel are retained. Two dated reference stills remain on the left throughout 6–17 seconds and 32–92 seconds. In the sampled 38-second bend, the upper picture hides a short left portion of tape; at 13 seconds the panels cover part of the cabinet surface. Readouts still refer to the original camera image. Originals and previous versions are preserved.
Watch and keep exploring
Watch Log 4 on YouTube · Previous: kitchen laps · Start with Log 1 · Trail-driving story: Log 2 · Build guide · All robotics posts
Next: a separate October 18 Ruby Hill trail passage, with the recorded inputs beside the video. The brief glimpse at the end introduces that next chapter; the full replay will accompany its post.