Supernovae

> @shubham-shahh commit history is a bit of a mess. Let me know if you'd like some help cleaning it up. Otherwise we have some help here: https://ardupilot.org/dev/docs/git-interactive-rebase.html sure @peterbarker...

Hi, @hendjoshsr71 I ran the test in SITL and passed different yaw and Yaw rates `message SET_POSITION_TARGET_LOCAL_NED 0 1 0 1 0 0 0 -4 0 0 0 0 0...

Hi @peterbarker, I tried cleaning up a bit, I am no git expert, if there are any more improvements to be made, do let me know thanks

> Txs for this. In general this looks good but I think we can avoid duplicate state by directly using the auto_yaw object. Thanks for the review, I'll look into...

> I really like what you are doing here but I would have thought we could use the existing yaw targets without having to recreate them in Guided. > >...

Hi @rmackay9, I and @hendjoshsr71 tried to fetch the yaw value from auto yaw object but they don't correspond to the correct values, can you please help me with this?

> When it is possible, sys_time does timesync between FCU and OBC. So mavlink messages with timestamp fields will be relatively close to FCU's time. > You can also use...

> https://github.com/vooon/ntpd_driver > > It simply forwards GPS time to NTP daemon, which do the rest of keeping time in sync. Hi, I tried this package, and it's not working...

> 1. It will get going with the same last adjusted pace (ntp adjusts frequency) > 2. I'm not an expert on clock sync, but since each sat have atomic...

> That's always all about the requirements on how accurate time should be. Clock speed depends on many factors, e.g. temperature change. But actually with NTP it'll drift more. With...