Page 16 of 17

Re: Airplane mode RTH

Posted: Tue Jun 02, 2015 7:22 pm
by Plüschi
Marc's is that with the flight simulator right? No, im too dumb to run that. I have tried.

Mine is simple stupid processing code. First it was a gps nmea simulator, then i added a 1 byte return value from the FC to control heading.
Its NOT sophisticated, but it lets me check some basics functions of the FC code.

I can attach it but you will be disappointed.

Re: Airplane mode RTH

Posted: Tue Jun 02, 2015 8:43 pm
by brm
no, you are showing a simpler approach as i have been thinking off.
;-) nice

Re: Airplane mode RTH

Posted: Wed Jun 03, 2015 10:35 am
by PatrikE
For Waypoints figure one is most desirable.
Keep a line between Wp's.
Image
Some more D to stop the overshoot.
Maybe somewhere( P3, D1)

For RTH Booth pic 1 & 2 is quite ok

Is any modifications needed to MWii code to run this?

Re: Airplane mode RTH

Posted: Wed Jun 03, 2015 5:12 pm
by Plüschi
I think P=3, D=3 is best since its the fastest to put the plane on a straight course to home.

For mwii:
Gpssim sends out NMEA over serial and expects 1 byte singned back. This byte would be GPS_angle[YAW]/20 i guess.
You need to simulate the gps delay (i use 1 second) and maybe yaw momentum in the gpssim.pde getinput() routine. This is not done in the gpssim thing i did post.

Re: Airplane mode RTH

Posted: Thu Jun 04, 2015 6:22 am
by Crashpilot1000
Plüschi wrote:There is the full vector rotation code in baseflight imu. Not the "small angle" approximation, but the real thing.

Using that code we can construct a 3D vector out of GPS bearing and horizontal plane and rotate this into the plane frame (using roll and pitch angles). Then correct the the directional vector (reused EstM) just like acc is used to correct EstG (gravity) vector. This is not possible with MWii's approximation.

I guess this will totally blow mwii's cycle time since the rotation is 900usec on a atmega, but with baseflight and stm32 this should work.


I just tried sinf() approximation code found here: http://lab.polygonal.de/?p=205 . I ended up with this code (see below), that saves compilesize and is 36% faster on stm32 F3. The maximal error I could produce was 0.00109074 (0.06 degree) so not shabby at all. The speedgain maybe higher on atmega? Maybe this can help you.

Code: Select all

// http://lab.polygonal.de/?p=205
// "High precision sine/cosine (~8x faster)"
// Personal measurement of maximal absolute error: 0.00109074 (0.06 degree)
// Personal measured speedgain on stm32 F3: 36% (so not 8 times..)
float sinFAST(float x)
{
    float sin;
    while (x >  3.14159265f) x -= 6.28318531f;                                  // always wrap input angle to -PI..PI
    while (x < -3.14159265f) x += 6.28318531f;
    if (x < 0)   sin  = x * (1.27323954f + 0.405284735f * x);
    else         sin  = x * (1.27323954f - 0.405284735f * x);
    if (sin < 0) sin *= -0.225f * (sin + 1.0f) + 1.0f;
    else         sin *=  0.225f * (sin - 1.0f) + 1.0f;
    return sin;
}

float cosFAST(float x)
{
    return sinFAST(x + 1.57079632f);
}


Cheers Rob

EDIT:
You may also consider these 2 variants of the code (same formula, same low error) if it runs faster / compiles shorter.

This runs 53% faster on stm32 F3

Code: Select all

float sinFAST(float x)
{
    while (x >  3.14159265f) x -= 6.28318531f;               // always wrap input angle to -PI..PI
    while (x < -3.14159265f) x += 6.28318531f;
    float sin = x * (1.27323954f - 0.405284735f * fabsf(x)); // 1.27323954f= 4/pi, 0.405284735f = 4/(pi*pi)
    return 0.225f * (sin * fabsf(sin) - sin) + sin;
}


And this only 52%..

Code: Select all

float sinFAST(float x)
{
    while (x >  3.14159265f) x -= 6.28318531f;               // always wrap input angle to -PI..PI
    while (x < -3.14159265f) x += 6.28318531f;
    float sin = x * (1.27323954f - 0.405284735f * fabsf(x)); // 1.27323954f= 4/pi, 0.405284735f = 4/(pi*pi)
    return sin * (0.225f * (fabsf(sin) - 1.0f) + 1.0f);
}


