Status update and check-in summary

Thank you all for taking the time over the past week to participate in check-ins! We hope we were able to answer any questions you had, and we very much appreciate the feedback given to us. I’ve listed below any questions that were asked during check-ins which may be of interest to other teams as well. Feel free to ask for further clarifications regarding any of the points.

  1. Vessel model: The vessel model used in the second software release is a simplified model implemented for this specific use-case. The model is limited by Unity which does not support mass and damping matrices, where (for example) the vessel damping is tuned with 2 parameters; linear and angular drag. The result of this is that the vessel (unrealistically) experiences equal drag in sway as it does in surge. To achieve realistic vessel dynamics, the control inputs have been tuned to match the mass and damping parameters. This was meant to be a temporary solution, as integrating OSP allows for the modelling of ‘proper’ vessel dynamics, however we are reluctant to change the underlying model at this stage as it would require teams to redo portions of their vessel controllers.*

  2. Lateral movement: The ability to apply a force directly in sway in the force controller is intended. Even though the 3D model in Gemini does not reflect this, we’ve chosen to give the Njord vessel actuators allowing for dynamic positioning to greatly simplify tasks such as autonomous docking. As such, controllers implemented by teams are free to use this capability.

  3. Origin of local coordinates: At the moment, the navigation message published in ROS includes the latitude and longitude coordinate as well as the heading. After discussing with a few teams, we believe that a better solution will be to publish the coordinates in Unity’s local euclidean coordinate system, and in addition publish a separate message with the latitude and longitude coordinates of the local coordinate system’s origin. This will allow teams to use both coordinate systems as they wish. An update to reflect these changes is already being worked on.

  4. Communication of mission objective: Our software team is working on an expansion of the ROS nodes to publish a mission object message, which will include a scenario identifier (an integer corresponding to the type of scenario, e.g. docking) as well as a set of coordinates which the vessel must reach to successfully complete the scenario. This update will come simultaneously as the changes described in the previous point.

  5. Task and technical report details: More detailed descriptions for the individual tasks and the technical report are already in the works. They will be published to the Gitbook soon, with an accompanying forum post to notify teams

I hope this has helped clarify some of your concerns, and again, please do not hesitate to ask any further questions.

*This is a point where we are open to suggestions. If a significant number of teams would prefer to use the improved vessel dynamics from OSP, please let us know, and we’ll see if we can reprioritise.