GPS NAV

[Leo]

Translated with Google: "if Fence radius is < Safe wP distance would have to abort mission ???????"

[Leo]

I had some fun testing various items like NAV settings and quality of my FPV hardware:



Leo

[Rob]

Nice test Leo..... Looks good....

[Leo]

Thank you.

I'll be using this route for further test. However I've added 5 meters to the altitude as the QC was a bit too low for my taste particularly flying from WP5 to WP6

At WP5 the QC seemed to be confused for a second....

[shikra]

Leo - Not sure if its of interest, but MWOSD has some support for displaying waypoint info...

from about 20 secs in can see example

[Leo]

When I'm happy with everything and all is working fine on my QC then my next project will be to install MWOSD

[ezio]

I had some fun testing various items like NAV settings and quality of my FPV hardware:



Leo

Do you have a log file from this flight? If yes could you send me it ?
contact@ez-gui.com

Bart

[Leo]

Bart, I had very bad 3DR reception. The data is almost useless.

However if you can wait and the weather is good tomorrow then I will do the same flight again and will use a longer rod so the antenna is higher of the ground.

[Leon11t]

Have a one technical question. Can NAV version take a mission correction inflight? Or this is imposible? Where stored a mission data?

[ezio]

Have a one technical question. Can NAV version take a mission correction inflight? Or this is imposible? Where stored a mission data?

Unfortunately not possible

[Leon11t]

Mission data stored in EEPROM?
I nead mission correction in flaight. Is there possible to implement this function?

[ezio]

Mission data stored in EEPROM?
I nead mission correction in flaight. Is there possible to implement this function?

Yes mission is stored in eeprom. So modifying it may/will cause glitches.
In my opinion mission should be stored in eeprom then copy to RAM while arming and if the FC is armed FC should allow to modify waypoints in RAM only.

Bart

[Leo]

This evening I did 2 identical flights that used the exact same navigation route with some interesting observations. I should have the video up tomorrow evening.

I also made some pictures during the flights. I think this one is cool:



@Bart: I will have 2 flight logs ready for you

Leo

[Leo]

Here a video I put together showing 2 identical navigation missions flown 15 minutes apart.

I have made comments in the video where I thought there are some anomalies (nothing serious)

I do would like to know what the causes could have been. Maybe small glitches in the nav code?

Enjoy



Leo

[Leo]

I've been doing more or less tests to see that mission navigation is working properly.

I did change baro calculation from float to integer on this flight in preparation for optimizations in smoothing out the readings. I will continue when 2.4 is officially out.




Am I the only one flying missions? I almost get the feeling that I'm talking to myself!

Leo

[stronnag]

I think a year ago it was new and exciting; now we're patiently waiting for a formal release. Very little has changed in user visible performance in that time, although there have been significant changes to the code base generally.

[Leo]

So I'm enjoying the leftovers from the party a year ago? OK... I can deal with that

[EOSBandi]

Not really a leftovers....
I think MultiWii has reached it's final form, there will be one more formal release but that will be the final one... the exciting things are happening on 32bit platforms, for example Cleanflight....

Regarding to the anomaly, it is hard to tell without telemetry or onboard log...

[Rob]

I've been doing more or less tests to see that mission navigation is working properly.

I did change baro calculation from float to integer on this flight in preparation for optimizations in smoothing out the readings. I will continue when 2.4 is officially out.




Am I the only one flying missions? I almost get the feeling that I'm talking to myself!

Leo

No! You not talking to yourself, Please go on it are interesting experiments....

Thanks,


Rob

[joebob85]

Proabably a dumb question - I am attempting GPS nav with my QC, however i cant seem to figure out if these flights shows are full uav or first person controlled. Does WinGUI 2.3 support full uav? Can i just upload my route, then flip a switch a have it "start" the defined WP route? any info is appreciated!

Matt

[EOSBandi]

Proabably a dumb question - I am attempting GPS nav with my QC, however i cant seem to figure out if these flights shows are full uav or first person controlled. Does WinGUI 2.3 support full uav? Can i just upload my route, then flip a switch a have it "start" the defined WP route? any info is appreciated!

Matt

Nope, no auto takeoff for safety reasons... you have to take off manually, then you can flip a switch to fly your route then land automatically.

[GUSHELFER]

I've been doing more or less tests to see that mission navigation is working properly.

I did change baro calculation from float to integer on this flight in preparation for optimizations in smoothing out the readings. I will continue when 2.4 is officially out.




Am I the only one flying missions? I almost get the feeling that I'm talking to myself!

Leo

We 're two in the world !!!!!!!!! , plug an play this doing much damage ...
http://youtu.be/rUiQSQIuibg