EDIT EDIT did some Arduino testing and came up with this: viewtopic.php?f=8&t=3989&p=64029#p64029

Re: Airplane mode RTH

Posted: Sat Jun 06, 2015 12:17 pm
by Plüschi
Nice.I have not used the full rotation code yet. Its too warm to do anything useful.

What i found is the originall mwii rotation code is problematic. Running a 20ms cycle as i do the "small angle" code with the approximations used doesent like fast movements. I have seen "strange readings" in flight and on the testbench. Basically mwii code cycle time MUST be low for "small angle" to work properly. I think a rewrite of this code is necessary, same thing baseflight does, and there your approximation comes in handy.

I dont intend doing it for compass direction but for the ACC vector rotation.
My gyro-gps fusion seems to work ok as is ... "seems" because its not tested very good.

Re: Airplane mode RTH

Posted: Sat Jun 06, 2015 3:30 pm
by Crashpilot1000
Hi Plüschie!
If you are unhappy with the small angle approximation loosing track during high speed turns you can optimize the Baseflight rotation for your multiwii.
If you are not turning more than 45 Degree (1/4 Pi) between reads you can use the Chebyshev sin approximation depicted here: http://stackoverflow.com/questions/3450 ... 117#345117 Chebyshev: sin(x) = 0.999f * x - 0.1603f * x * x * x with maximal error around 0,00015 Rad (0,009 Deg). Once you have calculated the sin/cos matrix you can run gravity vector and mag vector in one run through it. I guess that might end up in a couple of hundered microseconds so definitely not free lunch but something to consider if it's solving a problem.


EDIT: This "... more than 45 Degree (1/4 Pi) between..." should have been: "...more than +-45 Degree (+-1/4 Pi) between"...

Re: Airplane mode RTH

Posted: Sat Jun 06, 2015 4:28 pm
by Plüschi
+1 on 0..45 deg. From 0.8 ms down to 0.5ms (about, lots of jitter due to interrupts)
+1 on reuse of matrix

---> mind blown.

Re: Airplane mode RTH

Posted: Sun Jun 07, 2015 12:23 pm
by brm
PatrikE,
could you seperate the navigation stuff from the gps code?
would make the code more readable.
thanks

Re: Airplane mode RTH

Posted: Sun Jun 07, 2015 2:07 pm
by rubadub
what's the status of cruise mode and sticky rth?

Re: Airplane mode RTH

Posted: Sun Jun 07, 2015 4:55 pm
by PatrikE
brm wrote:PatrikE,
could you seperate the navigation stuff from the gps code?
would make the code more readable.
thanks

Since the Navigation is integrated in V2.4 and my hack basicly just uses direction to waypoint and Alt error.
FW code is isolated in a single void.
The rest is just some small tweaks to control the failsafe function.

Navigation code is implemented by EosBandi and the Fixed Wing part is just merged from the old branch i have been running.

You can run some compare program and see what's changed.

/Patrik

Re: Airplane mode RTH

Posted: Sun Jun 07, 2015 4:58 pm
by PatrikE
rubadub wrote:what's the status of cruise mode and sticky rth?


CruiseMode seems to work.
I have only seen a few people who have tested yet.

Sticky rth is not done anything with yet.
Failsafe RTH is Sticky though.
It's only disabled if GPS mode is changed.

Re: Airplane mode RTH

Posted: Sun Jun 07, 2015 8:38 pm
by brm
PatrikE wrote:
brm wrote:PatrikE,
could you seperate the navigation stuff from the gps code?
would make the code more readable.
thanks

Since the Navigation is integrated in V2.4 and my hack basicly just uses direction to waypoint and Alt error.
FW code is isolated in a single void.
The rest is just some small tweaks to control the failsafe function.

Navigation code is implemented by EosBandi and the Fixed Wing part is just merged from the old branch i have been running.

You can run some compare program and see what's changed.

/Patrik


the question is why refactoring the copy.
some rework on the original sources wouöld be better.
need to think ...

Re: Airplane mode RTH

Posted: Mon Jun 08, 2015 6:01 am
by rubadub
quick comment...
I'm wondering if it would make sense to have the GPS modes take precedence & over-ride passthru mode?

