GPS: combining flightmode-options

[zwiebacksaege]

Hi guys,

I recently got new hardware (finally!) and made first tests with GPS PH. Now I got some questions about the AUX-options. As far as I was teached I need to set ANGLE, MAG, and GPS PH in order to get the desired result (correct me if I'm wrong). Facing this I asked myself, why isn't all those options activated automatically when activating GPS PH or at least internally enabling all needed features for PH? This would prevent noobs like me from doing mistakes such as only enabling GPS option without ANGLE.

greetings zwiebacksaege

[linuxslate]

zwiebacksaege:

I agree. I went through the same learning curve myself.

I have requested in this post:
viewtopic.php?f=16&t=2611#p36861

...that someone update the Flight Modes page on the Wiki. That would sure help.

Perhaps if you "vote" by posting to that same thread, it will help.

[dramida]

How about a guided GPS PH mode, that means not to temporary deactivate GPS and switch to angle mode but to leave gps PH enableld and modify target GPS point, as altitude vario does for altitude. In this manner it will be more controlable in windy conditions, i guarantee it will be dynamite!
/Mihai from FAE

[zwiebacksaege]

you mean some kind of loiter? isn't it already inplemented in the 2.2 code? i thought so:

Code: Select all

  /************************        AP FlightMode        **********************************/
    /* Temporarily Disables GPS_HOLD_MODE to be able to make it possible to adjust the Hold-position when moving the sticks.*/
    #define AP_MODE 40  // Create a deadspan for GPS.

or is this something else?

@linuxslate: I agree and will vote for it! thx!

[dramida]

you mean some kind of loiter? isn't it already inplemented in the 2.2 code? i thought so:

Code: Select all

  /************************        AP FlightMode        **********************************/
    /* Temporarily Disables GPS_HOLD_MODE to be able to make it possible to adjust the Hold-position when moving the sticks.*/
    #define AP_MODE 40  // Create a deadspan for GPS.

or is this something else?
.......

that standard AP mode does a big bounce when entering in PH mode(until PID correctin kicks in) and when is windy, you really can't control the position of holding. You have to fly it to understand.

A better approach for AP mode will be to increment PH target point according to stick input.

[zwiebacksaege]

okay so I understand right: this AP mode is intended to work as some kind of changing the hold position but in your eyes it's not realized in a good way?
or am I still misunderstanding this line of code?

when I read your last sentense, you mean it would be nice to have the stick input as some kind of change of the hold position without really leaving the hold-mode instead of leaving the hold mode for some time and switching to normal direct flight mode as long as this stick-deadzone is left?
I completely share your opinion. I think they have already implemented a very similar option for the altitude, where you not directly control the throttle while in baro-mode but change the rate of climing in some very limited boundaries through the stick input (I think it was some max of 50cm/s and called ALTHOLD_FAST_THROTTLE_CHANGE beeing disabled)

[zwiebacksaege]

so I guess the lines

Code: Select all

                GPS_hold[LAT] = GPS_coord[LAT];
                GPS_hold[LON] = GPS_coord[LON];

may be just changed to something like

Code: Select all

                GPS_hold[LAT] = GPS_hold[LAT]+increment_rate;
                GPS_hold[LON] = GPS_hold[LON]+increment_rate;

while I am too stupid to make a right expression for <increment_rate> as I don't know in which units the transformation of the coordinates according to the copter heading is made...
just a wild guessing using some information I was able to reverse engineer from the code... guessing some 50cm per loop (?) at full deflection for roll or pitch to change the hold position coordinates..

Code: Select all

//                GPS_hold[LAT] = GPS_coord[LAT];
//                GPS_hold[LON] = GPS_coord[LON];
                GPS_hold[LAT] = GPS_hold[LAT]+50/1.113195*(rcCommand[PITCH]*cos_yaw_x+rcCommand[ROLL]*sin_yaw_y);
                GPS_hold[LON] = GPS_hold[LON]+50/1.113195*(rcCommand[ROLL]*cos_yaw_x+rcCommand[PITCH]*sin_yaw_y);

I see there is most likely some mistakes in signs and even normalizing factors for rcCommand missing but I think now everyone may know what I want to express and maybe someone from the inner circle can help us?

greetings zwiebacksaege

[dramida]

Yes, this is exactly what i was thinking. It will help navigate straight even in lateral winds and when entering in hold mode with stick centered, copter will remain just were you left it.
In addition to changing PH target, it would be better to use gps navigation routine for guiding the copter.
Some times when stick fully deflected, the rate of changing is so high that speed could be 20kmph and target point could be so far away that it needs crsstrack corections

[zwiebacksaege]

as far as I understood the code, the PH is also realized by the same code used for waypoint travelling...
so is no one out there to correct my code idea that I can test it?

[Crashpilot1000]

Nope, that code will not do it. First of all it's not correct in my opinion and secondly you will have to disable normal stickinfluence before the flightcontroller as well, otherwise you will fly both your multiwii and your gps ph pidcontroller. WP and PH are still different codepaths. Look at actual arducopter, or if you want to align it with current multiwii look for arducopter 2.7.X. Another Problem with that PH - Move approach (thats how arm o copter calls it) is, if you loose sats during that, it will (should!) switch back to direct stickinput. I think some people will break their copters by that, because loosing gps (on not good shielded setups) is easier near the ground. A GPS Override is always safer - less surprises.

[zwiebacksaege]

okay thanks for this information... i was not thinking of disabling direct flight controls nor of some unforseen consequences when losing sats.
So maybe just forget about this idea... at least for me

[dramida]

Is any controller which integrates such advanced GPS navi? The closest thing to that was arducopter with Mission planner in guided mode.
If you want to position yourself in FPV mode over a certain area 5x5 meters, this task would be imposible with actual MWC code, especially when wind blows.

[alll]

Hi,
I recently started with GPS PH NAV RTH tuning/flying in calm and very windy conditions.
Tuning is quite hard to understand (3 PIDs) :/

But the idea to be able to "move" the pos hold location "like headfree", via roll/pith input would be really, really nice.

manu

[scrat]

Hi,
I recently started with GPS PH NAV RTH tuning/flying in calm and very windy conditions.
Tuning is quite hard to understand (3 PIDs) :/

But the idea to be able to "move" the pos hold location "like headfree", via roll/pith input would be really, really nice.

manu

Do you mean this with move the pos hold?

/************************ AP FlightMode **********************************/
/* Temporarily Disables GPS_HOLD_MODE to be able to make it possible to adjust the Hold-position when moving the sticks.*/
#define AP_MODE 40 // Create a deadspan for GPS.

[alll]

Reading previous posts, i thought it was not doing exactly what it is supposed to do…

But the idea is to:
“move” current pos hold coordinates, “navigate” to this new point…

[croco]

Hey guys!

I'm working with dramida for this tiny upgrade.

I think I know how to make it work, but since I'm new to MultiWii could you guys tell me the interval of values that "rcCommand[Pitch]" and "rcCommand[Roll]" use ? From what I figured it out, it seems [-3,3], but I want your consent before we try it in a live test.

Thank you !

[EOSBandi]

Hey guys!

I'm working with dramida for this tiny upgrade.

I think I know how to make it work, but since I'm new to MultiWii could you guys tell me the interval of values that "rcCommand[Pitch]" and "rcCommand[Roll]" use ? From what I figured it out, it seems [-3,3], but I want your consent before we try it in a live test.

Thank you !

Read the source :

Code: Select all

static int16_t rcData[RC_CHANS];    // interval [1000;2000]
 
static int16_t rcSerial[8];         // interval [1000;2000] - is rcData coming from MSP 
 
static int16_t rcCommand[4];        // interval [1000;2000] for THROTTLE and [-500;+500] for ROLL/PITCH/YAW  

[alll]

Maybe i get it wrong, or don’t see the complexity behind it.

If you consider a standard gyro PID (rotational velocity PID) to stabilize ROLL/PITCH:

1)Gyro roll/pitch sensor input
2)Rx input
3)PID Error input
4)Mixing (tell how the output should be done to reduce the error)
5)Calc output (based on PID values)

