Preparing for the first teleoperated drive
Working through the list of things that have to be true before the rover moves under command for the first time. Power is on and behaving, compute is mounted, and the drivetrain is waiting on replacement mounts. The remaining work is the control link: a transmitter and receiver bound, a failsafe that triggers on link loss, and a stop that does not route through the autonomy computer. We are writing the pre-run checklist before the drive rather than after it, on the theory that the first run is exactly when a checklist is worth having.
What we learned
- Writing the pre-run checklist forced three unanswered questions into the open — none of which were about software.
- A first drive is a test of the stop path, not of the drivetrain. If the platform cannot be stopped predictably, nothing about how well it moves matters.
- Sequencing the drive behind the mount replacement was uncomfortable but correct; driving on a bracket we know is cracking would only produce a second failure to diagnose.
Next steps
- Bind the transmitter and receiver, and confirm failsafe behaviour on deliberate link loss with the wheels off the ground.
- Install the revision-two motor mounts and re-check encoder alignment.
- Run the first teleoperated drive on a hard indoor surface before anything happens outdoors.
Hardware referenced
- ExpressLRS linkExpressLRS (open source)915 MHz, CRSF, low-latency
- WAVE ROVER 4WDWaveshare4WD skid-steer base, integrated ESP32 driver board
- Motor and encoder mounts (custom)Designed and printed in-housePrinted brackets, revision 2 in design
Open challenges touched
Radio configuration
The control link needs to arrive as a genuinely independent path — a transmitter, a receiver, a failsafe that triggers on link loss, and a stop that does not depend on the autonomy computer being healthy. Binding, protocol selection, and failsafe behaviour are all still open.
Motor mount replacement
The first-revision printed motor brackets cracked at the fastener bosses under drivetrain load. Because the same bracket locates the encoder against the motor shaft, a compliant mount corrupts odometry well before it fails visibly. Revision two thickens the bosses and moves to a stiffer material; it has not yet been printed or loaded.
Decisions referenced
Keep the control link and stop path independent of the autonomy computer
Manual control and the stop path terminate at the ESP32 driver board, independent of the Jetson, so the autonomy computer can fail without the platform losing control authority.
- The autonomy computer must be free to crash, reboot, or saturate without affecting the platform's ability to stop.
- A simple controller is independently testable and can be reasoned about in full.
- This boundary is expected to be reused unchanged on every later platform.
- Route control through the Jetson — Rejected — a single software fault becomes a safety fault.
- Software-only stop — Rejected — a stop that depends on working software is not a stop.
Images
Rover on blocks with the wheels clear, ready for link and failsafe testing.