I'm thinking that it would always be preferable to have GPS take over and enable PID corrections when in the GPS modes instead of accidentally having it disabled via passthru. I can't think of a case where it would be useful to have passthru be able to disable the modes. I.E., if you've activated either GPS HOME or HOLD, either manually via a switch or through programmable failsafe on an RX, then your intentions should be clear & you shouldn't need to worry about whether or not passthru will get in the way and possibly disable the GPS navigation.

In any case, I'm going to customize my code to skip the passthru mode test (within GPS_NAV()), but I figured that it might be a worthwhile change to make in general. thoughts?

Re: Airplane mode RTH

Posted: Mon Jun 08, 2015 4:29 pm
by PatrikE
Pasthru was a thin i came up with before Nav code.
Just to be able to be able to take over manually.
And to stop the gyros when i carry the model.(I usually walk ~100m to my "field".)

It followed during the tests of RTH.
And saved the model more than once when a certain idiot had made some "improvements" in the code.
But i guess now it's not needed in GPS modes any more.


In Multiwii.cpp you can add f.GPS_mode as a condition for f.PASSTHRU_MODE

Code: Select all

    #if (defined(FIXEDWING) || defined(HELICOPTER))
      if (rcOptions[BOXPASSTHRU] && !f.FS_MODE  && f.GPS_mode != GPS_MODE_NONE)) {f.PASSTHRU_MODE = 1;}
      else {f.PASSTHRU_MODE = 0;}
    #endif

Then you will have Pasthu in normal flight modes but not in GPS modes.

Or simply leave Passthru un checked in the Gui.

Re: Airplane mode RTH

Posted: Tue Jun 09, 2015 12:35 am
by rubadub
PatrikE wrote:Pasthru was a thin i came up with before Nav code.
Just to be able to be able to take over manually.
And to stop the gyros when i carry the model.(I usually walk ~100m to my "field".)

It followed during the tests of RTH.
And saved the model more than once when a certain idiot had made some "improvements" in the code.
But i guess now it's not needed in GPS modes any more.


In Multiwii.cpp you can add f.GPS_mode as a condition for f.PASSTHRU_MODE

Code: Select all

    #if (defined(FIXEDWING) || defined(HELICOPTER))
      if (rcOptions[BOXPASSTHRU] && !f.FS_MODE  && f.GPS_mode != GPS_MODE_NONE)) {f.PASSTHRU_MODE = 1;}
      else {f.PASSTHRU_MODE = 0;}
    #endif

Then you will have Pasthu in normal flight modes but not in GPS modes.

Or simply leave Passthru un checked in the Gui.


cool,
not sure if you meant this though

Code: Select all

 && f.GPS_mode == GPS_MODE_NONE

so that it only allows passthru when in GPS_MODE_NONE, correct?

What I did was this:

Code: Select all

if (rcOptions[BOXPASSTHRU] && !f.FAILSAFE_RTH_ENABLE  &&  !f.GPS_HOME_MODE && !f.GPS_HOLD_MODE) {f.PASSTHRU_MODE = 1;}

although I wasn't aware of that GPS_MODE_NONE constant, much simpler to do it that way. :)

EDIT:
nevermind, I just realized that GPS_MODE_NONE isn't available in 2.3, so I guess I'll just stick with my above test.

Re: Airplane mode RTH

Posted: Tue Jun 09, 2015 2:44 am
by PatrikE
In V2.3 you can use
nav_mode == NAV_MODE_NONE

Or why not update to V2.4 FixedWing With Waypoints?

Re: Airplane mode RTH

Posted: Wed Jun 17, 2015 12:14 pm
by ardufriki
Hi Patrik,

I have a Crius SE, I2C NAV card and GPS. All of this has been working fine in quadcopter. Now I want to use all of this to setup an airplane with estabilization and RTH (for now).

I have flashed the the I2C NAV with 2.2 patched version, but the only think I get is quick flashing of the I2CNAV led, just when I connect the GPS to it. Is the GPS unit autoconfigurable (like 2.4 MW main branch) or have I to program it? Or may be a simple config.h missconfiguration? Thx.

Re: Airplane mode RTH

Posted: Wed Jun 17, 2015 2:38 pm
by PatrikE
I think your Config.h is wrong.
The settings is 115200 and NMEA in the config.(My debug setup)
You need to adjust it to your GPS.