Now I am reasoning for the GPS pos hold (translational “velocity”):

1)GPS x,y input
2)Rx input
3)PID Error input
4)Mixing (tell how the output should be done to reduce the error)
5)Calc output (based on PID values)

Is this not the same? …
So we end up with only 1 PID for the GPS
manu

[EOSBandi]

This is the relevant code from Ardu : it's called loiter_repositioning....

Code: Select all

#if    LOITER_REPOSITIONING == ENABLED   // Robert Lefebvre 16/12/2012
    // switch passthrough to LOITER
    case LOITER:
    case POSITION:
        // This feature allows us to reposition the quad when the user lets
        // go of the sticks


        if((abs(g.rc_2.control_in) + abs(g.rc_1.control_in)) > 100) {
            ap.loiter_override = true;
        }


        // Allow the user to take control temporarily,
        if(ap.loiter_override){
            
            // reset LOITER to current position
            next_WP.lat += LOITER_REPOSITION_RATE * dTnav * ((sin_yaw_y * g.rc_1.control_in) + (cos_yaw_x * g.rc_2.control_in))/4500.0;
            next_WP.lng += LOITER_REPOSITION_RATE * dTnav * ((sin_yaw_y * g.rc_2.control_in) + (cos_yaw_x * g.rc_1.control_in))/4500.0;


            if((abs(g.rc_2.control_in) + abs(g.rc_1.control_in)) < 100) {
                next_WP.lat = current_loc.lat;
                next_WP.lng = current_loc.lng;
                ap.loiter_override  = false;
            }
        }
        wp_control = LOITER_MODE;
        // calculates the desired Roll and Pitch
        update_nav_wp();
        break;  
