Skip to content

20221123 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Nov 23, 2022 · 13 revisions

General:

Notes

  • From Beat: Can we include all.xml in QGC?

  • Clarifying Euler angle axis order #1917

    • Correct thing to do is to add authoratitive link, but we've had trouble finding that in past in frame discussions.
    • This looks "no worse", and might help some people.
    • AO HamishW - merge.

  • Extend MAV_CMD_NAV_VTOL_TAKEOFF #1875

    • AO JamesP to clarify needs.
    • If no response before next meeting, AO on Roman to update new message as formal proposal for James to take to APM dev call.

  • Airspeed message: update #1900

    • AO JamesP to talk to Peter in person about this and resolve it.

  • component_information_basics: add serial number #1788

    • JulianO
      • idea is that you shouldn't have to do MAVFTP just to get basic component info.
      • no longer any pull for this from original customer.
      • Doesn't particularly like duplication
      • Not sure what rules should be for extending
      • Doesn't have strong opinions
    • HamishW
      • good to have basic info on components like this rather than forcing use of component information.
      • doesn't matter if it is big. It isn't streamed but is requested. If you don't get mavftp info, then you can choose to use this.
      • Extending OK for that reason.
    • AO Hamish to merge in development.

  • Proposal for fast yet simple and fully mavlink conform parameter upload #1918

    • ArduPilot very unlikely to do this.
      • Already have a solution that works for the case. Would have to keep the mavftp based solution, so this would be a cost in firmware, development, and additional maintenance.
      • Not seen as providing anything particularly "additional" that makes above cost worth it.
      • Adds "yet another interface" for people to target.
    • PX would more likely adopt ArduPilot solution (ThomasD - Auterion, JulianO - freelance/maintainer)
      • MAVFTP solid base of code that can easily be reused.
      • We might consider a more generic streaming protocol and base MAVFTP and parameters on it, but then we'd also have to define protocols etc to package the messages. Might be worth doing, but not for this case.
      • Param code has been historically hard to get right and been flaky in implementations. Adding more code to that seems risky.
    • HamishW
      • MAVFTP seems a big burden to put on component developers.
      • If we use MAVFTP we still have to keep parameter protocol and extended param protocol
      • This gives us a path to a compatible parameter protocol combining all the others, eventually dropping the fragmentation.
    • AO let Ollie et al know, close issue.

  • changes to standard flight modes #1915

    • Discuss the base_mode case - OK with removing. Only an issue if we ever remove this from HEARTBEAT. At that point many bigger changes would be happening.

Did not discuss:

Attendees: Hamish, JamesP, JulianO, ThomasDebrunner

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