[TASK] Expand joystick interface to have a mode that publishes a guidance reference message

[Andeshog]

Description of task

Right now the joystick interface publishes a wrench message. In practice, if there are strong currents in the ocean it is more difficult for a human operator to control the drone. To ensure better control, a mode that publishes a reference signal instead of a control input should be implemented. Unnecessary/repetetive logging should also be removed.

Suggested Workflow

• Get familiar with how the current joystick interface works by testing it out in the simulator.
• Get familiar with the NED coordinate system and the 6 degrees of freedom for an underwater vehicle.
• Write the code and test it by plotting all degrees of freedom in plotjuggler or foxglove.

Specifications

• Use PoseStamped as the message type for the reference signal.
• Use "joystick/guidance" as the topic name.
• The start position of the reference should be the current pose of the drone.

Contacts

• @Andeshog

Code Quality

• Every function in header files are documented (inputs/returns/exceptions)
• The project has automated tests that cover MOST of the functions and branches in functions (pytest/gtest)
• The code is documented on the wiki (provide link)

[chrstrom]

@Andeshog you might want to consider using a geometry_msgs::msg::PoseStamped for this (or some other well-suited standard message with a header). With a generic array you require the "user" to both know what index corresponds to which state and to correctly parse it. A Pose message will make that explicit (plus you can use all the tf2/Eigen conversion functions), and having the timestamp field populated is always a good idea (you will thank yourself later for timestamping your messages). Having the header also means you get to explicitly define the frame your data is in.

Note that nested messages are a bit EVIL in terms of performance (especially for serialization/deserialization), but that's honestly not a concern with such little data being sent.

[Andeshog]

@Andeshog you might want to consider using a geometry_msgs::msg::PoseStamped for this (or some other well-suited standard message with a header). With a generic array you require the "user" to both know what index corresponds to which state and to correctly parse it. A Pose message will make that explicit (plus you can use all the tf2/Eigen conversion functions), and having the timestamp field populated is always a good idea (you will thank yourself later for timestamping your messages). Having the header also means you get to explicitly define the frame your data is in.

Note that nested messages are a bit EVIL in terms of performance (especially for serialization/deserialization), but that's honestly not a concern with such little data being sent.

Yes, totally agree. Thanks for pointing out