#else   // LOITER_REPOSITIONING        

[Crashpilot1000]

Why not copy and debug the whole arducopter project and quit that years behind multiwii stuff?
From a time perspective it seems a more reasonable approach.
In my opinion multiwii is dead from many aspects. Perhaps mwii hopes for magic from this https://code.google.com/p/mwc-ng/ .
Unless that happens it is more reasonable to gather up the good parts of multiwii and arducopter and combine it to a fully functional FC - that arducopter simply isn't.
Only my 2 cents. I know this might trigger off some emotions but from a "Mr. Spock" perspective it seems reasonable to me.

Cheers
Kraut Rob

[alll]

Since the subject is GPS i want to share this behavior:

I have a really stable quad, in acro mode i shake it violently and respond immediately to rx commands without "any" overshoot! No wobbling at all! Thanks SimonK
Now, i tuned the 2 GPS PID's and in calm weather (light breeze) the corrections to hold position are "hacked" / not smooth, like it seems to miss some resolution. The correction angle changes are +-2-3 dergrees! The quad keeps its GPS position within 2 meters radius.

Thanks for reading and feedback,
manu

[EOSBandi]

Why not copy and debug the whole arducopter project and quit that years behind multiwii stuff?
From a time perspective it seems a more reasonable approach.
In my opinion multiwii is dead from many aspects. Perhaps mwii hopes for magic from this https://code.google.com/p/mwc-ng/ .
Unless that happens it is more reasonable to gather up the good parts of multiwii and arducopter and combine it to a fully functional FC - that arducopter simply isn't.
Only my 2 cents. I know this might trigger off some emotions but from a "Mr. Spock" perspective it seems reasonable to me.

Cheers
Kraut Rob

Well, somehow I can second to that... if you think that the whole poshold/rth is mostly based on the ardu code.
The 328p based mw is more or less dead... it's quite hard to tune the code any further. So you shouldn't expect more functions, only some polishing.
on the 2560 based boards there are some tought contenders (MegapirateNG, Arducopter, etc.) and since there are no new things under the sun, the functions are going to converge to a common set. On the other hand we reached the computational limits of the 8 bit platform. Yeah it can be optimised and polished more, but for many state of the art methods (RTK, inertial nav..) the platform does not have any horsepower.

Personally, once I finish the waypoint nav code (Which is this time not a copy of arducopter ) i'll move to 32bit platform for my new devs.

[dramida]

good news Mr. Eos.
2 cent ideea:
keep Crius Aiop/328 as sensor interface and use a stm32 for running the main
code.

[Tazzy]

Good to hear that 328p is soon mw history, it have been slow down the mw development for long time now.

// fredde

[timecop]

good news Mr. Eos.
2 cent ideea:
keep Crius Aiop/328 as sensor interface and use a stm32 for running the main
code.

or just let the fucking thing die.

[dramida]

ok, so die beloved Crius, but what all-in-one hardware with 32 bit proc are there? mass produced with a affordable price?