MultiWii

In the code I've seen that the common function calls after reading ACC and GYRO values are ACC_ORIENTATION(X, Y, Z) and GYRO_ORIENTATION(X, Y, Z).
When adding new sensors (such as an analogous gyro), how should one use these functions? Are the values supposed to be in a specific range/format.
Positive ranging, or +/- values (where 0 typically is leveled/not moving). What's min/max for each parameter??
Or should e.g. gyro values be entered in deg/s and acc values in G or deg?

Not knowing the current format expected, my opinion is having values actually measured (e.g gyro=deg/s and acc=deg) would greatly simplify the effort of adding new sensors, one would always have to convert whatever input is taken from the sensor to a specified format. Or is this conversion assumed to be too time consuming, thus affecting the loop??

Could someone please enlighten me on what range/format is expected by these functions?

Regards
demands

Hi

..._ORIENTATION are macroses designed to be able to change sensors orientation without changing the code. More details you can find in the following threads:
viewtopic.php?f=8&t=262&p=1364&hilit=sensor+address#p1364
viewtopic.php?f=8&t=536
viewtopic.php?f=6&t=426&p=2134&hilit=sensor+address#p2134

gyroADC
- 16bit signed
- Zero point automatically adjusted during calibration
- Measure units deg/sec
- Currently all sensors "aligned" to the
- +-2000 deg/sec range
- 14 bit resolution (which means +2000 deg/sec would be reported as +8192 value)

accADC
- 16bit signed
- Zero point automatically adjusted during calibration (z axis adjusted to the acc_1g)
- Measure units m/sec/sec (or g)
- Currently different sensors have different range and resolution

I hope this is answers your questions

regards,
ziss_dm

Well, it answers some questions, such as values being signed 16bit, i.e. -32767 to +32768.
Calibration is also clear, measuring the zero point through averaging 400 readings (think I saw this in the code somewhere)...
But how can the program account for different ranges and resolution for accADC???
I have an ADXL335 analogous acc, providing 10bit resolution through Arduino ADC...
How can the program know to expect a range between 0 - 1023??
When in another case (e.g. 12 bit ADC) it might be 0-4095...
And if my "not very good" acc doesn't use the full range, should I re-map values into this range??
If range and resolution is different between sensors, it seems they're not very important, and then I don't really see the need for re-mapping into a specific range, though without doing so gives very bad result in MWC...

And in the gyro case, what do you mean by "aligned"??
I have a gyro (again not very good, analogous), 10bit resolution, capable of 300deg/s (amplified) or 1200deg/s.
In this case, should I re-map values into a 14bit resolution?

