search

BluEye-Robotics / ProtocolDefinitions

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

Protocol revision #3

Closed jandren closed 3 years ago

jandren commented 5 years ago

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 commented 5 years ago

@jandren

which frequency do you think here?

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 commented 5 years ago

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 commented 5 years ago

Other things I wish we could improve:

jandren commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

Battery lifetimes + additional status registers for improved support on debugging

jandren commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

jandren commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

johannesschrimpf commented 3 years ago

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