Skip to content

20210217 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Feb 18, 2021 · 12 revisions

Agenda

General:

Notes

  • First meeting using Jitsi!

  • Discussion: COMPONENT_INFORMATION extension #1588

    • A number of options discussed - info captured in this comment.
    • Taking discussion offline for moment to think about.

  • Component Info - should component information data files (not schema) be hosted on mavlink?

    • Discussion last week was that we prefer vehicles to host their component information, but if not, having a default hosted by mavlink would ensure there was a reliable fallback.
    • BeatK feels this is not a particularly big issue:
      • Vast majority of boards could carry this size info onboard without difficulty.
      • Majority do not customise the information we are sending anyway, so we could have PX4 and ArduPilot defaults that would cope for the remainder.
    • HamishW thinks that we are better off recommending than mandating things we can't enforce, and which if used will cost us unnecessary time and effort.
      • Suggests adding comments like "vendors should host component information files on the vehicle if possible. When information is not vehicle hosted, the files must be hosted on an Internet service that can reasonably be expected to outlive the vehicle. Github is recommended for this purpose"
    • If they are likely to ignore that then they are unlikely to use our git repo for the purpose. If they do read that then there is no reason they can't use their own git repo.
    • No final decision made, but nor are changes going to be made to docs until this is discussed further.

  • GPS_RTCM_DATA microservice is not documented - request for information;

    • BeatK knows all about this. Information provided :-)

  • Support for 2 airspeed sensors

    • Lots of discussion - but essentially airspeed can come from multiple sources (both sensors and by calculation), and handling can be by a fallback mechanism or some kind of fusion. We need to know what the message they actually need is, and why, in order to evaluate the request.
    • AO Hamish to add comments - Done here

  • Add MAV_VTOL_STATE_QC field #1569 - Robert (owner) attending.

    • Vehicle does not yet exist, this is pre-work.
    • QuadChute is basically turning on multicopter rotors to use as a parachute (in FW flight or transition). Would be used before failsafe parachute as a less severe reaction to failure conditions.
    • Answer from team is "depends on whether quadchute is a real discrete mode with specific handling, or it is just enabling MC mode". If the former then a new state is appropriate, if the later then simply forcing the MC transition is more appropriate.
    • Discussion is that they just need this to happen, so adding a force bit makes sense.
    • DONE :AO hamish to add this comment.

  • Add battery faults flags for wrong firmware and battery models #1577

    • Those present OK with this. AO hamish to do final review and merge..

  • MAV_COMPONENT IDs for Smart Battery #1589

    • Yes, for MAVLink completeness we need the two ids and also MAV_TYPE_BATTERY.
    • HamishW should document the use of MAV_TYPE etc.

Not covered from Agenda:

Attendees: HamishW, JulianO, Robert, Beat (apologies JamesP, Lorenz)

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