You need to set correct baudrate and protocol.
#define INIT_MTK_GPS Should be able to autoconfigure your GPS like settings in config file.

Re: Airplane mode RTH

Posted: Wed Jun 17, 2015 2:56 pm
by Plüschi
I think mwii on a 328 is only cabable of two 50hz servo signals and the rest is software pwm generated. Is that right? How bad is jitter on soft-pwm servo?

It is possible use 8 bit timers to generate 50hz servo signals by having the 8-bit timer2 to generate the 1 to 2ms pulse, and the 16-bit timer generate the 18ms pause in-between. This will give us 4 good jitter free 50hz pwm channels on a 328.

It is also possible to use 8-bit timer0 to generate 2 additional channels in the same way. Downside ie micros(), millis() and delay() wont work any more, but they are easy to substitute with functions using timer1. This will give us 6 good jitter free 50hz pwm channels on a 328.

Next is LoopTime. It doesent make any sense to run 2ms looptime if servo update is 20ms. Except ... IMU small angle approximation. So if we kill "small angle approximation" by doing the full rotation we can do 20ms looptime and get better results. We can also fire some of the cryptic optimizations because 20ms is enough to do it all in float.

Another aspect is the big firmware size due to overly messy gps functions. Size can be reduced significantly here.

In other words, i think for airplanes a rewrite of the mwii frame makes sense. Size goes down below 20k doing this.

Re: Airplane mode RTH

Posted: Wed Jun 17, 2015 3:09 pm
by PatrikE
The PWM generating code is over my level!..
But i don't experience jitter on my planes.
And i agree the loop time is way overkill for a plane!

For the Gps functions.
I have "disabled" a lot of "Not needed" code to fit it in a 328.
A plane can fly with a much simpler GPS code.

Question is if Airplane should be fully merged for a MWii V2.5 or if it should be split to a separate branch.
So far i have been following the MWii branch and synced the code.

Re: Airplane mode RTH

Posted: Wed Jun 17, 2015 5:58 pm
by brm
to a certain extend a lower looptime is fine to fight gyro drift.
normally a plane is longer in the air as a copter ;-)

Re: Airplane mode RTH

Posted: Wed Jun 17, 2015 7:54 pm
by Plüschi
brm wrote:lower looptime is fine to fight gyro drift


Setting a low LPF in the gyro should perfectly compensate this.
20hz lpf + Improving the gyro readout accuracy by factor 4 + no "small angle approx" should give a 20ms system a good edge over actual mwii.
Only guessing, only partially tested.

brm wrote:a plane is longer in the air as a copter ;-)

We use acc to compensate roll/pich gyro drift. And gps or mag to compensate yaw drift. So this is no issue.

More rants:
Supressing the acc complementary filter on acc > 1.3g or acc < 0.7 G like donr in mwii is totally wrong and results in a skewed acc vector. Immagine a copter accelerating at 1.4G and breaking at 1.2G afterwards.

Re: Airplane mode RTH

Posted: Thu Jun 18, 2015 12:17 am
by rubadub
question/feature request:

Is there a way to save wing trims (center points) while in flight via an AUX channel?
example: switch to passthru mode, trim plane's control surfaces, level the plane out, hit an AUX switch to save the values, switch back to gyro mode, land, and either adjust the control surfaces mechanically or make note of & stick with the saved trim values.

The reason I'd like to do this in flight:
I have flying wing that flies great in gyro but that I find very difficult, almost impossible, to fly in passthru. It's very unstable, rocks side to side a lot, perhaps due to wind or being very untrimmed? I'm not sure. Anyway, I can manage to fly in passthru & trim it for a little while, but it would be risky to continue to fly & try to land it while in passthru. If I trim in passthru and then switch back to gyro, the large trim values will cause the plane to pull hard in the direction of the trims & thus also cause instability.

What I believe would be ideal is to be able to quickly trim in-flight by switching to passthru, trimming the plane, save the trims via an AUX switch, and then switch back to gyro, having the servo center values be immediately reflected in gyro mode.

I understand that this is currently available for 'in-flight acc calibration', but doesn't appear to be available for servo trims. My apologies if what I'm asking for already exists. If not, can we work on getting something like this implemented?

Re: Airplane mode RTH

Posted: Thu Jun 18, 2015 2:49 am
by PatrikE
It's very unstable, rocks side to side a lot, perhaps due to wind or being very untrimmed?
That's usually a sign of wrong CG..(Tail heavy)

