20200805 Dev Meeting

Agenda

General:

• Update from relevant previous calls
• Tagged: issues, PR.

Notes

• Long discussion about transport protocol alternatives; this was somewhat unintentional, falling out of discussion about needs for reliable protocols, which in turn came out of reasons why we're doing a number of other changes (e.g. using parameters for LTE settings rather than specific messages).

  • Jonas - all the problems have been solved by other protocols
  • Lorenz - these have not been validated on the kinds of rubbish radio links we need to support . They need to be investigated but we need to see if we can work out iterative improvements now to do what is needed.
  • JamesP - agreed that whatever we do, key benefit of MAVLink is working on poor links so that still needs to work.
  • Lorenz - for now, Jonas/Julian look at solutions we can come up with for which lead to a good migration path if we do move to new transports etc.

• File-based protocols for params, missions, etc

  • Can we benefit from using BSON or other format and sending missions, params as a set in a more compact format.
  • Benefit of "files" is the ability to send a treeview rather than the flat structure that is easy to send with messages. So we can describe the high level definition of a mission and associated it directly with the Geofence and rally points. This also allows round tripping of surveys etc through vehicle - currently not possible.
  • PX4 already has BSON and looks like a good protocol for this: https://px4.github.io/Firmware-Doxygen/d1/de1/tinybson_8h_source.html
  • ArduPilot using a home cooked but similar protocol https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Filesystem/AP_Filesystem_Param.cpp
  • No firm conclusions - we're going to talk about it next week.

• Daniele asked about how we can resolve the parameter_ext. For now agreed we'll revert to trimmed messages. Julian has now proposed good solution for that.

Did not cover

• FYI Terrain protocol docs 259 went in.
• Hamish using with pymavlink with dialects
• mavgen.py: correct handling of includes (updated) #436 - progress?
• #1166 Add helper function for routing - Ollie Points
  • Incompatibility flags to indicate target address field presence (and remove from payload). - why/costs/benefits?
  • Can we separate out CRC somehow into valid message vs corrupt message?
• Julian Gimbal manager extension: add status of a tracked object #1418
• FTP protocol extension in ardupilot

  "To facilitate more efficient file transfer over commonly used SiK radios I have added an extension to the ftp burst protocol where the 'size' field in the burst read request sets the block size of the burst replies. This helps as SiK radios do badly with very large packets. I have found that the best results with SiK radios is achieved with a burst read size of 110. If the size field is set to zero then the default of the max size (239) is used."

  • Can we get more info on this, so we can formalise into the spec? Note the burst protocol not properly documented.

Attendees: HamishW, JulianO, JamesP, Lorenz, DanieleP, JonasV