ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Common message structure for USV navigation

Hi, I am Masaya Kataoka and I am a software developer of OUXT Polaris.
I am developing fully autonomous sufrface/underwater vehicle for maritime and virtual RobotX Challenge.
Our software is fully open-source and anyone can use it.
In order to make a lot of useful ROS packages for UUV navigation, I want to make common message structure for USV navigation.

In my opinion, message structure for UUV navigation should be a little different from grounded robots.
I think there is no accurate navigation when the UUV sail on the sea.
But, when we try docking task autonomously, we have to navigate them very precisely.
In order to realize this feature, I want to add pose tolerance field to the waypoint message field.

From this point of view, I designed uav_navigation_msgs like below.


Header header
uint32 waypoint_id
geometry_msgs/PoseStamped pose
geometry_msgs/Vector3 position_torelance
geometry_msgs/Vector3 orientation_torelance

uav_navigation_msgs/Waypoint describes single target pose of the USV.


Header header
uav_navigation_msgs/Waypoint[] waypoints

uav_navigation_msgs/Path is a array of waypoints.
It describes single series of waypoints.

1 Like

I want to build usv navigation system like below.

Hi Masaya,

Are you aware of the auv msgs package?

Maybe it will work for you, or if you have any suggestions you are welcome to discuss different possibilities.

@Icarlucho Great!!
I did not aware of auv_msgs.
However, I am now designing unmanned surface vehicle, not underwater vehicle.

I am also developing unmanned underwater vehicle, so when I design auv navigation system, I will conrtibute auv_msgs.

I found that the USV cannot control altitude and pitch/roll angle
So, it is unnecessary to set torelance in Vector3 format.

So, I designed usv navigation msg like this.

In general I recommend using the full dimensional generic messages even if your current vehicle does not have the capability to execute it a future evolution of that vehicle might be able to achieve the goals.

We do the same thing with ground vehicles and send a full 3D pose. Most cannot achieve any vertical change, so they ignore anything out of the plane when controlling and do their best to achieve the goals ignoring the z elements. However, when interacting with other elements that do support 3D motion such as grippers or a robot with a telescoping torso it is useful information. If you define different datatypes for each subcategory of mobility types you will end up with a lot of duplicated code and libraries will be locked into one vehicle type when that’s usually not necessary.