[shikra]

I do a bit, but its not that exciting and too busy to edit up...

from 1:40 onwards for normal speed

[Leo]

That's great guys. Good to see I'm not the only one

[marcdornan]

Not really a leftovers....
I think MultiWii has reached it's final form, there will be one more formal release but that will be the final one... the exciting things are happening on 32bit platforms, for example Cleanflight....

Regarding to the anomaly, it is hard to tell without telemetry or onboard log...

EOSBandi - are you going to be lending your considerable talents to the Cleanflight project? Is anyone currently working on waypoint navigation for that? Is your work portable to 32 bit?

[EOSBandi]

Not really a leftovers....
I think MultiWii has reached it's final form, there will be one more formal release but that will be the final one... the exciting things are happening on 32bit platforms, for example Cleanflight....

Regarding to the anomaly, it is hard to tell without telemetry or onboard log...

EOSBandi - are you going to be lending your considerable talents to the Cleanflight project? Is anyone currently working on waypoint navigation for that? Is your work portable to 32 bit?

Eventually, it is possible. If my time permits.... the navigation code is quite simple to port, just like other parts of multiwii...

[elf128]

Hi EOSBandi,

Sorry for jumping into conversation in a such way, I have to abmit, I didn't have enough courage to read all 19 pages, so maybe I'm dubling someones question.

Currently, navigation is tailored specifically for multirotors and doesn't work with fixed wings or hybrids. I was trying to piggyback on your code outside of GPS.cpp but I've got to conclusion that this is bad idea. Mostly because correction of heading using back&yank has delay and lead to heading oscillations. ( No surprises so far ).
So, here is my question. Do you think it would be better to refactor GPS_calc_nav_rate and GPS_calc_poshold to support flying wing but that mean I'll introduce heading dependency and extra unnecessary complexity or it would be better to make an external PID controller for heading in wing-mode and add simple passthrough mode to GPS_calc_nav_rate and GPS_calc_poshold when they will just pass targerSpeed into nav[] without PID to avoid double PID.
The question is more about following merging I case if this part will be functional.

Thanks.

[Leo]

Here a video I put together showing 2 identical navigation missions flown 15 minutes apart.

I have made comments in the video where I thought there are some anomalies (nothing serious)

I do would like to know what the causes could have been. Maybe small glitches in the nav code?

Enjoy



Leo

Here are the log files of both flights if anyone wants to take a look at what might have been the causes of the anomalies as seen in the video: http://www.leo.nutz.de/images/helicopters/forums/MultiWiiLog_Leo.zip

Comments are welcomed.

[EOSBandi]

Hi EOSBandi,

Sorry for jumping into conversation in a such way, I have to abmit, I didn't have enough courage to read all 19 pages, so maybe I'm dubling someones question.

Currently, navigation is tailored specifically for multirotors and doesn't work with fixed wings or hybrids. I was trying to piggyback on your code outside of GPS.cpp but I've got to conclusion that this is bad idea. Mostly because correction of heading using back&yank has delay and lead to heading oscillations. ( No surprises so far ).
So, here is my question. Do you think it would be better to refactor GPS_calc_nav_rate and GPS_calc_poshold to support flying wing but that mean I'll introduce heading dependency and extra unnecessary complexity or it would be better to make an external PID controller for heading in wing-mode and add simple passthrough mode to GPS_calc_nav_rate and GPS_calc_poshold when they will just pass targerSpeed into nav[] without PID to avoid double PID.
The question is more about following merging I case if this part will be functional.

Thanks.

There is a fixed wing navigation fork of the MultiWii... waypoint navigation is recently ported into that tree.. check the code repository....

[PatrikE]

Info here:
http://fotoflygarn.blogspot.com/2012/03 ... -same.html
http://fotoflygarn.blogspot.com/2014/04 ... plane.html

code here:
https://code.google.com/p/multiwii/sour ... ingNav_Dev

The forum thread: (only 14 pages... )
viewtopic.php?f=7&t=2456

[elf128]

There is a fixed wing navigation fork of the MultiWii... waypoint navigation is recently ported into that tree.. check the code repository....

I've realised that GPS_Compute is living in a different time frame and syncronius to GPS frames, not main loop. So, he's an answer.
Does the change you're talking about is integrated into Shared branch or it somewhere else? Anyway, thank's for the tip, I'll take a look.

Correction. Found comment from PatrikE. Thanks!

[elf128]

Info here:
http://fotoflygarn.blogspot.com/2012/03 ... -same.html
http://fotoflygarn.blogspot.com/2014/04 ... plane.html

