Arducopter position

[lvale]

Added Roll and Pitch angles as A3 and A4.

Also added battery remaining (in %) as reported by the Flight Controller.

Could not find a better way to send it down, so Throttle (on RPM) now is multiplied by 100 (x2 due to the settings on Taranis for 2 blades) and added the percentage of battery remaing (also x2).

[chsw]

Unfortunately your branch is 28 commits behind master. Is it possible make it more up to date?

[lvale]

I believe I've managed to get uptodate with you and only the relevant bits are in

changes are:

removed my telem2 script

added on frskysport sending both A3 and A4, and on RPM modified to send both Throttle and remaining battery

added on mavlink-frskysport capturing roll, pitch and battery remaining

[chsw]

I'll merge this as soon as possible. I realize I need to read up on merging in github first :)

[lvale]

Please be aware that we'll have to overview the scripts again to check for the change on FR_ID_RPM.

Now the Throttle comes like (value)_2_100 and the first 3 digits are %% of battery remaining.

The output looks like 10099, where 100 is throttle and 99 bat capacity remaining.

[chsw]

So it would be imposible to have battery status at 100%? Wouldn't it be better to have the first 8 bits as battery status and the last 8 bits as throttle? (and multiply the value by 2 just before we send it through telemetry?

[lvale]

From what I've seen battery capacity remaining never reaches 100% :) as it's being reported by the flight controller. Both Throttle and Bat capacity are reported from the Mavlink as a percentage value. I considered having it being coded on binary like you suggest, but like this, even if you don't use a telemetry script the values can be "read" easily (like what is being done today with GPS satellites and lock).

I still have to do some more testing on this, because I have to look at the APM code to see what is being used to present the battery capacity remaining as reported by Mavlink.

I'm thinking on some kind of calculation being done using the reported voltage and min/max of that voltage, and with all these together enable a Flight Timer based on battery status. But this is a medium/long shot.

As it is now, the values are absolutely consistent with what can be seen on a normal GCS.

[SukMeWot]

I'd concur with the 100% - technically the second you plug in a battery it is no longer 100% - if you can ever truly say what 100% is. How do you decide what 100% is - is this based on the theoretical maximums of LiPo batteries, if so I'm not aware of any parameter that allows you to set the number of cells. Is it based on the voltage detected when connected? If you plug in a 4S with only 14.5 volts in it will this show 100% - or will it show 86% given that you could have 16.8 volts in a 4s. For these reasons I've never really cared over much about the %age - I watch the volts.

Not sure how to ask and this is probably the wrong place - how does somebody get into all this stuff - I look at things and see the 'A1' etc defined as 8 bit values - not sure where the 16 bit suddenly comes from. I'm trying to understand so that I can maybe bring some value but this is proving to be hard work - OpenTX in itself isn't small and Ardupilot is even bigger.

[chsw]

Personally I think that being able to read values without a lua-script is overrated. But I suppose I have to respect that everybody doesn't want to write a new telemetry screen every time they want to watch special values :)

I actually don't use the battery percentage either. I prefer to watch the current consumption, since I usally know how much is save to draw.

About the bits. It seem like the telemetry protocol transfers 32 bits (actually), but I don't think we can access the raw telemetry values without openTX messing with the values for us.

[lvale]

SukMeWot

At the moment we are only "consuming" what the Flight Controller (via Mavlink) sends out.

Using your example, if you plug that 4S battery with only 14.5V and the Flight Controller sends out a message saying 100%, we just send 100%. If you look at a directly connected GCS either via USB or 3DR Radio link, it will also report 100%....

It's bad I know, and the best way to have it corrected would be having the APM calculating real values based on voltage and current, but......

[SukMeWot]

And this is the sort of thing that bugs the **\ out of me and something I'd like to get involved with and 'rectify' but right now am just trying to figure out where everything is. I've not done code in a very long time but I design and engineer fly by wire and drive by wire systems for real, much the same thing really only my models are somewhat larger and I get to write the specification and make others do the coding ;-)

