docs: add OSD HUD and Craft Radar page - #24
Conversation
Ports the "OSD-Hud-and-ESP32-radars" page from the GitHub wiki into the Docusaurus site as docs/06-advanced-features/osd-hud-and-craft-radar.mdx, and repoints the related-documents entry in the OSD page at it. Every setting was checked against src/main/fc/settings.yaml on maintenance-10.x and the defaults and ranges corrected where they had drifted: osd_hud_homing, osd_hud_homepoint, osd_hud_radar_disp and osd_hud_wp_disp all default to off/zero rather than enabled, osd_hud_radar_range_min defaults to 3 m and not 10 m, and eight crosshair styles exist rather than seven. The three settings the wiki never documented are now covered: osd_hud_radar_alt_difference_display_time, osd_hud_radar_distance_display_time and osd_radar_peers_display_time. The peer data path is described from the firmware rather than from the old text: peers arrive over MSP2_COMMON_SET_RADAR_POS with the payload parsed in fc_msp.c, are stored in the radar_pois slots, and are drawn by osd_hud.c. Two points that readers regularly get wrong are now stated explicitly - the peer element is OSD_FORMATION_FLIGHT while OSD_RADAR is a home-point map, and the firmware applies no timeout to peer positions, so a stale marker stays on screen until the module updates it. Third-party ESP32 and FormationFlight hardware and firmware are kept as external links only, with no version or capability claims.
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can switch off images and animations for a plain-text comment |
PR Summary by QodoDocument OSD HUD and craft radar configuration
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
|
@Raffi1202 There are some statements like this -
That makes it sound like this is how you would set a multicopter for HUD use. While in reality you don't want to use the Craft radar feature (formation flight or the older INAV ESP32 radar) with the HUD. Because a copter can hover in the one spot and rotate on the yaw axis. This causes the HUD to provide incorrect positioning of the peer aircraft.
The warning that is written above. Makes it sound like the INAV radar feature can only be used with FormationFlight, However some pilots still use the older LILYGO hardware and ESP32 INAV radar firmware on their airplanes without issue. I noticed most of your commits are written by an AI. Which can cause issues when it's interpretation of how something works is based on what it reads, and not what it has experienced. We need to remember that the wording has to be in layman's terms. So the user doesn't require an AI to interpret what the document is saying. Otherwise they may as well use Google AI to find out how it works in the first place. |
Two things the page got wrong, both reported by Jetrell: A multirotor can hover and rotate on yaw, so the HUD draws peers in the wrong direction - it positions them relative to where the camera points. The page read as a setup guide for exactly that. It now says so up front and sends multirotor pilots to the fixed element. The element warning read as if Formation Flight were the only way to get peers. OSD_FORMATION_FLIGHT is the name of the OSD element, not of the hardware; the older ESP32 radar firmware feeds the same display.
|
@Jetrell You are right on all three counts, including the last one. Let me take that one first, because it is the reason the other two happened. Yes, I write these with AI assistance, and your diagnosis of the failure mode is exact: it produces text from what it can read, and there is no way to read "a copter hovers and rotates on yaw, so the HUD puts peers in the wrong place" out of the source or the settings descriptions. That is flying knowledge. I had the uptilt range right and the whole point wrong, which is worse than leaving the section out - a reader would have set it up and trusted it. I am not going to stop using the tool, but I will stop shipping pages that depend on experience I do not have without someone who has it reading them first. If you are willing to keep doing what you just did on the pages I have open, that is worth more to me than the pages themselves. If you would rather I pull them until then, say so and I will. On the wording: point taken there too. Anything that needs decoding has failed. I will go back through the other four for anything that reads like a specification rather than an instruction. The two corrections are pushed in Multirotors and the HUD. A warning now sits directly under the camera-geometry section, before anyone starts setting values:
The setup section now says plainly: on a plane raise The older radar hardware. The warning about
If the LILYGO/ESP32 path needs more than that - a different port setting, a firmware note, anything a pilot on that hardware would trip over - tell me and I will add it rather than guess. |
|
To assist in having agents help write documentation that needs less editing, I have created some guidance for them. Comments or edits from either of you would be appreciated. |
@sensei-hacker That is very useful guidance. If a contributor uses AI assistance. They could run your document by it before it writes their document. That should at least keep the AI model on track. So it doesn't go off rewording things that can often change the whole meaning because of its misinterpretation. @Raffi1202 That it clearer and on point with its operation. |
3 participants
Part of moving the GitHub wiki onto the docs site. Ports "OSD-Hud-and-ESP32-radars" to
docs/06-advanced-features/osd-hud-and-craft-radar.mdxand repoints the related-documents entry on the OSD page at it.The old defaults were wrong
Every setting was checked against
src/main/fc/settings.yamlonmaintenance-10.x, and most of the values on the wiki page had drifted:osd_hud_homing,osd_hud_homepoint,osd_hud_radar_dispandosd_hud_wp_dispall default to off / zero, not enabled. The wiki showed the peer display as 3; it is actually off by default, so following the old page left readers waiting for markers that could never appear.osd_hud_radar_range_mindefaults to 3 m, not 10 m.Three settings the wiki never documented at all are now covered:
osd_hud_radar_alt_difference_display_time,osd_hud_radar_distance_display_timeandosd_radar_peers_display_time.The peer data path is described from the firmware
Peers arrive over
MSP2_COMMON_SET_RADAR_POS, the payload is parsed infc_msp.c, stored in theradar_poisslots and drawn byosd_hud.c.Two things readers regularly get wrong are now stated explicitly:
Third-party hardware
ESP32 and FormationFlight hardware and firmware are kept as external links only, with no version or capability claims, so the page does not go stale when they change.
Image
static/img/features-adv/osd-hud-craft-radar-layout.pngwas not in the wiki repository, only as an attachment URL. It was fetched, viewed and checked against the code before being committed here.