LESSON 16 · HARDWARE

Bring a small robot to life carefully

Plan power and interfaces before connecting software to motion.

Environment and verification

Documented target: Ubuntu 24.04 · ROS 2 Jazzy · Gazebo Harmonic where used. Browser labs tested; ROS/Ubuntu/hardware execution not performed here.

What you will understand

  • Check manufacturer-backed compatibility.
  • Separate logic/motor power.
  • Plan staged commissioning.

Prerequisites: Plan a route and supervise a mission and its stated environment.

The idea, made clear.

Match supply voltage, current capacity, logic levels and connectors using manufacturer documentation. Example code does not prove compatibility with a different motor or battery. Part numbers and revisions belong in the project record.

The hardware project uses a documented Romi chassis and matching Romi 32U4 board. Integrated drivers reduce custom wiring, but battery chemistry, polarity, jumpers and routing still matter. A companion computer requires an appropriate supply; do not assume motor power can safely feed its GPIO.

Inspect unpowered wiring first, then logic communication, then brief low-power lifted-wheel tests. Provide a reachable motor-power disconnect before floor tests. This site supplies a reviewed learning plan, not a claim of physical assembly, certification or safety validation.

For the documented Romi combination, six AA NiMH cells provide 7.2 V nominal. The control-board limit is 10.8 V, not a suggested supply setting. USB can keep logic powered with the motor switch off. Disconnect both sources for wiring and use a chemistry-matched charger; never assume the board charges installed cells.

Power reviewUnpowered wiringLifted wheelsCommissioning
An original overview of the information or commissioning sequence.

Try it, step by step.

1

Review exact parts

Read the hardware project and current manual.

Expected: Part numbers, revisions and voltage/current evidence.

2

Trace power while disconnected

Identify battery holder, board input, switch and motor outputs.

Expected: A diagram matching the manufacturer circuit.

3

Define communication

Design example only, not supplied firmware.

hardware-integration-3.txt
command: {left_rad_s: 0.0, right_rad_s: 0.0}
feedback: {left_ticks: 0, right_ticks: 0}
policy: stop if commands expire

Expected: Units, limits, neutral startup and a timeout policy.

Explore the interactive lab →

If something goes wrong

Resets when motors start
Investigate supply sag and load with power safely removed.
Moves on startup
Require neutral outputs and explicit enable; test lifted wheels.

Check your understanding

When commands expire, what should happen?

Make it yours

Create a reviewed commissioning checklist with disconnect and pass/fail criteria.

Your learning progress

Optional progress stays in this browser. No account needed.

Go to the source documentation

Commands are educational examples for the stated environment, not a transcript of local ROS execution. Verify actual behavior on your machine.

Look up a term · Version notes · Report an issue