[lvale]

This conversation got me thinking about what I've submitted for the roll and pitch angles.

Now, I scale the roll and pitch angles from what is received from the Mavlink (radians from +pi to -pi and +pi/2 to -pi/2) to a positive value between 0 and 1024 (A3 and A4 are set to Raw and range to 1024).

Should I convert directly to degrees and send degrees ??

Please note that the Mavlink values are Euler angles, and there are some "issues" around some of the singularities... :)

[SukMeWot]

And this is where my confusion starts - because you can't represent 1024 in 8 bit - 256 is the max.

Eulars are best converted using a matrix, each axis (x,y or z) requires a different calculation but even so it still returns a radian value, do you care about z? we can get that from the compass - unless you want to refer it to the yaw when armed of course.

[lvale]

No need to mess with a matrix here because the APM is already doing it. What is sent is already the results of frame yaw, pitch and roll. There is a discussion on APM regarding Euler vs quaternion if you're interested :) I won't use (for now) the yaw angle, because it does not add value to the limited screen real estate we have available.

Regarding the bit length issue, we are repurposing existing fields that the SPort telemetry sends with data we feel better suits our specific needs, and this can be broken anytime a different OpenTX build is released (It has happened before with the VFAS issue). I have already submitted a request to the OpenTX dev for creating some general purpose generic fields, that we could use without fear of breaking... We do have other "crazy" issues here like Mavlink not sending error codes but full text messages. :)

[chsw]

There were something seriously wrong with the last merge. It merged in complete diffs, so I had to manually try to sort things out. I haven't tested last master.

[chsw]

I've looked some more at transferring the roll/pitch by using A3 and A4, and we will have a bit of a problem. The resolution for these values are also 8bits only (so we are gonna loose precision). And OpenTx does some crazy conversions on its value before using its value. We will only be able to show roll/pitch in steps of 1.4 degrees, but perhaps that's enough for your purpose?

[lvale]

I saw that too, but if my hexa is tilted 2º unless I squint very hard :) I can't see it, and also for the LCD resolution the steps are much coarser than 2º. What do you think?

[chsw]

I'm gonna scale it down to 8 bits and set the offset of a3 and a4 to get the roll/pitch in degres. Why do you want +/- 180 deg roll and only +/- 90 for pitch?

[lvale]

LoL It's not me wanting that, it's what is really being reported by Mavlink :). It got me stomped for some time, but what is reported are the resulting Euler angles. I've asked at the APM dev forum, but if you open the Mavlink debug widget you can see that what is being reported. https://groups.google.com/forum/#!topic/drones-discuss/MSNODQ0cg4U

I didn't test sending negative values on A3 and A4.

[lvale]

btw: Where did you see the conversion being done on OpenTX? I looked, but could not find any conversion when RAW is defined.

[SukMeWot]

I've not found where it is happening yet but if you try to compare an AV value that is raw as part of a logical switch statement you can see its effect. The value that you can use increments or decrements in 'range/256' steps so if you enter a range of 256 = steps of 1, 512 = steps of 2, 768 = steps of 3 and so on so event if you get AV values looking OK on an lua based telemetry display you can't do jack all with them in the TX.

[lvale]

On previous versions of OpenTX there was a 330 ratio on A3 and A4 vs 255 on A1 and A2 https://github.com/opentx/opentx/issues/1555 but the issue was closed

Is that what you're seeing?

[SukMeWot]

A3 and A4 behave the same as A1 and A2 now. My issue with them seems a tad different.

If you want to use the 'A' registers when they are defined as raw the maximum value that you can have as 'range' and retain a resolution of 1's is 256.

If you want to see this first hand open companion, define A1 thro A4 as raw and give each a range which is a multiple of 256. Then try to define an x=a or x>a etc etc and notice the increments allowed for V2 - and you cannot manually enter a number that doesn't equate to a 'range/256' step. If you use the arrows on the V2 box you will clearly see the steps. If you use 1024 for instance the V2 value will increase or decrease in steps of 4.

