Architecture
Robot Operating System or (ROS, in our case, ROS version 2 or ROS 2) is not an operating system in the traditional sense. It’s easier to think of ROS as a communication network; it’s a system that facilitates the transfer of information from one point (called a node) to another.
Package – A folder Node – Each piece of software that interacts with the ROS network, generally there is one per file. Topic – ROS’s variable, it has a type and can be accessed through the ROS network. Publisher – Sends data to a topic - Like a setter in programming terms Subscriber – Takes data from a topic - Like a getter in programming terms Client – Sends a request to a server over the ROS network Server – Acts on a request that a Client sends
FIgure 1 shows the logic flow for the 2022-2023 season. Expect something similar for the following years.
Starting with the GUI/User Interface, there are two different monitors likely hosted on two different laptops. The GUI functions as shown in subsystems. It talks over ROS to the rest of the system. The first laptop will contain pilot essential functions, such as controls, flight cameras, and task selection. The second has lightly undefined behavior at the moment but will likely contain logger, float, and showcase processes.
From there we have 3 main systems, the Surface Computer, the Pi and the Float
One of our goals of using ROS was to offload as much processing as possible from the Pi on the ROV. As such, the surface computer manages input, manages tasks, and handles much of the main control of systems.
To manage input, the surface computer publishes both keyboard and Puown menu which interfaces with the input manager as described in the subsystems documentation.
Other task stuff
- Tasks/selector
- can be auto or teleop
- realsense stuff will end up being a task
- teleop control is a task - 1 man control task
The surface computer will also run various control nodes as needed, doing as much of the ROS to hardware translation as possible to ensure the Pi doesn't g
The surface computer will also run various control nodes as needed, doing as much of the ROS to hardware translation as possible to ensure the Pi doesn't get overloaded.
The Pi contains mostly hardware interface things, working with the cameras, the Pixhawk and the Relays for I2C control of the manipulators.
The cameras will work similarly to the input control, where they talk directly to the GUI and any other tasks that listen to it over ROS topics.
The Pixhawk interface interfaces with the Pixhawk, taking something from ROS and making it into callable controls from the Pixhawk.
The Relay interface interfaces over the I/O board through I2C to the manipulators. This will be better explained later.
Float exists and kinda does its own thing, ask hardware or Eric if you need more info about the float. From a software perspective, it's a black box that we only touch through the Eric Yarnot.
passwd