It's equally important (for backward compatibility in the app) to version and identify these types, as the app needs to know the size and how to unpack the returned from the drone.
I sugges we follow the same scheme as we do for the UDP, with a protocol version, and a message type as the two first bytes. As none of the existing messages has these two fields, we can consider the existing messages v1 (even if our protocol is currently at v2), and then simply version all the existing messages as v2.
As the existing messages do not have version or type info, I will use a feature toggle in the app and use the version number of the drone to determine which data format to expect in this concrete instance.
So far the protocol definition file only includes packages published over UDP. In addition, we have data types passed between app and drone over the TCP connection. These are defined inline in the
node_telecommunication.cpp, like theAllCamParam: https://github.com/BluEye-Robotics/p2_drone/blob/dev/src/node_telecommunication/node_telecommunication.cpp#L160The types are:
It's equally important (for backward compatibility in the app) to version and identify these types, as the app needs to know the size and how to unpack the returned from the drone.
I sugges we follow the same scheme as we do for the UDP, with a protocol version, and a message type as the two first bytes. As none of the existing messages has these two fields, we can consider the existing messages v1 (even if our protocol is currently at v2), and then simply version all the existing messages as v2.
This issue is relevant now, as we are extending the
AllCamParamDatamessage with two fields, FPS and resolution. See https://github.com/BluEye-Robotics/p2_drone/pull/93As the existing messages do not have version or type info, I will use a feature toggle in the app and use the version number of the drone to determine which data format to expect in this concrete instance.