After connecting to the rover via ssh or physically, run the command MAVRIC-Start and follow the instructions for picking a GitHub branch and launch file. This new branch and launch file will be what the rover automatically starts on power up until this command is run again.

In order to manually run a launch file, first stop the systemd service mavric-launch and run roslaunch mavric <launch file>. Keep in mind if a launch file isn't working like you expect make sure you are on the correct git branch and have pulled the most recent code base.

The Ubuntu distro that we use uses systemd as the systemctl module, so our startup scripts have to fit within that. Systemd allows a user to create services for anything that needs to be loaded at startup. It is not strictly necessary to use roslaunch, but it is more maintainable. Roslaunch is a tool that lets you lay out the structure of your application/submodules giving clarity to how things are connecting. It allows for simple remapping of topics, which lets us use things like a generic PID controller without creating our own modules specifically for it. Additionally, there is a hierarchical nature to the launch files, you can specify groups of nodes to go into a namespace, which isolates them from other nodes/topics with the same names. This means that we could have a launch file that spins up nodes that tell us lots of status information (system temperature, CPU load, whatever else) and then deploy that launch file (using the <include> tag) in a new namespace for each board. Diagnostics can then decide which one to look at at runtime. The savings here is that we only have to design the nodes/launch file once for the whole unit, then just reapply it in different namespaces.

Roslaunch can also access ROS utilities such as rostopic by invoking them as a node: bash: rostopic pub /SystemCooling/DesiredTemperature std_msgs/Float64 45 -1 roslaunch: <node name="..." pkg="rostopic" type="rostopic" args="pub /SystemCooling/DesiredTemperature std_msgs/Float64 45 -1"

Finally, roslaunch will also restart nodes that crash. This is important for things like a server that can have errors caused by external circumstances (if the user sends bad data). While it is possible to catch all posible errors and recover, it is also easy to miss something. this behavior can be specified by putting the respawn="true" attribute in a <node> tag.