code here:
https://code.google.com/p/multiwii/sour ... ingNav_Dev

The forum thread: (only 14 pages... )
viewtopic.php?f=7&t=2456

OMG, What a hack. Everything is packed into one function.

[PatrikE]

Feel free to improve.
It would be nice with fresh eyes on the code.
It's easy to be blind after a while.

[elf128]

Feel free to improve.
It would be nice with fresh eyes on the code.
It's easy to be blind after a while.

Thank you for being open.
I think there should be three independent parts of airplane control. Altitude control, Heading Control and Speed Control. Navigation suppose to feed values to all those modules, but they should be independent. Actually, Alt and Speed hold are usefull even without GPS for training purposes.

I've done implementation of AltHold for horizontal flight inside generic AltHold cycle, so it doesn't depend from GPS and you can switch baro without GPS and use it in the same way as for Multirotor. And it's working out of the box, cause Nav is simply supplying AltHold values to the system and most of the stuff are done by EOSBandi already. It does use the same PID values, so you don't have to patch GUI for PC and tablet.
For Heading, I'm doing it the same way as you're, but using numbers from YAW PID for tuning ( kinda hack, but I don't want to introduce new variables ).
For Speed. There is rudimental Velocity PID in MultyWii. I don't know where it come from, but it's exposed every were in GUI, so I'm pretty much doing implementation of it right beside AltHold.

BTW, should we go to another topic with this stuff?

[PatrikE]

The goal was from beginning to have a working Failsafe and RTH for Planes.
Using only a MPU 6050 and GPS for a really poormans setup.
And to avoid Magnetic interference etc as bonus.
It works satisfying now with the current code.

Split up like you say could be a good improvement.

We can use the old thread for fixedwing GPS.
viewtopic.php?f=7&t=2456

Or we can create a new clean thread for this.

[PatrikE]

Mission data stored in EEPROM?
I nead mission correction in flaight. Is there possible to implement this function?

Yes mission is stored in eeprom. So modifying it may/will cause glitches.
In my opinion mission should be stored in eeprom then copy to RAM while arming and if the FC is armed FC should allow to modify waypoints in RAM only.

Bart

Wouldn't it work to simply set a save to Eeprom flag and save when it's Not armed?
Then it's possible to change mission inflight and keep it in RAM while Armed.

[cassiusfxg]

I not found in the site nav firmware b7 . Can someone please pass ?

[Leo]

I not found in the site nav firmware b7 . Can someone please pass ?

http://eosbandi.com/downloads/

[cassiusfxg]

I not found in the site nav firmware b7 . Can someone please pass ?

http://eosbandi.com/downloads/

Thanks, but the site can only download the wingui B7 .
the firmware of this board not available.

[ezio]

I not found in the site nav firmware b7 . Can someone please pass ?

http://eosbandi.com/downloads/

Thanks, but the site can only download the wingui B7 .
the firmware of this board not available.

You don't need b7 firmware anymore. Use MultiWii 2.4 - it has the same functionality.

[Leo]

I not found in the site nav firmware b7 . Can someone please pass ?

http://eosbandi.com/downloads/

Thanks, but the site can only download the wingui B7 .
the firmware of this board not available.

Ooops...

Here is what you are looking for : https://code.google.com/p/mw-wingui/downloads/list

[cassiusfxg]

Ooops...

Here is what you are looking for : https://code.google.com/p/mw-wingui/downloads/list

Yes, but this is the baro B5. I do not know if it works without bugs. I wanted a newer version. I am unsure. I am a beginner and still use the 2.1 version.

[Trakker]

Hi,

I bought this multiwii for my second quadcopter --> http://www.hobbyking.com/hobbyking/stor ... _Port.html
I got it working (MW 2.2 + I2C NAV module + Ublox neo 6) with help of V2 from this page: http://www.rcgroups.com/forums/showthread.php?t=1724694. (Neo 6 resets it's settings after few hours, also u-center show ublox 5... not ublox 6. Never know what you get from ebay ). I would like to get some kind of gps waypoint combination working. I read this thread and got confused. If I understood right, MW2.4 is not going to work with my 328p multiwii but there might be some way to get the waypoints working with MW2.3? If so, could someone provide me couple steps how try this. (Just need the right direction).

Also should I consider better or newer multiwii FC to get best of my quads?

Thank you!

[Crashpilot1000]

Hi EOSBandi!

I have done some testing on faster sinus and cosinus functions on Arduino like outlined here: viewtopic.php?f=7&t=2456&start=750#p64003. I will paste a link to this post here as well, just in case someone will stumble about it in a year or so.

Naturally you have to deal with those functions so you might want to look into this. I fired up my rusty arduino pro mini and ran some benches and got an speed increase of 25%. The compilesize is probably lower as well (haven't checked that but is on stm32 when all sin/cos functions substituted).
The algorithm has an maximal, absolute error of 0.0010907 Rad = 0.062 Degree (own measurements across the range in 0.001 deg steps). The arduino "abs" function is a speedbrake (cost: 5% speed) that can be released by this:

Code: Select all

float abs_flt(float x)
{
    uint32_t i = (*(uint32_t*) &x) & 0x7FFFFFFF;
    return *(float*) &i;
}


Farting around with "union" and just masking a byte with 0x7F doesn't make it faster from my testing. So that code is already "inlined"/ implemented in the speed-winner version.
This is the fastest version (-25%) for Arduino I could puzzle together (without a sinus - table):

Code: Select all

float sinFAST(float x) // MUST BE IN RANGE OF -PI ... +PI
{
    uint32_t absconv = (*(uint32_t*) &x) & 0x7FFFFFFF;
    float absresult = *(float*) &absconv;
    float result = x * (1.27323954f - 0.405284735f * absresult); // 1.27323954f= 4/pi, 0.405284735f = 4/(pi*pi)
    absconv = (*(uint32_t*) &result) & 0x7FFFFFFF;
    absresult = *(float*) &absconv;
    return 0.225f * (result * absresult - result) + result;
}

float cosFAST(float x)
{
    x += 1.57079632f;
    if (x >  3.14159265f) x -= 6.28318531f;
    return sinFAST(x);
}


The more bulletproof version that doesn't require the input to be in the range of -Pi..+Pi is only 22% faster:

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;
    uint32_t absconv = (*(uint32_t*) &x) & 0x7FFFFFFF;
    float absresult = *(float*) &absconv;
    float result = x * (1.27323954f - 0.405284735f * absresult); // 1.27323954f= 4/pi, 0.405284735f = 4/(pi*pi)
    absconv = (*(uint32_t*) &result) & 0x7FFFFFFF;
    absresult = *(float*) &absconv;
    return 0.225f * (result * absresult - result) + result;
}

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


Further reference can be found here: http://lab.polygonal.de/?p=205 and http://forum.devmaster.net/t/fast-and-a ... osine/9648.
Cheers Rob

[elf128]

Hmmm, that's kinda old topic.
It has been proved long time ago, that usage of tables for implementation of sin/cos on Atmel is bad idea from ether memory or performance perspective. Sure it's faster than straight floating point implementation, but it's way slower than fixed point polinomial aproximation. Due to the fact, that those floats are pretty much everywhere in the code, nobody have been tried to remove them, but If the one thinking of global code refactoring I would suggest getting rid of all floating point operations for drastic performance boost.

[Crashpilot1000]

@ elf128: Yes, definitely and if my aunt had balls she would be my uncle.

[brm]

oh yeah, sometimes i have memory and sometimes i just overclock the mcu to gain the speed momentum.
and yes - i have an aunt with 4 horse shoes and ... she is bitchy.

[mbeerer]

I got to test out the GPS features of multwii for the first time today. So far so good, but I had one question that I couldn't find anywhere in the forums. During RTH (with MAG enabled) my tricopter seems to fly towards home at about a 45 degree angle off centerline. It definitely responds differently to the MAG on/off as expected, but I can't figure out why it wouldn't turn directly towards home. If does fly directly home as expected. If my MAG signal was bad, I would think it wouldn't work at all.

I'm using the RTF multiwii pro v3 black FC in a standard set up with the mag positioned away from power cables.

Any thoughts from the experts would be greatly appreciated.

[vtpete]

Hi Guys,
Forgive me if I have the wrong thread, or if this topic is already covered. I've been reading the pages to find the answer to this, but, well...

I'm using WinGUI and the 2.4 code with my Quadrino controller. I have waypoints working nicely and I've looked at the source code to figure out how most of it works. But, does anyone know how WinGUI is determining "10" as the maximum number of commands? I see from the code a nice function for determining the maximum number of waypoints (max 255), but don't know how to get WinGUI to use more than 10. (I have a gut feeling that 10 is determined somewhere I just haven't found yet.)

-Pete

[ravid824]

Hi EOSBandi,
Can you please help.
What is the reason that all of the Navigation settings in MultiWiiWinGUI 2.3> flight tuning are grayed?
I also can't upload any mission.
I am running Multiwii 2.4 firmware on Crius AIO V2.
The GPS functions well and recognize 9 satellites while it is set 38400, it is important to set it to any specific rate, such as 115200?
Can you estimate any other reasons?

Thanks.