In the latest fw_Nav version i have added a field trim function.
It only works via stick command by calibrating gyro inverted on the ground.
And that means you will have to land the plane...
https://multiwii.googlecode.com/svn/bra ... 150431.zip
Search for "SERVO_FIELD_TRIM" in sensors.cpp

/**** SERVO_FIELD_TRIM ****
Center servos with trims.
With Plane Inverted in Passthru & Disarmed.
Calib gyro with sticks release sticks quickly
Make sure Elevator stay in Max position.
Remove TX trims when servos return to center again...
Ready to fly...*/


I guess it should be possible to do the same in Air.
But with a AUX switch.
Could maybe modify the in-flight acc calibration switch.

Re: Airplane mode RTH

Posted: Thu Jun 18, 2015 8:44 am
by rubadub
PatrikE wrote:
It's very unstable, rocks side to side a lot, perhaps due to wind or being very untrimmed?
That's usually a sign of wrong CG..(Tail heavy)


hmm, ok, thanks I'll look into it.
I'm pretty sure that the CG is where it should be, have checked it a bunch of times.
The wings are balanced, but they are "heavy" as I've got my RX/GPS out on the edge of one wing, and my VTX on the opposite edge, so perhaps this causes issues even though the wing is technically "balanced" when placed on a stand.

PatrikE wrote:In the latest fw_Nav version i have added a field trim function.
It only works via stick command by calibrating gyro inverted on the ground.
And that means you will have to land the plane...
https://multiwii.googlecode.com/svn/bra ... 150431.zip
Search for "SERVO_FIELD_TRIM" in sensors.cpp

/**** SERVO_FIELD_TRIM ****
Center servos with trims.
With Plane Inverted in Passthru & Disarmed.
Calib gyro with sticks release sticks quickly
Make sure Elevator stay in Max position.
Remove TX trims when servos return to center again...
Ready to fly...*/


I guess it should be possible to do the same in Air.
But with a AUX switch.
Could maybe modify the in-flight acc calibration switch.


ok, sounds cool.
In the meantime, I already went ahead and started working on a patch based on the in-flight acc calibration stuff. I've got it compiled, just need to test it, hopefully within a couple of days.

Re: Airplane mode RTH

Posted: Thu Jun 18, 2015 5:13 pm
by brm
Plüschi wrote:
brm wrote:lower looptime is fine to fight gyro drift


Setting a low LPF in the gyro should perfectly compensate this.
20hz lpf + Improving the gyro readout accuracy by factor 4 + no "small angle approx" should give a 20ms system a good edge over actual mwii.
Only guessing, only partially tested.

brm wrote:a plane is longer in the air as a copter ;-)

We use acc to compensate roll/pich gyro drift. And gps or mag to compensate yaw drift. So this is no issue.

More rants:
Supressing the acc complementary filter on acc > 1.3g or acc < 0.7 G like donr in mwii is totally wrong and results in a skewed acc vector. Immagine a copter accelerating at 1.4G and breaking at 1.2G afterwards.


btw. more rants: looks like you didn't got it.

antialiasing it not solvable with just using a lpf filter.
as a rule of thumb to reduce noise is simple:
when you need the data at 20ms then sample it at 10 times the rate you need, thus: 2ms.

at the upper and lower boundary you cannot trust these mems devices.
go up to 8G or 16G and increase the values above accordingly.
is this understandable?

and btw. when the gyro saturates you get easily 20% error ...

Re: Airplane mode RTH

Posted: Thu Jun 18, 2015 11:54 pm
by Plüschi
brm wrote:is this understandable?


Did i piss you off somehow? Sorry you feel this way, wasnt my intention.

I think we should move that discussion to another thread, and not hijack patricks plane thread.

Re: Airplane mode RTH

Posted: Fri Jun 19, 2015 7:17 pm
by ardufriki
PatrikE wrote:I think your Config.h is wrong.
The settings is 115200 and NMEA in the config.(My debug setup)
You need to adjust it to your GPS.

You need to set correct baudrate and protocol.
#define INIT_MTK_GPS Should be able to autoconfigure your GPS like settings in config file.


Hi again. It works now, with ublox and 115200 setup. I get the i2cnav board flashing when GPS has 3D fix.

