Protocol revision

[jandren]

Just collect ideas for future protocol update

Would be good to have in the logs: Type of device used, pilot and buddies Calibrated gyro Calibrated acc Thrust setpoint Dropped frames? CPU usage RAM usage

[johannesschrimpf]

@jandren

• CPU usage
• RAM usage

which frequency do you think here?

• Type of device used

You mean mobile phone/tablet? This would needed to be registered then from the top side and a string is quite a few bytes data in each line in the log file. Also dropped frames is data that I assume is living in the mobile phone, not the drone.

[follesoe]

We could consider a secondary log file or a header section in the file for non-repeating elements as there are certain data that does not change but would be nice to have logged. Alternatively, they could still be rows in the file, but at a different rate. I.e. the log file is still just a record of the binary data sent over UDP, but we can allow multiple message types at different rates.

[follesoe]

Other things I wish we could improve:

• Connection flow which takes multiple clients into account somehow (todays behavior of the app being kicked out but not being able to tell why, and then trying to reconned, is not a good user experience).
• Number of connected clients on the RTSP stream

[jandren]

@johannesschrimpf For CPU/RAM, I say at what ever rate that is suitable to pull it without affecting performance. 1/min? We will just have to test.

For device used, dropped frames and other app related logging. I think it would be very nice to have this kind of data synchronized with the dive for better debugging. Our logging solution as of now is to store the TCP flow so thats why I put that data here. Not that the drone has it but that we want to have it on the server after the log files are synced.

[aksell]

After talking with Jacob and Sindre it became clear that the only the first argument in the lights command is used on the drone (lights_upper, lights lower). So we should remove and rename the parameters for the light command.

[follesoe]

SDK can remove it but protocol can’t change - but we can change it in v3. The app use a feature toggle to match the behavior, old drones use both values, current version don’t (but both expect to values in protocol).

[borjaserra]

Battery lifetimes + additional status registers for improved support on debugging

[jandren]

More from @borjaserra The battery it also logs when it has failures and how many. If there was a Under Temperature Charging failure it would state which cycle and how many times it happened. It is information that is not logged and it is useful for debugging customer battery issues from the office and decide if they need to send it back. Status registers can also show if there is a permanent failure and if the chemical fuses have been blown up to protect the battery and/or the system

Some might not need 10 Hz logging but rather a once per boot check and save.

[jandren]

Add unit_lat, unit_lon for georeferenced position using waterlinked or similar device. Should be same as user_lat/lon, i.e. phone GPS when no underwater positioning system is available. Could be used for EXIF, videologs for photogrammetry, dashware, subtitles etc. Adding support for waterlinked and co would then just be to start publishing on this topic.

[jandren]

control_yaw, ie log yaw (heading) with and without magnetic compass. Would be useful for photogrammetry in magnetic disturbed areas (pretty normal case...)

[jandren]

Add final line telling us if shutdown was intentional or not. I.e. Fault or loss of battery will not end with some specific information Correct shutdown will write one final line or just set some bit somewhere that later can be appended to the log files.

(Sitting with a support case where the customer claims that it shut down while diving but it just seems to be loss of connection to the app, logging this information would help a lot in debugging)

[jandren]

add /hmi/watchdog or similar connection metric an improvement would be if we could tell if it is an intentional end dive or loss. Simplifies the process of seeing stability of link and helps in debugging. Consider having ping times as well as realtime link metric (now that iperf only runs when video streams are connected).

[jandren]

Lost connection, time and why its raised. Probably also log the watchdog message that counts up (would show app connection)

[johannesschrimpf]

Followed up in https://github.com/BluEye-Robotics/ProtocolDefinitions/pull/14