Hamish Willee

Thanks @julianoes - So as I understand it the problem you had was that the velocity components were assumed to be aligned with the airframe - so as it pitched...

@auturgy That's useful. The proposal, if accepted would make this pretty unambiguous: - LOCAL/BODY reflect the _origin_ of the co-ordinate system - fixed on earth (nominally "home") or fixed on...

Following review of the spec. - the non-deprecated frames are consistent with the frames RFC naming convention. The exception is `MAV_FRAME_LOCAL_OFFSET_NED` which would be named `MAV_FRAME_BODY_NED` (but we can't because...

>>> Let me wrap my head around all this: @julianoes > _LOCAL means frame origin is fixed in earth frame - i.e. nominally relative to "home position" > Just to...

@Jaeyoung-Lim Re ^^^ https://github.com/mavlink/mavlink/pull/1685#issuecomment-923021675 Thanks very much! Sure - COG was just a suggestion. What we need is a succinct term that means "on the vehicle frame" to replace `BODY`...

I think marking it as reserved makes sense in this case because I can't see anyone using this message. IMO best to never use a capability bit to indicate general...

@auturgy @julianoes So, since this is not used in ArduPilot or PX4, and the associated API looks like something you shouldn't use because it is a bit broken, I have...

@BazookaJoe1900 Re https://github.com/mavlink/mavlink/issues/1149#issuecomment-592448557 thanks, but that is out of scope for this discussion (it is PX4 specific and MAVLink is flight stack agnostic) - and I do not believe it...

@jarednm There is no formal release process and no documentation on the differences between the minor releases (yes, there should be). We are pretty careful about compatibility. Most releases only...

Would like to clarify how releases kind of work (or dont) at some point