ROS Architecture
sciencebot was built using ROS2, which operates on a principle of decentralized nodes. Each node has a specific responsibility, and knows and acts only on its very limited domain. Information is shared through topics, which nodes can publish to (send data) or subscribe to (recieve data). Actions are useful in carrying out higher order goals, and provide feedback during execution.
The ROS2 Tutorials are a good place to better understand ROS2 concepts.
We begin on the left, whereby our sensor information from the imu and the dwm are collected by their respective nodes. The information is published to a heading and xy topic, which the pose_fusion node collects, and republishes to a topic named "pose." Currently, this is merely a packaging of the prior information into one topic, but one could envision in a more advanced implementation that the pose_fusion could combine the individual sensor inputs to create more accurate or more probable localization information, perhaps using techniques such as Kalman Filtering or AMCL.
The pose information is read by the position_pid node (or whatever controller you desire to use). This is where the calculations are performed to determine movement goals. The controller will only act when it is servicing an action, which is prompted by a client. This action can be seen in the large rectangular box labeled 'move_to'. The client must provide the goal destination. The controller serves the action, providing position feedback during execution, as well as report of final state upon action completion.
Moving further right, a mux node decides which commands to accept and pass along to the motors. In this diagram, key_vel comes from manual keyboard commands (which have highest priority), and auto_vel have instructions originating from the aforementioned controller. One could add more sources of input here, along with more complex priority logic.
Finally, accepted commands are processed by the motor node, which translates movement instructions into motor commands that the micro-controller understands. If you happen to have a new drivetrain or different micro-controller, simply change only this node - the remaining architecture can remain intact.
Within some sciencebot implementations, this base architecture is condensed / abbreviated. For instance, for an autonomous run only mode, the mux middleman is unnecessary. When completing a goal that only requires turning to the correct heading (no X, Y location requirement) the dwm's xy information is not needed. As another example, some vehicle controller implementations directly calculate motor commands, rather than going through a velocity interface translation into motor commands. This means that the controller can serve as the last node, and all further nodes to the right are merely information passers that increase the spin up time of the system, as well as introducing slight delays.
Overall, the architecture is designed to be as modular as possible, and easily adaptable to different implementations.