Skip to content
Mehul Goel edited this page Nov 13, 2024 · 2 revisions

What is BuggyState ROS Msg?

Buggy state is our representation of the entire input state of the buggy. It should be the universal representation within our autonomous system and contains all the required data to perform autonomous steering.

The reason for a BuggyState is that we have a variety of input state representations, coming from Robobuggy Firmware, Short Circuit's UKF, or the INS, each of which have different units and coordinate systems. The BuggyState is going to be a special form of the nav_msgs/Odom topic, with how that is implemented explained below.

What is the BuggyState ROS Node?

After defining the ROS Msg that represents our buggy states, (published on channels self/state and other/state), we need to transform our raw_state topics to our clean_state topics. Take a look at the mermaid chart explaining our overall system architecture to understand which topics to subscribe to (self/raw_state and other/raw_state at time of writing) and write translators for this code.

Converting self/raw_state

self/raw_state will come in two different formats, depending on if you are on Short Circuit or NAND.

  1. Short Circuit's raw_state comes from the INS, and needs to be translated.
  2. NAND's raw state comes from the Robobuggy-Firmware's UKF output, and the packet structure should be detailed within the Serial wiki.

Converting other/raw_state

other/raw_state should only exist on SC, and is the representation of NAND's location after being sent over radio (or vision) and contains only two pieces of information that contain the position of NAND.

BuggyState Definition as a NAV/Odom ROS MSG

  • x (float64) - UTM Easting
  • y (float64) - UTM Northing
  • z (float64) - Heading (Radians) (0 is East - Fact Check before assuming!)
  • x (float64) - m/s of buggy speed in x direction
  • y (float64) - m/s of buggy speed in y direction
  • z (float64) - rad/s of heading change of rate