BUT, now I have i2C errors and no connection through the i2c port. I have checked the config.h and I see the 0x20 address for the i2cnav board. I have swapped the SDA and SCL wires, but no luck. I would like to debug the problem, but I dont know what to check. I have tried PULL RESISTORS on and off, 400KHz and 100kHZ... :(

Re: Airplane mode RTH

Posted: Fri Jun 19, 2015 9:32 pm
by PatrikE
I did a quick test..
With a diy I2C_GSP module and a diy FC.

I had no problem connecting it without I2C errors.

First i had errors but then i saw i had a Crius AIO defined and i only used a MPU6050 on the testFC...
After i changed it no more errors.

You can test it against stock V2.3 or 2.4 to ensure your I2C communicates correct.
Good luck

Re: Airplane mode RTH

Posted: Sat Jun 20, 2015 4:35 pm
by brm
Plüschi wrote:
brm wrote:is this understandable?


Did i piss you off somehow? Sorry you feel this way, wasnt my intention.

I think we should move that discussion to another thread, and not hijack patricks plane thread.


thanks.
to a certain extend there is a techie touch when discussing problems.
if it's not too much then i hope it is ok to stay within this thread.

Re: Airplane mode RTH

Posted: Sun Jun 21, 2015 7:41 am
by Plüschi
Hi Robert,

>need the data at 20ms then sample it at 10 times the rate you need, thus: 2ms.

I think the internal sensor LPF (6050 and 3200 devices) does exactly what you describe, read out at a fast rate and average the stuff. If this numerical LPF is inside the 6050 or outside in the 328 doesent matter, its the same functionality. Must be a simple FIR filter with all coeffs 1 (also called averaging). This is good enough for antialiasing. Or maybe the 6050 does use individual FIR coeffs (a thing the 328 would struggle to do), i dont know.

>at the upper and lower boundary you cannot trust these mems devices.
>go up to 8G or 16G and increase the values above accordingly.

I agree an 8G (or 5G) cutout would make more sense, and i state again the current 1.3G limit is not good for nothing. Agree?

I have the impression this G limit and the "small angle approx" is the cause of a skewed acc vector after some sharp maneuvers.

Re: Airplane mode RTH

Posted: Sun Jun 21, 2015 6:12 pm
by brm
for antialiasing i prefer higher datarates.

the slow recovery after sharp maneuvers mainly has to do with the lowpass filtering.
i would replace all low pass filters by a pt1 elements.

will be interesting to do some testing with such a setup.

Re: Airplane mode RTH

Posted: Mon Jun 22, 2015 7:55 am
by ardufriki
PatrikE wrote:I did a quick test..
With a diy I2C_GSP module and a diy FC.

I had no problem connecting it without I2C errors.

First i had errors but then i saw i had a Crius AIO defined and i only used a MPU6050 on the testFC...
After i changed it no more errors.

You can test it against stock V2.3 or 2.4 to ensure your I2C communicates correct.
Good luck


It works now. It was a problem when flashing of the I2C NAV board. I have it configured with #define UBLOX and works fine. Thx Patrik.!!

Re: Airplane mode RTH

Posted: Mon Jun 22, 2015 10:03 am
by ardufriki
Hi, I want to configure the airplane (this is my first one, so I have many newbie questions :lol: ):

- If I activate "passthrough" mode, is it the same as if I had no FC?

- I would like to experiment with my transmitter (er9x), with the expo rates, limits of the servos, mixes and so on. So I would like to inject two separate channels for the ailerons. Is that possible in multiwii?

- If I use 5 channels for motor and servos, I still have other 3 for passthrough, RTH and PosHold. Is that a good setup?

Re: Airplane mode RTH

Posted: Mon Jun 22, 2015 2:28 pm
by PatrikE
Passthrough Uses no sensors only the input from TX.
You get a small delay on the controls and FC is just doing the mixing based on TX.

In the current mixtable it's not possible.
You will have to modify it for separate inputs.
One thing to take in consideration is The Pid's only have one output/Axis.

Roll, Elevator, Throttle and Rudder is affected by Passthru.

5+3 should work fine.

Re: Airplane mode RTH

Posted: Tue Jun 23, 2015 8:15 am
by ardufriki
So if I understand well, could I setup like this?:

- 4 channels to control the plane (so it is not possible two separate channels for ailerons). RUDDER, THROTTLE, ELEV & AILERONS. I have to invert or not them in the GUI.
- 1 three position switch (1 channel) to select PASSTHROUGH, ANGLE or HORIZON.
- 2 channels more to select GPSHOLD and RTH.
- As I use PPM input from my openlrsng rx I cant inject more than 8 channels to multiwii (sync problems), but as I stiil have another channel free, could I use it to inject RSSI into the FC? (in order to not use a RC filter).

Re: Airplane mode RTH

Posted: Tue Jun 23, 2015 9:03 am
by PatrikE
Sounds like a good setup.
The 3Way sw i usually set.
PassThru|Acro|Horizon.
If you have a second 3Way you can set GPSHOLD and RTH on it.
But separate switches works fine if you have channels for it.

You can inject RSSI as channel 8 or 9 to mwii.
But increase from the synctime to >= 27µs to avoid the sync problem.(in Olrs gui)

Actually you can send 12ch if your TX supports it.

Re: Airplane mode RTH

Posted: Tue Jun 23, 2015 1:30 pm
by ardufriki
Ok, I will test with 8ch for now.

In config.h like this ?

Code: Select all

  /********************************************************************/
  /****                             RSSI                           ****/
  /********************************************************************/
    //#define RX_RSSI
    //#define RX_RSSI_PIN A3
    #define RX_RSSI_CHAN 8   //RSSI injection on selected channel (for PPM, Olrs, SBUS, etc.) (Starts at 0)


and in chrome configurator for openlrsng : "inject RSSI on servo channel : 8" ???

But I am confused, because of "(starts at 0)" indication. Should I define 12 channels instead?

Re: Airplane mode RTH

Posted: Tue Jun 23, 2015 1:46 pm
by PatrikE
ardufriki wrote:Ok, I will test with 8ch for now.

In config.h like this ?

Code: Select all

  /********************************************************************/
  /****                             RSSI                           ****/
  /********************************************************************/
    //#define RX_RSSI
    //#define RX_RSSI_PIN A3
    #define RX_RSSI_CHAN 8   //RSSI injection on selected channel (for PPM, Olrs, SBUS, etc.) (Starts at 0)


and in chrome configurator for openlrsng : "inject RSSI on servo channel : 8" ???

But I am confused, because of "(starts at 0)" indication. Should I define 12 channels instead?

"(starts at 0)" means 0,1,2,3,4......
#define RX_RSSI_CHAN 8 = RC-channel 9 or AUX5
I guess you should set
#define RX_RSSI_CHAN 7
or
#define RX_RSSI_CHAN AUX4 // Will work just as fine.

Re: Airplane mode RTH

Posted: Wed Jun 24, 2015 7:14 am
by ardufriki
Hi Patrik, now it works !! Many thanks. ;) In the GUI I can see how AUX4 channel changes value when switching off the transmitter. Good. Still to assign AUX4-->RSSI in MW, but it will work for sure.