This behaviour implies that it isn't truly raw - OpenTX is interfering with it in some way - if it was truly treated as 'raw' I should be able to use ANY integer comparison and not be forced into using what it thinks is appropriate.

[lvale]

It’s the 8 bit limit that OpenTx telemetry currently (2.12) has. I believe that is considered to be revised.

On 21/09/2014, at 14:17, SukMeWot notifications@github.com wrote:

A3 and A4 behave the same as A1 and A2 now. My issue with them seems a tad different.

If you want to use the 'A' registers when they are defined as raw the maximum value that you can have as 'range' and retain a resolution of 1's is 256.

If you want to see this first hand open companion, define A1 thro A4 as raw and give each a range which is a multiple of 256. Then try to define an x=a or x>a etc etc and notice the increments allowed for V2 - and you cannot manually enter a number that doesn't equate to a 'range/256' step. If you use the arrows on the V2 box you will clearly see the steps. If you use 1024 for instance the V2 value will increase or decrease in steps of 4.

This behaviour implies that it isn't truly raw - OpenTX is interfering with it in some way - if it was truly treated as 'raw' I should be able to use ANY integer comparison and not be forced into using what it thinks is appropriate.

— Reply to this email directly or view it on GitHub.

[chsw]

It seems like A3 and A4 is (around) 8 bits. And I think it looks like it's actually the other way around. Since 2.0.9 there are some crazy conversions going on with A3 and A4: frskyData.analog[TELEM_ANA_A3].set((SPORT_DATA_U32(packet)*255+165)/330, UNIT_VOLTS);

I have changed the code a little. Firstly I store the roll/pitch values converted to degrees (-180/180). Then I apply a factor to compress it to 8bits, and apply the reverse of the conversions above. To this I set the range of A3 and A4 to 362, with an offset of -180.

With this I seem to get reasonably correct roll/pitch on A3 and A4.

I haven't checked it in yet though.

[lvale]

Hi Christian

watch out the conversion to degrees because of this

https://lh3.googleusercontent.com/-p0iFkKH3mYw/VA3qzdjYivI/AAAAAAAAYXs/BbvKVAyR_bg/s1600/pitch.png

about the 330 conversion on A3 and A4, the one you point isn't only when the value is volts ?

[lvale]

I picked up the hexa and did graph the evolution of yaw, pitch and roll.

Each graph represents a counterclockwise full rotation on each axis, stopping at aprox 0º, 90º, 180º, 270º and back to 0º.

I tried to keep steady, but not easy :) Also tried to align Yaw with magnetic 0º declination so that it would also start at aprox. 0

Yaw Counterclockwise as seen behind the hexa.

Note the change from -Pi to +Pi when rotating from 180 to 270, but this was expected.

Now with roll rotation, similar behavior as yaw previously. Counterclockwise as seen behind the hexa.

Note that on both of these, except for minor shaking of the hexa the only change is from the angle we're measuring.

Now the fun part begins.

Here first, pitch rotation counterclockwise (i.e.) flipping "back" (sorry for the different graph colors but did it after the first round)

and now clockwise

Relevant here is how roll and yaw vary

What I propose, is I'll do all the calculations on the Teensy and only sending on the telemetry Roll and Pitch corrected, because when I first submitted I was thinking of doing it on the script.

[chsw]

I have to admit that this kind of math is something very rusty to me.

I committed a patch which sends pitch/roll as degrees on A3/A4 (with the appropriate setup in my init). It looked kind of right to me, but I think you have a for better understanding of this then me. Feel free to fix it if it's broken :)

[lvale]

Thinking of this, I have the angles on my hexa when flying limited to 30º, but this is for sake of consistency, and I'm sure that those that fly planes would like this :)

[lvale]

LoL Christian

I'm over 50 and didn't "play" with this kind of math for more years that I care to remember....talk about Euler angles and singularities, blah, blah, blah, but it's what Mavlink is sending... LoL

[chsw]

Actually, NOW i have commited my changes :)