Is it possible to use PPMSUM on this board?

as you can see in the nice manual quadframes made it's possible.

Originally Posted by bluelightning

Thanks for your advice. I have used the 5V from the I2C plug because, If I power the AIOP with the USB (during the dev phase) there is no voltage ouput from the S1-S3 plug, so the GPS is not powered by this way.

Attached the successful test with the GPS EM406

Hi yes I know that

The only way to get power to the S1-S3 is if you power via the extended power holes as seen in this picture Then your GPS will have power and that way you dont have to use I2c to power it
( YOU MUST REMOVE THE YELLOW PIN) when powering this way and use a UBEC

Working great so far except ..

The Z acc value calibrates to 256, but reversing the board will give a -780 reading. This is obviously wrong, the calibration value should be 512, not 256. This also makes a very twitchy board at 90 deg angles. Where do i change that?

The baro did knock me off my chair. How is that accuracy possible?

Edit:
i did change in sensors.c, function ACC_init

#if defined(FREEIMUv043)
acc_1G = 512;
#else
#if defined(CRIUS_AIO_PRO_V1)
acc_1G = 512;
#else
acc_1G = 255;
#endif
#endif

Works. Upside reading 512, reversed board reading -530.
But the twitchieness at facing 90 deg up, down or sideways stays. Must be another issue.

Cesco great! I ordered my board today and am looking forward to playing with it soon.

issue with the board at 90°:

if you calculate the angle out of the accelero vector you'll have to use sin/cos at some point.
cos at 90° will be around zero. this very small value will lead to very unusual behavior in the measurement of the angle.

there are possibilities to avoid the cos zero crossing by using cosine direction matrix or quaternions for calculating the orientation, unfortunately our chip will not be able to calculate that in time. so just don't fly at 90° tilt or use heading hold for that.

I think it would be a good idea to have A8 as input for PPM Sum instead of one of the serial ports. Gnd, 5V, A8 is in a row, perfectly lined up to connect my frsky receiver with one standard 3 pin servo cable. No soldering.

btw. I do use a nokia usb cable. The normal mini-usb would not fit.

Hello,
I have just done a successful porting of the ArduPlane v2.4 to the AIOP v1, so it is now called ArduPlaneNG v2.40.
All things are working well...
I have used:
- a Mediatek MT3329 GPS
connected to RX2,TX2 from the S1-S3 plug and powered by the I2C plug (+5Vdc, ground)
- a airspeed sensor MVPX7002DP
connected to A0 from the A0-A5 plug and powered by the I2C plug (+5Vdc, ground)
- a turnigy receiver 9X8Cv2
This has been fully tested with the AP mission planner 1.1.96 mavlink 1.0
soon tested in flight on a Easyglider... Stay tuned...
see photo attached:

Originally Posted by Rober-t

Cesco great! I ordered my board today and am looking forward to playing with it soon.

issue with the board at 90°:

if you calculate the angle out of the accelero vector you'll have to use sin/cos at some point.
cos at 90° will be around zero. this very small value will lead to very unusual behavior in the measurement of the angle.

there are possibilities to avoid the cos zero crossing by using cosine direction matrix or quaternions for calculating the orientation, unfortunately our chip will not be able to calculate that in time. so just don't fly at 90° tilt or use heading hold for that.

So currently the code for MultiWii with AIO Pro given by Quadframes (thanks to him) is not stable ?
still need adjustment ?

Thank you

Orphee, i would not say it's unstable, but it becomes inaccurate around 90° nick or roll in stable mode, as you should use cosine for that calculation. It's a common problem in PID controllers that only use the cartesian coordinate system for describing the current position in space (there is no top or bottom of the copter)

you never fly around 90° in stable mode, common angles go up to maybe 60° and that is already accro-stable :P

there is no way with cartesian coordinates to make it accurate around 90° AND 0° or it's a hack (f.e. resetting the acc vector close to 90° (swapping axes) / using sin on gyro and cos on acc etc.) BUT you'll always have more than one acceleration if you come to 90° inflight, so the 90° will be inaccurate as long as you look at the accelero itself. You'll have to use gyro integral as well and merge it to the acc value etc etc etc

code is good so far, don't worry

This is a mpu6050 chip inside, we fly with it for month without problem with many boards, I have doubt the default code is not correct.
But as AccZ is not used for now in mwc, perhaps that's why nobody corrected it before ?

Just flied the board quickly with default code, default pid, everything looks smooth and leveled.

Just a big bad point here: The micro usb detached from the board when I've plugued it for the 4th time. Bad soldering. And the 2 gnd pad at the side of the usb plug broke at the same time ). Not really solid so be care.

I have to use the ftdi port for now.

i'll be buying a board soon and want to buy a GPS with it, which GPS board have you guys tried and found well worth the money ? Mediatek MT3329 ? or the U-Blox-06 or other ?

Originally Posted by Rober-t

Orphee, i would not say it's unstable, but it becomes inaccurate around 90° nick or roll in stable mode, as you should use cosine for that calculation. It's a common problem in PID controllers that only use the cartesian coordinate system for describing the current position in space (there is no top or bottom of the copter)

you never fly around 90° in stable mode, common angles go up to maybe 60° and that is already accro-stable :P

there is no way with cartesian coordinates to make it accurate around 90° AND 0° or it's a hack (f.e. resetting the acc vector close to 90° (swapping axes) / using sin on gyro and cos on acc etc.) BUT you'll always have more than one acceleration if you come to 90° inflight, so the 90° will be inaccurate as long as you look at the accelero itself. You'll have to use gyro integral as well and merge it to the acc value etc etc etc

code is good so far, don't worry

Ok thank you.
Il will try it with 2.1 RC 964

Just a quick test of Crius pro with mwc 2.1 level model this afternoon, in a strong wind.

This mpu6050 thing is rock stable in all conditions here.

Hunter Vtail 500 - ready to rumble (4 min 41 sec)

Originally Posted by Kipkool

Just a quick test of Crius pro with mwc 2.1 level model this afternoon, in a strong wind.

This mpu6050 thing is rock stable in all conditions here.


http://www.youtube.com/watch?v=bJApP...&feature=g-upl

Nice video & great V tail!

Hey everyone,

I've written up a Howto for the Crius AIO for MultiWii 2.1 on fpvcentral.net - special emphasis on using a u-blox GPS and configuring that for the higher update and baud rates.

@Quadframes, I've credited you for your own tutorial writeup. Feel free to incorporate stuff from my howto if you like!


--> http://fpvcentral.net/2012/07/crius-...ltiwii-part-1/