Skip to content

20220302 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Mar 3, 2022 · 10 revisions

Agenda

General:

Notes

  • camera/component information: URI zero termination

    • just merge. Minor risk. Significant benefit.

  • Component information protocol - move into standard #1806 - requirement for approval

    • Translations break the assumption of the existing general metadata that it can be static.
    • Some things might not be as static as you think - e.g. parameters and metadata that is dynamically created.
    • DONE AO: HamishW/Julian/James to articulate issues/points.

  • Add WATER_CURRENT and DVL messages #1804

    • SebH came along to let us know lots more suggestions coming.
    • Very welcome - ground/sea vehicle domain is "underrepresented".
    • Need to work through development.xml.

  • Rename and document parameter encoding protocol bits (Associated docs update)

    • Proposes MAV_PROTOCOL_CAPABILITY_PARAM_ENCODE_BYTEWISE, MAV_PROTOCOL_CAPABILITY_PARAM_ENCODE_C_CAST
    • Tridge suggested sending param values including encoding.
    • Following discussion, protocol bits address most cases, are "standard" and can be used now. They don't preclude adopting Tridge suggestion, which potentially allows a smoother path for adoption and works better for partial logs. They also reflect the intent of the bits.
    • Agree to merge PR and ask Tridge about possible RFC for his update.

  • FYI only Enums for FTP follow on

    • Community member added enums for opcodes as is less opaque than magic numbers for users (PeterBarker).
    • Still waiting on proper formatting etc.

  • Batteries with more cells - discussion about continued requests to extend message for more cells.

    • BATTERY_STATUS is too embedded to replace in any kind of short term, so this would have to be done with an extension or something that can live in parallel
    • Already extended once. We should not do so again in same way as it is not scalable.
    • JamesP. Most systems do not need or use this information, at least not all the time. What they really need is the battery voltage cumulative and the chemistry. If they do need this information they aren't actually interested in the voltage of every battery but more in the ones that are aberrant (i.e. as a fault condition) - so this could perhaps just be a bitmask indicating cells that broken (a much smaller extension). Or it might be a separate voltage message.
    • General agreement that we should discuss again. Also that we can't break BATTERY_STATUS in short term. Whether a new message or extension depends on the final information that is is agreed we need.

Follow ups

Not discused:

Attendees: JulianO, Hamish, JamesP, SebH

Add a custom footer
Add a custom sidebar
Clone this wiki locally