I had many many problems yesterday with sync of the PPM stream. Sometimes all the channels got blocked or their values were changing. When I went to disarm some servos went to weird positions and the motor went to 45% power !!!. Bad things. :shock: :shock:

This was happening until I modified the limits of the channels in the transmitter. From 100 to 90 in the 7 channels (one free in the transmitter for RSSI because I guess it is generated in the rx), and then no more issues with that.

Last year I had similar problems when trying to use 12ch instead of 8 channels. Finally it works with 8 in my quadcopter.

I am scared with the PPM sync problem, but it seems it is solved now for this new project.

My future flying projects will be with 32bits. May be sync problems are solved there.....

Re: Airplane mode RTH

Posted: Wed Jun 24, 2015 8:16 am
by PatrikE
ardufriki wrote:I had many many problems yesterday with sync of the PPM stream. Sometimes all the channels got blocked or their values were changing. When I went to disarm some servos went to weird positions and the motor went to 45% power !!!. Bad things. :shock: :shock:

This was happening until I modified the limits of the channels in the transmitter. From 100 to 90 in the 7 channels (one free in the transmitter for RSSI because I guess it is generated in the rx), and then no more issues with that.
My future flying projects will be with 32bits. May be sync problems are solved there.....


I guess your Yaw channel triggered Failsafe threshold when you disarmed!..
Ensure that the first four channels don't go below 1000 in lower position like you did by reducing it to 90%..
The AUX channels don't affect the Failsafe at all.

