Camera uptilt AHI compensation

[avsaase]

On a quad, I would like to have the artificial horizon in the middle of the osd when the camera is level with the ground, not when the quad is level. I'm actually surprised this feature doesn't already exist.

This PR uses the existing osd_camera_uptilt cli command from the HUD feature to shift the AHI according to camera uptilt. However, it doesn't work yet. Increasing osd_camera_uptilt correctly shifts down the AHI, but far from enough. I can probably figure it out eventually, but if someone can point me in the right direction then that would be great.

[Jetrell]

@avsaase Do you intend to mix it with the applied elevator stick input?

Reminds me of when I integrated a camera gimbal that used accelerometer tilt compensation. To always keep the camera facing forwards, no matter the tilt angle of the quad.
Worked nice. But the AHI and pitch angle degrees needed to be watched all the time, unless the props are in view.

[avsaase]

@Jetrell No this is just to keep the AHI somewhat aligned with the horizon. Right now when I pitch forward to get the camera level and fly straight ahead, the AHI completely moves out of view on the top side of the screen.

[avsaase]

I must have made a mistake with flashing this morning because now it works as expected.

[OlivierC-FR]

Why not using the existing setting : osd_horizon_offset ?
Granted, it only allows -2 to +2 correction, but could easily made to allow a wider range.
CMS > OSD > HUD > HORIZON OFFSET

[avsaase]

I expected you to comment on this 😅 . Do you mean osd_horizon-offset already moves the horizon up and down? A far as I can see it is only used in osdCrosshairPosition(). Regardless, I think the uptilt angle in degrees is much more intuitive and direct than the osd_horizon_offset in lines (?).

[OlivierC-FR]

I expected you to comment on this 😅 . Do you mean osd_horizon-offset already moves the horizon up and down? A far as I can see it is only used in osdCrosshairPosition(). Regardless, I think the uptilt angle in degrees is much more intuitive and direct than the osd_horizon_offset in lines (?).

Yep it moves the crossair, but all the AHI and sidebars and hud POIs etc are positionned relative to the crossair, so in the end it moves the whole thing as a block

void osdCrosshairPosition(uint8_t *x, uint8_t *y) { *x = osdDisplayPort->cols / 2; *y = osdDisplayPort->rows / 2; *y += osdConfig()->horizon_offset; }

Then the AHI in osd.c at line 1715

[avsaase]

Yeah okay, but I'm not trying to move the elements, just trying to compensate the AHI for the camera uptilt. This PR does that in a much more straightforward way.

[avsaase]

I quite like this so can I merge it?

[b14ckyy]

@OlivierC-FR LOL
right today when I tested RC1 the first time I fell exactly over what you describe and it totally threw me off that my AHI did not align with the crosshair when flying level. I agree with you here. Using osd_ahi_vertical_offset makes much more sense here as on wings we wenat to align the AHI with the crosshair in level flight.

[OlivierC-FR]

@OlivierC-FR LOL
right today when I tested RC1 the first time I fell exactly over what you describe and it totally threw me off that my AHI did not align with the crosshair when flying level. I agree with you here. Using osd_ahi_vertical_offset makes much more sense here as on wings we wenat to align the AHI with the crosshair in level flight.

I also could not fly with the AHI "wrong" relative to the crosshair, but that's personal taste.
Well anyway now that both settings are available, pilots can go with whatever they prefer.
And that's mostly with planes yeah. With multirotors, the AHI is lost out of sight in another dimension in time and space ;)

[b14ckyy]

yes we have 2 options currently but osd_ahi_vertical_offset will ONLY affect Pixel OSD.
IMHO we still need to separate the HUD element offset (for camera angle) and the Horizon offset relative to the crosshair.

On classic OSD i use the crosshair offset that will also move the AHI up or down, to align with the physical horizon.