Learning ROS 2 by trying to simulate a submarine

The mental model was different

When I first opened a ROS 2 project, I kept trying to understand it like a normal application.

Where does the program start? Which file owns the state? What calls what?

That is not really the right mental model.

A robotics system is split across nodes that publish, subscribe, and communicate through messages. Once I stopped looking for one central application and started thinking about the graph of components, the structure made much more sense.

Simulation is not just a visual demo

Gazebo initially looked like the part where you get to see the robot move around.

The more useful way to think about it is as a development environment.

If the simulated vehicle, sensors, transforms, and software interfaces are close enough to the real system, the team can work on behaviour before everything is running on the physical AUV.

That makes simulation infrastructure part of the engineering workflow, not just something to show at a demo.

Robotics exposes every abstraction

Robotics also has a nice way of exposing assumptions.

Coordinate frames matter. Timing matters. Sensor data matters. A topic name being wrong can make an entire chain silently stop doing anything useful.

I am still early in this work, but it has already forced me to debug at a different level than I usually do in web software.

Why I wanted the project

Part of the reason I joined AUV Calgary was exactly because I did not already know this stack.

I wanted to work on software where I could not fall back on the same tools I already knew.

ROS 2, Gazebo, Linux, and robotics software have definitely done that. I still have a lot to learn, but feeling slightly lost has been useful. It means the project is doing what I wanted it to do.