I've been flying with FrSky PPM since i started with MWii and have never had any problem with the sync on 8 channels.
Even without the 27µs update on RX.

Re: Airplane mode RTH

Posted: Wed Jun 24, 2015 8:33 am
by ardufriki
PatrikE wrote:
I guess your Yaw channel triggered Failsafe threshold when you disarmed!..
Ensure that the first four channels don't go below 1000 in lower position like you did by reducing it to 90%..
The AUX channels don't affect the Failsafe at all.


I have been reading about this issue and you are right. The higher values can confuse the PPM stream, BUT the lower values can trigger Failsafe !! I will test again to ensure of that.

Im getting closer to my maiden flight :D.

Re: Airplane mode RTH

Posted: Tue Jun 30, 2015 11:06 am
by rubadub
@PatrikE,
I want to patch my 2.3 version with your CRUISE mode code.
where can I take a look at it?

Also, I was wondering what your opinions are of running an i2c GPS setup.
I have an ATMega328 i2c GPS module that I got a long time ago & that I've never found a use for. Now, I'm wondering if it might be something worth throwing on my skysurfer. Anyway, just wondering if you think those i2c GPS modules can be of any good use on a plane?

Re: Airplane mode RTH

Posted: Tue Jun 30, 2015 2:29 pm
by PatrikE
I2C is practical if you want to connect a OSD.
But use my patched version.

You can fond the Cruise code in gps.c.
Search for GEO

Re: Airplane mode RTH

Posted: Wed Jul 01, 2015 10:58 pm
by rubadub
thanks Patrik, I'll take a look.

I was wondering if it would be possible to setup something like an auto-launch/auto-climb mode, where the plane will level off & climb at a steady rate, maintain heading, and basically go into 'cruise' mode once the plane reaches some specified altitude. As soon as the user is ready to assume control, the 'CLIMB/LAUNCH' mode can be disabled. Throttle would be controlled by the FC, but the user would need to set the throttle above a minimum threshold in addition to enabling it via an AUX switch.

I think something like this could be very useful for hand and bunjee launches on FPV flights; you could toss the plane and allow it to safely climb while you get settled (put your goggles on, sit in your chair, etc.). Although I'm not sure if it could be done effectively & easily. What are your thoughts?

Re: Airplane mode RTH

Posted: Wed Jul 01, 2015 11:02 pm
by PatrikE
Try to enable RTH When you lauch.
It will climb out and start cirkling over your head intill you take over.

Re: Airplane mode RTH

Posted: Mon Jul 06, 2015 9:23 am
by ardufriki
Hi all,

I have added i2C-GPS to my setup and can report some tests (CRIUS SE board).

I have installed the i2Cboard and ublox GPS and tested the GPSHOME, GPSHOLD and CRUISE capabilities. Not FPV yet, so I dont have many telemetry data to report.

- When I select RTH (AUX switch) the throttle suddenly goes full throttle (or close to this), but inmediatly slows and rises again. All the time in a cyclic behaviour, until it reach a very high altitude (I think it is not 50m as I should expect) and the full throttle decreases, but the cyclic throttle thing remains. Then the plane circles over my head as espected (that is amazing).

- The GPSHOME box switches on and off although I have 9 sats or more. I can see it at bench tests. I think this is directly related to the throttle issue.

- The GPSHOLD haves similar behaviuor.

- CRUISE control seems to have a constant throttle (not intensely tested)

Re: Airplane mode RTH

Posted: Mon Jul 06, 2015 10:13 am
by PatrikE
That sounds strange!..
" The GPSHOME box switches on and off "
It indicates there's something wrong with the FIX. ( >= 5 sat )
At climbout the Motor should be at Max until hold altitude is reached.
In all other GPS situations it should hold Cruise throttle and increase/decrease slowly depending on speed and Alt error.

Maybe it can be something with the New I2C handling in MWii i have not tested it my self just checked on the bench.
I'm a bit occupied atm and can't test anything.

Re: Airplane mode RTH

Posted: Mon Jul 06, 2015 10:32 am
by ardufriki
I think the problem is as you said (FIX sats >=5) because in WinGUI I see the green FIX box blinking (but I have 9+ sats !!).

I dont know if the problem is in the i2c board, the GPS itself, the code, or the cables (will test). May be the quicker is to code a 2 seconds "filter" for the GPS input, or something like that, but it seems a bad solution.