iNavFlight
Add custom telemetry values for transmission to an edgetx transmitter
Current Behavior
Currently, the only telemetry values allowed are those built into the firmware. In my use case I use a microcontroller that receives telemetry from one FC port and "publishes" data via another. As things stand I have to hijack existing but unused telemetry elements (in my case rangefinder) to carry telemetry data from my micro controller to the FC and then to my transmitter or OSD.
Desired Behaviour
Via CLI or the configurator, I would like the option to "define" a telemetry name value pair. If Inav offered x number of custom telemetry slots, I would see something like cli commands:
set custom_tel 1,"MYTELEMNAME",x,y
where 1= the custom telemetry slot I want to use between 1 and max_num_custom_telem, "MYTELEMNAME" is the name for the telemetry value x is a default value for the telemetry value y is the UART on which the value will arrive
Then the FC would know to expect telemetry of this type to flow from that UART, and all the FC is required to do is post that new telemetry value along with the standard items.
Suggested Solution
See above for a possible implementation. In addition to this, being able to refer to custom telemetry values in programming, OSD, etc, would make this a very powerful option. For example, with programming, I could carry out actions depending on the values of custom telemetry fields read from the daughter processor feed. I could create custom fields for my OSD based on these values. I could change flight modes based on data collected and forwarded to the FC. The options for this are endless and will spark great innovation.
Who does this impact? Who is this for?
Anyone who wants to innovate with developing new payloads easily, and anyone who wants to extend the FC processing say onto a daughter processor like the esp32 or pi pico easily.
Additional context
I have a specific use case, however, I feel that this feature is one of those features that if you build it, they will come. It will spark possibilities for innovation.
Which telemetry protocol are you thinking of? Each protocol - CRSF, Smartport, SRXL, SRXL2, etc all have their own values sent in their own way.
Hmm, actually if you add new values to CRSF, it's not CRSF anymore. So what you're wanting is to make up your own telemetry protocol.
Or use MSP, such as via mLRS, because that includes INAV global variables as something you can request and send! And those global variables are built in to the Programming tab, the mixer, the OSD, etc. Sounds like you just want to use MSP rather than whatever telemetry protocol you were using before.
That's the protocol typically used with a flight computer and described in the documentation for for INAV remote Management, Control, and Telemetry. https://github.com/iNavFlight/inav/wiki/INAV-Remote-Management%2C-Control-and-Telemetry
@sensei-hacker the sensible thing to do would be create an interface and implement it for each protocol. you are correct that CRSF has a rigid standard I often use other sensor data to perform "fusion" or use literal fusion and augment the gps data crsf supports for accurate header position etc... similar techniques could be used for other protocols as well. each implementation would provide a feature support map so we don't waste time calling on methods that can't transmit useful data. I deal with this a lot with custom ground vehicles that lack an FC. here is my gps fusion lib for esp32. https://github.com/wdunn001/GeoAtom
Using telemetry is the wrong way to work with a board like the ESP32 or Pi. You should talk via MSP. You will likely find everything you need already there. Those telemetry protocols are deliberately kept lightweight for better use OTA.
@MrD-RC I understand that MSP is better for MCU support, but I have esp32's laying around and this isn't critical data. I use the microcontroller as a preprocessor for sensor fusion in a device that otherwise does not have a microcontroller. Like sure I guess I can add a stm32 as it is better with timing, but I am also doing several other things like processing that telemetry and drawing a custom OSD, drawing on a led screen and hosting a web server, transmitting aprs packets etc.
That's a cool project. Pretty similar to one of my own. https://github.com/sensei-hacker/CheapGPSTracker-Helium
I use a similar small board to read a GPS module such as a BN-880 or better BK-880. The differences being for my project, I relay the GPS information out over the Helium network, vs displaying it on a screen. Mine is also designed so the same GPS module can ALSO be shared with an FC.
I understand that MSP is better for MCU support, but I have esp32's laying around and this isn't critical data. I use the microcontroller as a preprocessor for sensor fusion in a device that otherwise does not have a microcontroller. Like sure I guess I can add a stm32 as it is better
There is absolutely nothing about the MSP protocol that requires STM32. In fact it was originally written for Arduino, in 2011. That's an 8-bit Atmega328P board. You'd connect a gyro harvested from a Nintendo Wii game controller. (Hence multiWII serial protocol, MSP).
I have an ESP32-powered device sitting on my desk right now that speaks MSP. If I ever do a version 2 of this device, I'll use a Pico (RP2050)
Even mLRS (think MSP over LORA) can use some of the same ESP32 gear that is typically sold for use with ELRS.
Are you thinking "since I'm using ESP32 I therefore have to base my protocol on i-BUS"? Or base it on SRXL2 or crsf or Smartport2 or -- you never said which protocol you're trying to modify to make it work more like MSP.
That was my first question, which protocol are you trying to modify? I don't think you ever answered that. MSP is the protocol that already does what you want. If you want to modify some other protocol to make it more like MSP, it might be helpful to know which protocol you're wanting to modify.
Which telemetry protocol are you thinking of? Each protocol - CRSF, Smartport, SRXL, SRXL2, etc all have their own values sent in their own way.
Hmm, actually if you add new values to CRSF, it's not CRSF anymore. So what you're wanting is to make up your own telemetry protocol.
Or use MSP, such as via mLRS, because that includes INAV global variables as something you can request and send! And those global variables are built in to the Programming tab, the mixer, the OSD, etc. Sounds like you just want to use MSP rather than whatever telemetry protocol you were using before.
That's the protocol typically used with a flight computer and described in the documentation for for INAV remote Management, Control, and Telemetry. https://github.com/iNavFlight/inav/wiki/INAV-Remote-Management%2C-Control-and-Telemetry
The two use cases for the data are
- to send to the OSD
- To send to the transmitter
In my rangefinder example I am publishing values to the rangefinder using MSP on UART4 (see my current ports tab)
but to send to the transmitter i believe the default is crossfire? From an outcome perspective I would like to see the values I produce on either the OSD or a telemetry page on my radio, does that help?
Using telemetry is the wrong way to work with a board like the ESP32 or Pi. You should talk via MSP. You will likely find everything you need already there. Those telemetry protocols are deliberately kept lightweight for better use OTA.
If I want values from my microcontroller to appear on my telemetry screen, how would you best suggest that I achieve that? Let's say that my microcontroller was counting sheep. How do I get the number of sheep found from my microcontroller to my radio?
For what purpose?
As already pointed out. Some telemetry protocols are strictly defined. So just adding a random sensor is not possible.
If this is for logging of test data. The best place to do that is on the external board itself.
If your board is modifying a value or providing a sensor. The original sensor's output should now be showing your value (such as the rangefinder). Or a new sensor would require support added for it.
If it's an already existing sensor. There is most likely an OSD output for it. If it's a new sensor. Then an OSD element would need to be created.
In my rangefinder example I am publishing values to the rangefinder using MSP on UART4 (see my current ports tab)
From an outcome perspective I would like to see the values I produce on either the OSD or a telemetry page on my radio, does that help?
To display something on the OSD
There are two possibilities. First, look on the OSD page in Configurator and see if there is a stock widget for what you want to display. For altitudes, there is. Boom, you're done, with one click and drag.
If you want to display number of sheep, from a global variable, you'll create a custom element on the right side of the OSD configuration page.
https://github.com/iNavFlight/inav/wiki/Custom-OSD-Elements
To display it on the radio
but to send to the transmitter i believe the default is crossfire?
The newest Configurator prompts you to choose a protocol right after you flash, on first boot. So there's not really a "default". Not that it would really matter anyway - you'd want to choose a protocol that actually works for your radio and your needs.
If your radio supports CRSF, it probably also supports Smartport2. CRSF has a very limited number of sensors defined in the packet format. Smartport has many more.
To display and do MORE (laptop ground station)
A laptop running the MWP ground station can do much more than what fits on the radio screen. mLRS is one option for on-air protocol that fits pretty well for a ground station.
That's a cool project. Pretty similar to one of my own. https://github.com/sensei-hacker/CheapGPSTracker-Helium
I use a similar small board to read a GPS module such as a BN-880 or better BK-880. The differences being for my project, I relay the GPS information out over the Helium network, vs displaying it on a screen. Mine is also designed so the same GPS module can ALSO be shared with an FC.
ah mine was originally designed for a icom 7100 backpack radio system primarily meant to feed it fusion data over gps messages