edgetx
edgetx copied to clipboard
EdgeTX
Telemetry: add ability to define unknown sensor
Is there an existing issue for this feature request?
- [X] I have searched the existing issues
Is your feature request related to a problem?
The yaapu and iNav telemetry scripts expect values in the range of -1800 to 1800 for Roll (0= level). The Archer SR8 reports Roll as a float in the range of -180.00 to 180.00. So I changed Roll to calculated/multiply and found out there's no way to type "10" as the second factor. Also, there is no way to define the type, sign and range of an unknown sensor. Example: Archer SR receivers' Roll and Pitch (see bug #4729) or Flight Controllers like the Mateksys G474 which also reports Roll and Pitch (unkown IDs in EdgeTX). This enhancement would extend issue #3030 to a general purpose solution and replace my previous enhancement request #4732.
Describe the solution you'd like
Additions: • Ability to define unknown sensors as two 16 bit values, which would create a second sensor with the high 16 bits of the received telemetry (>>16 and zero out the high 16 bits in the current sensor). This would imply adding a new on/off field "Dual Sensor". • Ability to change between signed or unsigned values by placing a tilde in a new on/off "Signed" field • Add a field for number of decimal places so we can change the decimal point position, equivalent to divide or multiply by 10 independently of "Precision". This field can be negative or positive depending of the point moving right (multiplication) or left (division) and would disregard overflows (user's responsibility). • Ability to type a constant as one of the fields in Calculated telemetry and add subtraction to the Calculated options. An example for this would be to reverse the telemetry values by using Calculated/Subtract, typing 0 as the first value and selecting the sensor as the second (offset would not work here unless we had a way to change the sign). Another example would be if we wanted to change the unit between Mph to an unknown unit like "light years per aeon" (pun intended), we would need to multiply by a constant. In this case we would use Calculated/Multiply, select the sensor as the first value and type the constant as the second value (example: 1.49 for light years per aeon). I know we can use Ratio for this, but I'm posing this enhancement as general purpose. These changes would let us work around problems like bug #4729 for any unknown sensor.
Describe alternatives you've considered
No response
Additional context
No response
I did a "Bridge" Widget to help the guys at RotorFlight to create Sensors they needed before they are officially added to CRFS. Before they were trying to reuse other existing sensors, rename them in EdgeTX and use ratio/offset to adjust the value.. not always work nicely, and any changes we do on those sensors, could break their use.
Practically, the protocol push a LUA queue, any Telemetry Message that is unknown at that time, then the LUA Widget (on color radio) takes it, and creates the sensor on EdgeTX and populate the data.
Example here, check my last comment: https://github.com/crsf-wg/crsf/issues/4
Well, the Matek sensors are working (despite a misplaced decimal point which can be fixed by changing Precision). I guess this is the same functionality used by the Pixhawk FC when using FrSky's passthrough protocol for yaapu's LUA. I see no harm in adding the rest of the mods, you would be able to select Signed (if not enabled it would not affect the sensor) and adding the ability to change the decimal point position if the value doesn't fit the LUA script (i.e. iNav with Maytek or the case of bug #4729). This would enable me to use both the G474 in my heli and the SR8 in my plane with the same iNav LUA. The Signed field could be called Forced Signed if you don't want to update the tilde for all known signed sensors...
This is my Polaris plane. According to FrSky's stabilizer calibration, my SR8 receiver is pointing backwards (and it won't accept 180° inverted calibration).
Is there a way to change the sign of Roll and Ptch?
Thank you!
I don't think you can use the stabilisation when installed in a non supported way, or at the very least you should be very cautious before first flight
And be very ready to take it out of stabilised flight back to manual as soon as it starts pitching up instead of down. In reallity, you shouldn't need to even flight test it... just put it in stablised flight mode, and see if the surfaces move correctly to compensate in the right direction when you physically change the plane attitude. If they move with the attitude change rather than against, you might want to rethink that installation ;) Changing the 'sign' of pitch and roll is not what you want... that is telling you things are not going to work as they are.
Does "horizontal reverse" for the mounting type not fix that? edit: scratch that, it is for when you mount it facing down.
Not supported - orientation not supported by the receivers stabilisation firmware.
I don't think you can use the stabilisation when installed in a non supported way, or at the very least you should be very cautious before first flight
What do you mean non supported? It's firmly velcroed to the tray (the tray is glued level to the plane). Should I use double sided tape instead? (PS: I didn't tighten the velcro for this photo)
Does "hoizontal reverse" for the mounting type not fix that?
I was totally inmersed it the telemetry issue. You are right, I didn't even try to program stabilization and reverse whatever is necessary, will do, sorry.
Yeah, stablisation receivers are... fun... you have to get everything right as far as the installation and setup of the receiver, so that it knows it's the right way around, is moving surfaces the right way around, then you can finally start looking at is there something wrong with the telemetry, etc.
stabilisation might work, but for modes like horizontal, tork,... it needs to understand the plane orientation
Not supported - orientation not supported by the receivers stabilisation firmware.
Yes it is, you can always invert the way the surfaces move if they are going the wrong way. Take a look at page 6 of the SR8 manual here: https://www.frsky-rc.com/archer-plus-sr8/ What I don't know is if inverting the surface will also change the sign of the returned telemetry, which would affect the LUA scripts (whether you wanted it to or not). I'll program stabilization first, THEN wrestle with telemetry and the LUAs...
Hm...it doesn't look like it ... (and realistically it shouldn't since servo direction != orientation).
So, since I think you never actually mentioned, is the receiver giving you positive pitch numbers when the nose pitches down, and negative numbers when it pitches up (i.e. opposite to what you would expect)? It looks like my SR10+ is a pain that way also... wants all it's pins to the nose (which is opposite the orientation I would want to install it :confounded:)
Well, my SR8 has pins on both ends, so, while calibrating I actually have no idea how to point it when it says "put the pins up"... which pins LOL? I had to assume the "pins" are on the left of the sticker, just like in the SR10+.
Hm...it doesn't look like it ... (and realistically it shouldn't since servo direction != orientation).
Servo direction and SR stabilization orientation are two very different settings, SR orientation is actually saved in the receiver's firmware, and programmed using the "AP Stap Rx_OPTX" LUA script, and is independent of the channel inversions in the radio.
OK now, I programmed stabilization, this is how it is setup in my Polaris (which has the receiver "pins" pointed to the back) for the surfaces to move in the correct "compensation" direction:
SR8 receiver stabilization (using LUA script): CH5 Mode: AIL2 (I use elevons to help the small elevator). AIL direction: Invers, ELE direction: Normal, RUD direction; normal, AIL2 direction: Invers.
Radio settings: Outputs (servo direction): CH1 (AIL): INV, CH2 (ELE): INV, CH4 (rudder): NORMAL, CH5 (AIL2): INV
As you can see here elevator direction does not match, it is "normal" in the SR8 and "inverted" in the radio.
And the returned telemetry values AAAAARE: Ptch Dn: POSITIVE, Ptch Up: NEGATIVE, Roll Right: POSITVE, Roll Left: NEGATIVE
iNav, using a Ratio of 255 for both Roll and Ptch (it expects values -1800 to -1800 and -900 to 900) is working in the CORRECT direction for the artificial horizon (who would have guessed!). It still goes bananas when I go negative because of the #4729 bug, but down pitch and right roll work as expected.
I hope this helps!
Yeah, the FRskys calibration instructions/lua aren't isn't specific to the narrow form factor RXs, so I can get that being confusing... guess I probably would have just gone with "more pins" end ... :laughing: Using the sticker orientation relative to the SR10 probably makes more sense thou... would have been nice if it asked for the model or auto-detected though...
See how you go with the fix for #4729, as #4733 firmware is built now ;)
I'm curious now... with the iNav Lua HUD... ~~does that also work correctly if you turn the plane around and treat the tail as the nose?~~ nvm, that can't change without it being calibration derived... I've never tried to 'miscalibrate' the SR10+ to see if you can flip its orientation front to back... :thinking:
The SR receivers work ok with the pins pointed to the back. Now I wonder if iNav's horizon would be wrong if the receiver was pointed to the front... iNav has no inversion settings for Ptch and Roll (no config screen).
Let's see, while Roll and Ptch do affect the position of the control surfaces until the plane is level, the rudder does not depend on a "compass", the tail only moves when you are rotating the plane on a vertical axis and it goes back to the center immediately even if you keep rotating. Tail stabilization depends on the accelerometer only, your plane will NOT go back to the heading it was going after being shaken by a wind gust.
I tested an artifact (I don't know if it was #4733) for X9 Lite S today, Roll and Ptch values do go negative as they should, but something is missing (the LUA interpreter?) because iNav's horizon does not move at all and the LUA SR8 calibration script does not work with that firmware (I answered you in Discord #bugs-and-tests). Both LUAs work with nightly build 1b73d753 but the #4729 bug is still present.
I've never tried to 'miscalibrate' the SR10+ to see if you can flip its orientation front to back... 🤔
I did. Doesn't work, it keeps waiting for you to point it in the right direction, the calibration script hangs there and you have to start from the begining.
it keeps waiting for you to point it in the right direction,
Fair enough... so it's more of a "fine tune" calibration... it already knows roughly which way around it should be.
iNav has no inversion settings for Ptch and Roll (no config screen).
there should be a config screen... don't ask me how you access it on the X9 Lite S though :laughing: Unfortuantely, I don't seem to see any options for the pitch/roll/HUD https://luatelemetry.readthedocs.io/en/latest/Configuration-Settings/
the tail only moves when you are rotating the plane on a vertical axis and it goes back to the center immediately even if you keep rotating.
I doubt it has a compass in it... will just be a X/Y/Z axis accelermoeter and gyro, and will probably be kicking the tail proportional to the amount of yaw it detects?
something is missing (the LUA interpreter?) because iNav's horizon does not move at all
It shouldn't be... it's no different to a nightly build but with that change. What could be the case is that if iNav Lua is working with the current weird values, maybe it was coded with that in mind or (or is actually the expected behaviour?), so doesn't like the sign corrected code. See how you go with tomorrows nightly.
Just played with the iNav Lua and SR10+ a little more... something seems off... the sign corrected telemetry seems to be working better than the prior non-signed values, but it still isn't right... I suspect it simply isn't compatible with the telemetry coming from these FRSky receivers... will have to compare with a proper iNAV FC and see what is happening there.
Just played with the iNav Lua and SR10+ a little more... something seems off... the sign corrected telemetry seems to be working better than the prior non-signed values, but it still isn't right... I suspect it simply isn't compatible with the telemetry coming from these FRSky receivers... will have to compare with a proper iNAV FC and see what is happening there.
Did you set Ratio to 255 in both Roll and Ptch? iNav complains if it doesn't detect the GPS, but I plan to connect an FrSky GPS ADV. The artificial horizon (which is what I wanted) works pointing the plane down or right with the bug, I'll test the new artifact.
there should be a config screen... don't ask me how you access it on the X9 Lite S though 😆
Right, I pressed all the butons, couldn't activate it... I was unaware of the config screen in iNav
I doubt it has a compass in it... will just be a X/Y/Z axis accelermoeter and gyro, and will probably be kicking the tail proportional to the amount of yaw it detects?
For Roll and Ptch it uses the magnetometers, because the ailerons and elevator keep deflected until the plane is level. Yaw on the other hand uses the Z accelerometer only. The tail kicks only when the plane is applied an accelerating rotation on the vertical axis (yes, it's proportional to the acceleration). If you keep rotating at the same speed the rudder goes neutral.
I connected the GPS ADV to the SR8. As you can see iNav is now reporting coordinates (but still complains because of the lack of compass). Good enough for me. I'll test the bugless nightly as soon as it gets processed.
For Roll and Ptch it uses the magnetometers, because the ailerons and elevator keep deflected until the plane is level. Yaw on the other hand uses the Z accelerometer only.
FYI, I don't think they have a magnetomter.
Built-in 3-axis gyroscope and 3-axis accelerometer sensor
A gyro measures angular velocity (rotation around an axis), hence using a gyro to measure rotational force (like used to be done with helis), which is what would be in part controlling the rudder. An accelerometer on the other hand measures linear acceleration (side to side on a given axis). Hence why 6DOF IMU sensors (gyro+acc) are all that is needed to determine orientation. Given no compass (magnetometer) is exposed as a sensor or mention of it as a feature, I would not expect there to be one in these receivers. A 9DOF (gyro+acc+mag) IMU could be advantageous, as the north reference would lock in the craft orientation absolutely, but that is about all... it's more useful when you have a GPS so it can be used as part of waypoint or return home capabilities. Especially due to the extra calibration requirements it adds to both initial setup and subsequent flights (i.e. needing to rotate the craft more than 360 degrees on each axis to determine exactly where magnetic north is).
@pfeerick excellent explanation, thank you! So, translating my previous comment, it uses the ~~accelerometers~~ to keep the plane level and the gyro to kick the rudder. Scratch that, this is all about rotations, only the gyros are used! Not only for the rudder, for the ailerons and elevator too, just the reaction is different for those. The accelerometers aren't used at all. ~~This means, since it has no magnetometers, the receiver has no idea where the horizon is unless we perform the "blue LED" calibration after powering it up. Wow.~~ Wrong statement: the Z accelerometer measures the 1g earth gravity, so it knows where the horizon is.
Just played with the iNav Lua and SR10+ a little more... something seems off... the sign corrected telemetry seems to be working better than the prior non-signed values, but it still isn't right... I suspect it simply isn't compatible with the telemetry coming from these FRSky receivers... will have to compare with a proper iNAV FC and see what is happening there.
I just tested nightly 904a920. It works perfectly! Thank you @pfeerick and @frankiearzu !
I don't understand why you had problems, did you set "Ratio" to 255?
Thanks for the update.
I've never changed the value of radio, so it's still - on my TX. :innocent: So you are right... changing the ratio to 255 make the iNav Lua happy... the hud orientation now pretty much matches the receivers. Thanks! :)
It should use the accelerometers, but only when you want to self-level... i.e. if you dip a wing, it's using the combination of acc+gyro to know how much deflection to put into the elevator, and know when it is level again. Using a gyro only for that sort of correction tends to drift over time => unstable flight.
So you are right... changing the ratio to 255 make the iNav Lua happy...
iNav expects Roll values of -1800 to 1800 and Pitch of -900 to 900 (because it was developed with those sensor values). In fact, that is what Matek's G474 returns without touching Ratio (and if I don't change Precision to adjust to 180.0). Also, this is one of the reasons why I'm suggesting the enhancements in the first post of this request LOL. If breaking compatibility is an option, just freeing Offset and Ratio to any value would allow us 90% of these adjustments. I could just use a ratio of -1 to change sign (to invert the sensor), or 10.0 (instead of 255) to multiply Roll by 10 for iNav... you get the idea.
Hi everybody,
I've kindly been directed to this ticket to add my possibly related request:
The ability to divide one telemetry value by another e.g. [power in] / [vertical speed].
An alternative implementation to the above would be an operator to take the inverse of a telemetry value (which could in turn be used as a multiplier for another value).
Kindly, Andrew