This confusion (I know, it's probably just me ) is the reason I'd rather have actual values (as for accelerometer, enter values in actual "g"), which is common to all accelerometers (after applicable conversion)...

Hi,

But how can the program account for different ranges and resolution for accADC???

The Attitude estimator uses direction of the gravity vector it does not care about magnitude. The rest of application uses acc_1G as a reference of the resolution.

And if my "not very good" acc doesn't use the full range, should I re-map values into this range??

Better not to. Better just specify correct acc_1G and the rest should be handeled automatically.

If range and resolution is different between sensors, it seems they're not very important, and then I don't really see the need for re-mapping into a specific range, though without doing so gives very bad result in MWC...

This is strange, could you please describe what was wrong?

And in the gyro case, what do you mean by "aligned"??
I have a gyro (again not very good, analogous), 10bit resolution, capable of 300deg/s (amplified) or 1200deg/s.
In this case, should I re-map values into a 14bit resolution?

There are pros and cons..

Mapping to standard res/range
pros:
- Compatible PID values
- No need to change IMU
cons:
- More calculations
- Bigger code size
- Probably hard to archive with int ariphmetic

Leaving as-is
pros:
- Less calculations
- Smaller code size
cons:
- Incompatible PIDs
- You need to re-define GYRO_SCALE in IMU

regards,
ziss_dm

The rest of application uses acc_1G as a reference of the resolution.

Ah, why didn't I think of that, makes sense...

This is strange, could you please describe what was wrong?

Well, I'll try, here it comes:
I'm using a 3v3 sensor (ADXL335) connected to a 5v arduino without AREF, which doesn't give me the full 10bit resolution, but actually range it 0-675 instead of 0-1023. Though, having the correct acc_1G as you stated, this range shouldn't matter (acc_1G is measured in the same way, within the 1-675 range). But when leaving everything without re-mapping, looking at the animations in MWC (pitch and roll), they only turn about 1/5 or something (very little).

This is the exact setup:
Z axis measures 290 (upside down) - 425 (lying flat), which means I set acc_1G to 425.
X/Y measures 250-410 this is the min/max values I'll ever get from the sensor in any direction while holding it still.
This gives the behaviour explained above.

Re-mapping the values to the "full range" 0-675 should do the trick was my thought, but no... It gives animations very close to what i expected, but it's still of by some degress. Though, re-mapping to the full 0-1023, actually gives me animation as expected, it reflects how I turn it. I find this very strange, since the range IS 0-675, acc_1G is also measured within this range, and "0-1023" should have nothing to do with it...

Or, is it simply so, that the animations shouldn't reflect the actual prototype turning?
Oh, and it's a full scale +/- 3g acc, and the original code was ripped from here: viewtopic.php?f=6&t=521
In that thread, you stated ziss_dm, that scaling (re-mapping) the values shouldn't be necessary, though it just doesn't "look" right when we don't...

Hi,

Z axis measures 290 (upside down) - 425 (lying flat), which means I set acc_1G to 425.

not exactly

this means: neutral value (0 G) is (425+290)/2 = 357
acc_1G = (425-290)/2 = 67

Hi,

Z axis measures 290 (upside down) - 425 (lying flat), which means I set acc_1G to 425.

acc_1g= (425 - 290) / 2 = 68

So, after calibration, values in GUI should be :
Z=+68 - flat
Z=-68 - upside down

regards,
ziss_dm

Well ziss_dm and Alex, you're both saying the same thing, so I don't mean to argue, you know this better than I do... I'm just hoping to understand
But I thought, when lying flat (i.e. 0/360 deg, no rotation around either X nor Y), the Z axis experienced 1g, and when upside down (i.e. 180 deg), 0g.
At least that's what's stated on this page (which refers to the sensor I have):
http://bildr.org/2011/04/

How come acc_1G shouldn't be set to which ever value is measured when the sensor is lying flat?
I surely understand the math, but not the logic behind, and I'd be very happy if someone could explain it more in depth (or provide a link, though I thought I'd already read "everything" online ).

And if as you state Alex, 0 G is (425+290)/2 = 357, and 1 G is (425-290)/2 = 67, then what does my measured 290 and 425 actually represent??

Just to make it even more confusing, this page: viewtopic.php?f=6&t=521 where you've been involved ziss_dm, covers the exact same sensor. cob (after some discussion) now uses 426 (measured almost same as mine) as acc_1g, with a comment in his code that it's what's been measured when the sensor is lying flat. Is this wrong then??



Making my head spin, I'll go mow the lawn instead

Hi,

290 - -1g
425 - +1g
-------------
357 - 0g

regards,
ziss_dm

290 - -1g
425 - +1g

Ok, I think I understand it
New day, new brain

Full range from +1g to -1g is 425-290 = 135
To center 0g at 0 in MWC, divide by 2 (=67,5) giving -1g = -67,5 and 1g = 67,5, thus 0g = 0

As I see it, my biggest mistake was assuming 290 represented 0g. Didn't know it was -1g.
Think I've read on to many pages that the Z axis experienced 1g lying flat and 0g upside down.

Now, looking at it, all we do is "move" the range by its average, to center around 0 (290-357,5 = -67,5 and 435-357,5 = +67,5)
I know I'm describing this overexplicitly, but I need it myselft to understand , and maybe it can help someone else in the future.

Thank you very much ziss_dm and Alex, for your time and effort!