Peter Barker

> I'm in favor of this. I'm just wondering what additional fields we should add, e.g. UTC GTPS time. GTPS? I guess you meant GPS here? @tridge suggested gps week...

> @peterbarker I also think we should add gps_week and gps_week_ms, that is the real key to time handling with GNSS I've discussed this with tridge and he's expressed the...

Working on this one again a little. Wondering if we should try to reduce the packet size and use float16 for the accuracies. ArduPilot and pymavlink has good support for...

> I guess this might be a important message in a mapping workflow, I wonder if we should change the labels to purposely break peoples scripts. Currently they would probably...

Only output change is that the romfs on the periphs is 60-odd bytes larger.

The vehicle may never actually be at its navigation origin, so I don't think an orientation in the message makes sense. Telling the vehicle definitively via a `MAV_CMD_EXTERNAL_POSITION_ESTIMATE` might be...

> @peterbarker How do you suggest we orient the vehicle to the global frame on initialization? Should we send a MAV_CMD_DO_SET_GLOBAL_ORIGIN, and then MAV_CMD_EXTERNAL_POSITION_ESTIMATE with the heading? I see your...

On Sat, 7 Jun 2025, njdevi11 wrote: > @peterbarker I think you're mistaking the desire here, I've never once mentioned setting roll and pitch and don't need to inject roll/pitch....

On Tue, 10 Jun 2025, Hamish Willee wrote: > What I think @peterbarker is suggesting is a new message MAV_CMD_ATTITUDE_ESTIMATE to complement MAV_CMD_EXTERNAL_POSITION_ESTIMATE. > For your case you could define...

FWIW, quick discussion with tridge and he noted that we would probably treat the input from this message in a qay very similar to the way we do a yaw...