Enhance OSD Custom Elements

[MrD-RC]

The OSD custom elements are extremely useful. They can provide pilots with any information they can access and modify in the programming framework. They can, for example, be used to show the position of a switch on the transmitter. But in a more customisable way than the current switch indicators.

• Removed switch indicators, as the functionality and more can be achieved by the custom elements
• Increased the number of custom elements to 8
• Changed MSP to read custom elements to two calls. The settings, then individual elements. This was to allow for more than 4 custom elements
• Added more types to allow for a greater number of numerical formats
• Added types to allow reading the values directly from logic conditions. Rather than having to store the value in a global variable.
• Changes the method to constrain the numbers, so that negative numbers will work.

OSD Custom Elements now have their own category on the left options menu.

The layout for the editing boxes. Changing the options for each custom element now updates the OSD preview. Meaning that the OSD can be accurately aligned without having to use the goggles.

The drop-down list for the new type options. The original None, Text, Icon Static, and Icon GVar are still at the top. The numerical options for global variables are matched for logic conditions.

A screen shot from HITL to show the same layout as seen in the above configurator screen grabs.

enum change
This update does change the indexing of enum osdCustomElementType_e. This would break backwards compatibility. I could change the enum values so that the old settings persist. But, this is a new feature, and it would be better to have the enum ordered appropriately.

Numeric format	Old name	Old ID	New name	New ID
000	CUSTOM_ELEMENT_TYPE_GV_SMALL	6	CUSTOM_ELEMENT_TYPE_GV_3	7
00000	CUSTOM_ELEMENT_TYPE_GV	4	CUSTOM_ELEMENT_TYPE_GV_5	9
0.0	CUSTOM_ELEMENT_TYPE_GV_SMALL_FLOAT	7	CUSTOM_ELEMENT_TYPE_GV_FLOAT_1_1	10
0000.0	CUSTOM_ELEMENT_TYPE_GV_FLOAT	5	CUSTOM_ELEMENT_TYPE_GV_FLOAT_4_1	15

MSP Breaking change
This change was required to allow for more than 4 custom elements to be used. Normally, I would create new MSP IDs. But this has only been in INAV for a single version. And it is unlikely used by external tools. I asked in the dev Discord group, and there were no objections.

• MSP2_INAV_CUSTOM_OSD_ELEMENTS (0x2100) used to pull the settings and all custom OSD elements. Now it just pulls the settings.
• MSP2_INAV_CUSTOM_OSD_ELEMENT (0x2101) pulls an individual custom element's data
• MSP2_INAV_SET_CUSTOM_OSD_ELEMENTS (0x2102) Sets an individual custom element's data

Requires Configurator
iNavFlight/inav-configurator#2159

Release notes

Changes have been made to Custom OSD elements. This update changes the indexing of the custom element type. This breaks backwards compatibility. To keep your custom OSD elements working, you will need to change the element type IDs, if they are 4, 5, 6, or 7. The table below shows the old and new IDs.

Numeric format	Old name	Old ID	New name	New ID
000	CUSTOM_ELEMENT_TYPE_GV_SMALL	6	CUSTOM_ELEMENT_TYPE_GV_3	7
00000	CUSTOM_ELEMENT_TYPE_GV	4	CUSTOM_ELEMENT_TYPE_GV_5	9
0.0	CUSTOM_ELEMENT_TYPE_GV_SMALL_FLOAT	7	CUSTOM_ELEMENT_TYPE_GV_FLOAT_1_1	10
0000.0	CUSTOM_ELEMENT_TYPE_GV_FLOAT	5	CUSTOM_ELEMENT_TYPE_GV_FLOAT_4_1	15

Below, you can see the position of the IDs that you need to change if they are 4, 5, 6, or 7.

osd_custom_elements 0 3 0 1 0 0 0 0 0 "FLAPS"
                      ^   ^   ^

[mmosca]

Sounds like we are removing something simple (switch indicators) with something users will have a hard time wrapping their heads around, even if it is more powerful.

We should probably leave the switch indicators alone for now.

[MrD-RC]

I honestly don't think it's too bad a change. I can make a very quick example on how to replicate the functionality. It just seems pointless to me to have two things that can do the same thing.

[Jetrell]

I do get @mmosca point.. However, I'm sure Darren will make a good tutorial video concerning this feature, to help people understand how to take full advantage of all it offers.

[mmosca]

I do get @mmosca point.. However, I'm sure Darren will make a good tutorial video concerning this feature, to help people understand how to take full advantage of all it offers.

We are going from this, where the user enables a switch indicator, picks a channel and give it a name:

To making 5 choices, including picking an icon by number and potentially setting up things in the programming tab.

While the custom OSD is powerful and can replicate the switch indicator function, I see it as an advanced option, not something every user will be familiar and confortable using.

My opnion is that we should at the very least match the usability of the existing switch indicators, but it is probably best to leave them alone and let advanced users use the custom osd elements if they need more than 4 switch indicators.

The original intent of the custom osd was to augment the existing osd, cover corner cases and add flexibility, not necessarily replace parts of it.

[Jetrell]

@mmosca As I mentioned. I do see your point..
I figured that @MrD-RC was also considering the extended load time of the OSD tab, compared to other tabs. And not duplicating the same function.

[mmosca]

@MrD-RC was there a technical reason to replace the switch indicator elements? (Like, did we run out space on the variable that stores the osd elements?)

[MrD-RC]

No, it just seemed silly to replicate functionality. I just see this as working better to do the same thing.

It's true. It does need some lines in the programming framework:

and then add the change to the OSD custom elements

But it's not much at all.

However, writing this has given me 2 other changes to make.

1. Allow LC and GV for setting the icon. That wouldn't need the 4th line.
2. Show the actual icon if the LC/GV value is valid

[mmosca]

No, it just seemed silly to replicate functionality. I just see this as working better to do the same thing.

It's true. It does need some lines in the programming framework:

and then add the change to the OSD custom elements

But it's not much at all.

However, writing this has given me 2 other changes to make.

1. Allow LC and GV for setting the icon. That wouldn't need the 4th line.
2. Show the actual icon if the LC/GV value is valid

Why don't we keep the existing switch indicators and your improvements to the custom osd, including the extra ones?

That way we keep the easy of use for the users, and the extra capabilities for the advanced use cases.

[MrD-RC]

I couldn't get the live values from GVs or LCs unfortunately. But added the ability to use LC outputs directly to set the icon

[sensei-hacker]

It occurs to me we COULD keep the same UI available for now, but behind the scenes implement it using the new feature.
I am not volunteering to code this, though. :)

[error414]

I did not created custom osd elements as replacement for switch idicator. It was just side efect. I use custom osd elements for

• low speed warning stall
• durring VTOL transition I show info that aitspeed is enought to switch fix wing mode speed OK
• warning if flaps are down in hight speed FLaps
  and as well
• for flaps where is showed angle of flaps "Flaps 10" "Flaps 20" "Flaps 25"

In my todo list is:

• more numerical formats, it's cool that MrD-RC done that
• clickable icon selector, I don't like that you have to write number of icon, choose `icon by clicking to icon would be much easy and stright forward for users.
• so far icon number uses uint8, but I think that some icons uses two bytes.

[MrD-RC]

I have reinstated the Switch Indicators. Maybe they can be removed in a later release.