Andy: The existing polygon function wasn’t accurate enough. I think it’s because it uses Cartesian and not lat/lon.
Of course, a new implementation is costing more flash.
Andrew: It used to be lat/lon.
But we now convert the coordinates to Vector2f (e.g. read_polygon_from_storage).
Hence fences become less accurate, the further out they go.
Did you mean to support all fence types?
A: Yes Andrew: We do have the Vector2f in memory, you can call it directly and save loading/processing anew. A: What kind of error are we looking at if we implement warning in lat/lon and breach in float? Andrew: It’s at the worst 1m for a planet-wide fence. A: Alright, I’ll try with the Vector2fs then. Michelle: We could be storing the origin along the Vector2fs, and not use lat/lon, if that’s a problem. Andrew: We do like using lat/lon as it’s the primarly format for input and display. Peter: At this point we’re +1900B for this PR.
Peter: We should be able to assign each fence with a breach action. George: Yes, and also it’s more intuitive/transparent to have multiple fences for each warn/rtl/etc action. And they should be created in the GCS side: The user could draw multiple fences, or click a button to automatically copy and offset.
UTC0728
Andrew: LGTM. Randy should approve.
Andrew: Nice!
Can you check what would happen if there’s a (0,0) waypoint right after the DLS waypoint?
UTC0735
A: RV_MASK is wrong indeed, but to change it is some effort.
You’d expect bit 0 to map to servo 1, but it doesn’t in my experience.
Andrew: I don’t think there’s a way to un-reverse a DShot ESC without rebooting it. That’s a gotcha.
Is there an example of bad behaviour? Does the flight controller have an IOMCU?
By the way, we should rename all the _BLH_ names. Perhaps DSHOT_*?. SERVO_* is also inaccurate, but also another problem.
UTC0745
Discussion on an issue found on some M10 GNSS RXs where they would get stuck in their configuration.
UTC0801
Andrew: It’s fine to remove, as long as we accept the argument and do nothing without it.
Continuing live-debugging of the problem from UTC0745.