search

BluEye-Robotics / ProtocolDefinitions

Collection of protocol definitions for the Blueye underwater drones
GNU Lesser General Public License v3.0
2 stars 3 forks source link

Reorganize protobufs #19

Closed erlenner closed 3 years ago

erlenner commented 3 years ago

Protobuf messages are organized into the following files: message_formats, for defining the data format of payloads. req_rep, for defining request / reply messages like GetOverlayParametersReq. control, for messages published from client to drone like AttitudeCtrl. And telemetry, for messages published from drone to client like DepthTel.

The main points of this organization is to separate the fine grained data description in message_formats from the more broad stroked protocol description in the other files, as well as to separate the different protocol patterns from each other.

Some of the high level messages, like DepthTel, use a very simple message format, so in those cases we could consider removing the message_format entry and just put an integer directly in the DepthTel message. On the other hand, if we keep the message_format entry, then we can just extend that if we at some point need to add more fields, allowing us to keep the DepthTel message short and high level.

erlenner commented 3 years ago

I've also left the StartRecordCtrl message empty, instead of adding an empty StartRecord message in message_formats. But here it wouldn't be a problem to add a message in message_formats at a later stage, so it doesn't matter that much.

erlenner commented 3 years ago

Should we extend this to both data and video partition? I think it's nice to have both partitions represented here rather then two messages. This way, we can easy extend it to more partitions later.

@johannesschrimpf Sounds good. However, in cases like this adding more information to one message means that we will need to consider an extra failure scenario. That is for instance the scenario when we manage to get the storage space for the data partition. but not the video partition. Should we avoid sending the message in those cases? Or should we send it, but have a valid flag for each partition?

erlenner commented 3 years ago

On second thought, I think the added complexity of a valid flag etc. means it will be simpler to add a message. Remember that with the new protocol, adding a new message is very simple.