A complete guide to streaming real-time sensor data from your FTC robot over UDP, storing it in a SQLite database, and querying it to find problems your eyes can't see.
The ability to instrument a system, capture data during operation, and query it intelligently is one of the most valuable skills in professional engineering. You are not just debugging a robot. You are learning how the world's most critical systems are understood and improved.
Rockets stream thousands of sensor readings per second during flight. Every SpaceX anomaly investigation, every Mars rover debugging session, every Columbia inquiry — all rely on the same pattern: structured telemetry capture, timestamped records, and systematic querying.
Implantable devices, surgical robots, and proton therapy systems log operational data continuously. In cancer treatment, beam targeting systems rely on real-time monitoring to deliver the right dose to the right location — a system that cannot be observed cannot be trusted.
Every self-driving car generates terabytes of sensor data per hour. Finding the specific 200-millisecond window where the system failed — and understanding why — is only possible with the habit of mind you develop here: log everything, query intelligently.
Tactical robots, autonomous vehicles, and sensor platforms operate in conditions that cannot be fully reproduced in a lab. High G-forces, jamming environments, extreme temperatures — the data stream is the only window into what actually happened.
Autonomous submarines and remotely operated vehicles cannot be observed directly during a mission. Post-mission data analysis is the primary debugging tool. Dynamics that look predictable in simulation behave completely differently underwater — and only the data reveals why.
The pattern is universal: instrument the system, capture data continuously, store it efficiently, query it intelligently. Engineers who master this skill see problems differently than their peers. They find failures before they become catastrophic. They validate changes instead of assuming them.
Four components. One direction. The robot sends. The laptop receives, stores, and answers questions. No web servers. No build pipelines. No infrastructure to maintain.
One call to .put() and one call to .send() per loop. The network stack handles the rest asynchronously. Your loop time is unaffected.
Two tables: packets and triples. Add any sensor, any predicate, without ever touching the database schema. The structure adapts to your robot.
Full SQL. Find outliers, compare runs, detect stalls, trace events across subsystems — all from the same database, across every run you have ever logged.
Filter on udp.port == 3000 to see every packet your robot sends. Instantly diagnose connection problems before blaming the code.
Teams encounter these exact situations every season. In each case, the robot appears to work fine in practice — and then fails at competition. Telemetry data is what separates a team that guesses from a team that knows.
You drive straight in your gym. At competition, on a different floor surface, it curves left. The code is identical. The wiring checks out. You have two matches left.
Both motors receive the same command — but one wheel has a slightly different tire contact patch on the new floor. The robot curves.
Autonomous runs flawlessly for 8 seconds — then the robot freezes mid-field for 3 seconds and drives into the wall.
Another robot drove between yours and the April tag, blocking the camera. Your code waited for a detection that never came and had no fallback.
Works perfectly in your workshop — a hundred times, never misses. At the competition venue, it misfires constantly. The hardware is fine.
Your workshop has cool fluorescent lighting. The competition venue has warm LED panels at a different intensity. Your threshold was tuned to the wrong building.
The intake sensor fires, the gate opens 50ms later. Sometimes the ball makes it, sometimes not. Intermittent and invisible. The software timing looks fine.
Physics: the ball is still decelerating through the mechanism. It arrives at the gate somewhere between 80 and 240ms after the sensor fires.
Arm mechanism works with practice game elements. At competition with the official (slightly heavier) elements, the arm stalls partway through its travel. The robot times out.
The stall signature: power output climbs toward maximum while encoder position stops changing. Visible in data. Invisible to the naked eye.
The driver pushes forward and the robot goes sideways. Pushes right, it goes backward. From the driver station it looks possessed. It worked perfectly in practice.
A hard collision shifted the IMU heading 45 degrees. Every drive command is now rotated by 45 degrees in the wrong direction.
SQL queries pull data from the triplestore and paste directly into LibreOffice Calc. These are examples of what you can see — rendered from real sample telemetry values.
A pile of triples looks like nothing. A well-written SQL query reaches into that pile and surfaces patterns that were invisible. These are three of fifteen queries in the full guide.
| id | power | encoder_pos | encoder_delta |
|---|---|---|---|
| 45 | 0.62 | 1840 | +42 |
| 46 | 0.74 | 1871 | +31 |
| 47 | 0.95 | 1874 | +3 |
| 48 | 1.00 | 1875 | +1 |
| 49 | 1.00 | 1875 | 0 |
| tag | samples | avg_reading | min | max |
|---|---|---|---|---|
| workshop_tuesday | 240 | 418.3 | 390 | 451 |
| comp_practice | 180 | 681.7 | 645 | 714 |
| comp_match_1 | 80 | 679.2 | 650 | 710 |
| id | subject | predicate | object |
|---|---|---|---|
| 153 | camera | targets_detected | 0 |
| 153 | imu | heading | +12.1 jump |
| 153 | left_motor | velocity | -0.8 drop |
| 158 | arm_motor | encoder_delta | 0 (stall) |
| 165 | camera | targets_detected | 1 |
Clone the repository, run the listener, instrument your robot, and start asking questions. The whole stack runs on a $35 Raspberry Pi if you want to log automatically at competition.
Get telelog.py and the UdpTelemetry Java class from the Nexus Workshops git server.
Connect your laptop to the Control Hub WiFi. Start telelog.py before your op mode. Tag every session.
Add four lines of Java: create UdpTelemetry, call .put() for each signal, call .send() at the end of each loop.
Run a query, paste into LibreOffice Calc, chart it. Every session you have ever logged is in the database.
The complete field guide goes deep on every concept covered on this site -- IP networking, UDP frames, Wireshark, the triplestore schema, all fifteen SQL queries, six engineering problem walkthroughs, and LibreOffice Calc graphing with sample charts. Written for FTC students planning careers in engineering.
A 14-section technical manual covering everything from "what is an IP address" through multi-system event reconstruction with SQL window functions. Designed for FTC students who want to understand their robot at a professional engineering level -- and carry those skills into their careers.
This guide is part of the Nexus Workshops educational program — a collection of hands-on technical workshops designed for students who want to do real engineering, not just follow instructions.
The skills in this guide — networking, database design, SQL, systems thinking — are not FTC skills. They are engineering skills. The robot is the project. The discipline you build is the career.
Take your time with this material. Return to it as your experience grows. The engineers who become exceptional at data-driven debugging are the ones who stayed curious long after they got the basic system working.