Preserve the Factory Baseline Before Modifying It

Once the robot was assembled and reachable, the temptation was to immediately start replacing vendor software.

I decided not to.

The better first milestone is a known-good, recoverable baseline.

My rule became:

Understand and preserve the reference system before destroying the reference system.

That means checking the major hardware and software paths while the robot is still close to the factory configuration:

  • drive system
  • robotic arm
  • LiDAR
  • camera
  • display
  • Jetson
  • robot controller
  • networking
  • battery telemetry
  • ROS nodes and topics
  • packages and launch files
  • TF relationships

I started inspecting the ROS 2 environment directly with tools such as ros2 node list, ros2 topic list, and package/launch-file searches rather than simply running vendor demos.

One small but useful confirmation was battery telemetry. I observed /battery readings around 11.05 V before charging and about 12.30 V later after charging. That was an early example of physical state becoming software-visible state through ROS.

Backup before experimentation

After the component tests are complete, I want a full recoverable image of the Jetson storage—not only a copy of a workspace.

The goal is to preserve the original Linux, NVIDIA software, drivers, ROS environment, vendor packages, and system configuration so that later experiments can be reversed.

The intended cycle is simple:

known-good baseline
        ↓
full-system backup
        ↓
experiment
        ↓
break something
        ↓
understand why
        ↓
recover if necessary

This also supports the security goal I had before purchase. I can preserve the vendor reference environment while still moving gradually toward a system whose packages, services, and network behavior I understand.

Remote access is infrastructure too

SSH was usable, but I also encountered ownership/permission issues while improving the authentication setup. That was another reminder that robot engineering still includes ordinary platform engineering: Linux permissions, identity, networking, deployment, and recovery matter before autonomy becomes useful.