[Draft] ROS Proposal

Owned by Aaditya Chaudhary
Last updated: 2022-11-15
2 min read

Pros

  • Streamlines communication between high level zp components by using topics and well defined Messages.

  • Allows us to easily see what data is being sent between nodes as anyone can watch a topic

  • Rosbag recording is OP for identifying problems and they allow us to very easily reproduce problems to see how the system behaves (makes it insanely easy to recreate the sensor input and conditions that lead to a crash)

  • Makes fw/cv a lot closer, while still keeping some levels of separation between them, as nodes can be written in c++ or python, (and other languages, but I think you need third party libraries to build them), but still use the same ROS messages to communicate.

  • makes the high level components easier to develop for, as you dont need the dev board, you can build and test on your computer

  • makes the high level components easier to test, as they can be tested without the zp board.

  • simulation is a lot easier, ros integrates well with flatland for 2d sims and gazebo for 3d sims

  • ros can be run from docker

  • ROS is very common in robotics industry, so its a useful skill to learn

  • ROS has a lot of built in tools, for testing, plotting, visualizing etc. Think FRC tools like smart dashboard, on steroids

  • we can properly use git sub modules, as each node doesnt really depend on the other nodes, as long as they have the message definitions available. Some people hate git submodules, some like them, so idk if this is a pro or a con, but I think its “better practice” for git so its a pro for now.

Cons

  • We would need to separate the high level and low level components

    • This is kind of already happening though, with the creation of LOS. Which is why I think its the perfect time to move to ROS (or next comp, but this year)

  • porting it all to ROS

    • only have to port over high level components

    • High level components are already in cpp, so really we just need to take the code and paste them into ros packages, write some launch files, and figure out what topics we want. It’s more discussion and planning rather than coding to be honest.

    • We would need to write a relay node to convert ros topic data to UART or I2C and send to zp board.

  • need to change our zp - jetson comms (but I think we’d need to change them anyway so Its fine.

    • I think we could use the compiled ros messages for the fw, I’ve seen it work

Nodes

  • /path_manager

    • Subscribes To:

      • /Telem/GroundSideComms/Waypoints

    • Publishes To:

      • /PathManager/AttitudeCommands

  • AM

  • telemetry_manager

    • /GroundSideComms

    • /LosRelay

      • subscribes to:

        •  

      • publishes to:

        • /Telem/LOSRelay/Odometry

  • System Manager

  • CV nodes

  • Nodes for interfacing with cameras, sensors attached to jetson

Links