Feature: Basic Robot Simulator

[guilyx]

Purpose

There are a fair amount of untested packages, because we had no ways to simply emulate the movements of a robot. (i.e. docking_controller, relative_move...)

Approach

Here I developed a Node that listens to a velocity topic and broadcasts a projected global_frame to base_frame transform. It of cours abstracts all hardware issues and assumes the kinematic model is perfect.

[jcmonteiro]

How do you think this compares to running gzserver in the CI? Maybe we will have use cases for both?

[guilyx]

This is fine for unit testing methods, gzserver is suited for things that require running the stack imo
Ex: gzserver is good if you need to run a test that needs a map and proper instantiation of the whole stack, this is good for testing minimal things like "when I request rotating 90 degrees, are the commands received actually going to get me to 90 degrees"

[guilyx]

@SomaGallai fyi the last commit broke the CI but it's still building locally

[jcmonteiro]

I would approve if not for the #include syntax. It is a detail, but we should keep it consistent so that others copy the correct syntax when using this code as reference.

[SomaGallai]

When this gets merged, can you create a new tag please. https://github.com/cmrobotics/odom_tf_publisher/pull/1 is failing due to tests_utils not being up-to-date.

[jcmonteiro]

The PR is looking really good! I just made some small comments to help improve it a little bit, but you could even see them as optional.

To document what we briefly talked about, I would favor passing ros::Time and ros::Duration objects or plain std::chrono whenever time variables are used. This is to prevent a developer messing up the function call. For example, thinking the function receives a uint64_t value in milliseconds when it actually is a double value in seconds.