Page 1 of 20

GPS NAV

Posted: Fri Aug 30, 2013 10:20 pm
by EOSBandi
Hi All !

The time has come, so I'm releasing the navigation code for MultiWii. I would call it first public beta. It was flight tested several times, and I flown dozens of missions with it, plus a couple hundred simulated ones. BUT as we know all program contains at least one cycle, one branch and one error.

I rely on the community (as usual) to test it and find out the possible bugs. Currently the capabilities of the mission editor and the navigation engine is somehow limited if we compare it to other UAV software. The reason for it is that I would like to build a solid foundation what can be extended. We all know what happens when developers started to pursue new features instead of making existing ones to work. (ArduCopter anyone ?)
I got lot's of feedbacks and recommendations and many of them are very valuable, eventually they will make it into the code, but first make is solid.

This version works with AtMega2560 based board and serial GPS. (Ublox or MTK19 is recommended). Please make sure that your copter is well tuned, ANGLE mode, MAG and BARO works correctly. Navigation relies on these functions.

Three components are released today.
WinGUI 2.3pre4 - Contains the mission editor
MultiWII 2.3-navi-b1 - MultiWii 2.3 software extended with navigation capabilities
SiK-mW 2.3 - A customized firmware for 3DR radio telemetry modules to use with MultiWii.

LATES VERSION AVAILABLE from http://eosbandi.com/downloads

Here is the initial draft for the user guide, I hope it's enough to get started, but do not hesitate to ask.
HAPPY FLYING !
(And if you like it and willing to donate (so I can buy new gadgets) don't forget to click on the donate button at http://code.google.com/p/mw-wingui/ )

Changes is WinGUI2.3pre4 and MultiWii 2.3-navi-b1

The serial communication is now not happening in bursts. Queries are sent in timeslots. This allows effective use of half duplex communication channels and avoid flooding of the link.
TABS are reorganized to support telemetry connections (sensor graph moved to a separated tab)
FLIGHT DECK
- New gauges added to the Flight Deck tab (Vertical speed and Altitude)
- Sent and received packet counts are displayed and telemetry link quality is calculated from these values.
- If telemetry uses 3dr radios with Sik-mw 2.3 firmware, radio link RSSI and Noise figures are also displayed
- BIND Spektrum button now available
- Default refresh rate is now 5Hz (can go to 10Hz with direct link)
FLIGHT TUNING
- Contains all common parameters (PID’s EXPO’s)
FC Config
- Contains additional parameters (Servo config, Mag Decl. etc.)
- Magnetic delineation can be entered in degree-minutes format
MISSION TAB
On the mission tab, you can see your copters actual position on the satellite map at the left, and the list of the mission steps on the right.
At the left bottom you can get information of the navigation engine. GPSMODE is the current nav mode determined by the RCOptions. NAV_STATE is the current state of the navigation engine.

To create a mission, you have to put down mission steps on the map, you can do it by shift+left click on the desired position. Mission steps are added to le list automatically.

At this moment you can use five type of steps. (I call them steps, but in fact these are commands that tells the copter what to do.)

The first and most widely used command is a waypoint command. This tells the copter to go to a specified location and altitude. The next step is executed once the copter reached the desired position. The copter will not wait for reaching the desired altitude, it will continue the mission once the waypoint is reached.

When you shift+left click on the map the newly created step always will be a waypoint. You can edit it later by changing the drop down selection in the action field.

The second type of command is a timed poshold. This is just like the waypoint command tells the copter to go to a specified location AND wait there for a given amount of time. The next step is executed after the given time elapsed.

The third type of command is called the unlimited poshold. It commands the copter to go to a location and stay there. This command ends the mission.

The fourth type of command is the Return to Home. This also means the end of the mission. The RTH altitude is controlled by defines in the config.h, the altitude setting in the RTH step is not used.

The fifth type of command is a JUMP command. With this we can create loops in the mission. There are two parameters for JUMP command. A mission step number to jump to, and the number of repeats. The -1 value of the number of repeats means infinite loop.

There are two restrictions with the JUMP command, first for safety reasons you can jump only backwards (step number is less than the JUMP command) not forward, and second you cannot create nested loops.

Once you created you mission, you can save it to a file, or upload to the flight controller. For your and your copters safety it is recommended to download your mission from the FC after you uploaded it, to make sure that it is correctly uploaded.

If you want use WinGUI on the field without internet connection, you can cache satellite map images for a given region. To do that, zoom out to show your planned flight zone, then with ALT+left click mark the area you want to cache, then click on the FETCH MAP button. The satellite images for all zoom level are cached to the disk and available offline.

Go to Click function
It is possible to control your copter via the GUI directly. First enable the GoToClick (GtC) function by clicking the button on the left bottom of the MISSION tab. When GtC is enabled, the button turns RED.
When your copter is in positon hold (GSPMODE : PosHold, NAV_STATE: Poshold infinit) if you right click on the map, a temporary waypoint is created and the copter will navigate there. If the “Send GtC alt” checkbox is selected then the altitude in the GtC altitude box is sent to the copter along with the new position.

When the copter started to navigate to the GtC location you cannot set new location until it reaches the previous one. If you want to cancel GtC before the location is reached, simply disable PosHold momentarily.

Executing a mission
When your mission is successfully uploaded and checked, you can start it by switching ON the MISSION rcOption. It is your responsibility to enable ANGLE, MAG and BARO too.

An ongoing mission can be aborted by disabling the MISSION rcOption or enable RTH rcOption.
Switching GPSHOLD rcOption ON during a mission pauses it. Mission will continue when GPSHOLD is switched off (MISSION must be ON).

Navigation parameters in Config.h

GPS_WP_RADIUS
If we are closer than this distance to a waypoint, then it considered as reached. (in centimeters)
SAFE_WP_DISTANCE
This defines the maximum distance in meters that can be flown by the copter between to waypoints. If a Waypoint is farer than this, the mission will be aborted and copter switched to GPSHOLD. This also true for the distance between the home position and the first waypoint, so your copter will not go away if your mission programmed for a different location.
MAX_NAV_ALTITUDE
This defines the maximum allowed altitude what can be reached during navigation. If a waypoint sets altitude above this limit then navigation will ignore it and uses the defined value (in meters)
NAV_SPEED_MIN, NAV_SPEED_MAX, NAV_SLOW_NAV
These parameters governs the copters speed during navigation. MAX is the maximum speed that the copter can reach. MIN is the minimum speed to slow down to when approaching waypoint. When SLOW_NAV is true then the SPEED_MIN is ignored and copter slows down as much as possible when approaching waypoint (it allows to reduce speed to zero). The unit is cm/sec for both SPEED parameter
CROSSTRACK_GAIN
It controls the how the weight of the crosstrack error in the navigation calculations. (Do not touch it, unless you understands the navigation code)
NAV_BANK_MAX
It limits the maximum banking that navigation control gives to the copter. (unit 100=1deg)
RTH_ALTITUDE
It defines the RTH altitude in meters, it is 0 it means that no current altitude will be kept.
WAIT_FOR_RTH_ALT
If it 1 copter will hold position until it reaches RTH altitude then start coming home. If it 0 copter will start coming home as soon as RTH is engaged.

Re: GPS NAV

Posted: Sat Aug 31, 2013 6:31 am
by e_lm_70
Good job

Will you also update the MultiWii gui ?

Re: GPS NAV

Posted: Sat Aug 31, 2013 1:13 pm
by Mis
EOS, my five cents...
1. Instead of additional MISSION BOX maybe you can use existing boxes ? Simply turn on both HOLD and HOME boxes in the same time start the mission.
2. Parametr altitude should be signed for allow flying to points below take-off altitude.

Re: GPS NAV

Posted: Mon Sep 02, 2013 9:12 am
by Hamburger
while you are at it, could you please have a look at the gps_status?
I found it reporting 'status ok', even with a serial speed mismatch of gps and the gps port. Very misleading. What I would like to see is an indicator for various gps states like
- hardware detected
- serial connection established
- some meaningful data received
- successfull fix at least once (gps home position reasonably set)
- last values provide position info yes/no

Re: GPS NAV

Posted: Mon Sep 02, 2013 8:39 pm
by EOSBandi
e_lm_70 wrote:Good job

Will you also update the MultiWii gui ?


Yes

Re: GPS NAV

Posted: Mon Sep 02, 2013 8:40 pm
by EOSBandi
Mis wrote:EOS, my five cents...
1. Instead of additional MISSION BOX maybe you can use existing boxes ? Simply turn on both HOLD and HOME boxes in the same time start the mission.
2. Parametr altitude should be signed for allow flying to points below take-off altitude.


1. NOPE, this wont allow the unconditional prioritization of HOLD and RTH over NAV.
2. True, thanks for noting

Re: GPS NAV

Posted: Mon Sep 02, 2013 8:41 pm
by EOSBandi
Hamburger wrote:while you are at it, could you please have a look at the gps_status?
I found it reporting 'status ok', even with a serial speed mismatch of gps and the gps port. Very misleading. What I would like to see is an indicator for various gps states like
- hardware detected
- serial connection established
- some meaningful data received
- successfull fix at least once (gps home position reasonably set)
- last values provide position info yes/no


OK, I'll take a look. The GPS parsing code needs a rehaul anyway.

Re: GPS NAV

Posted: Tue Sep 03, 2013 6:13 am
by fryefryefrye
EOSBandi wrote:
OK, I'll take a look. The GPS parsing code needs a rehaul anyway.


The GPS_STATE will still keep OK while the GPS is disconnected.

Re: GPS NAV

Posted: Wed Sep 04, 2013 9:30 pm
by ezio
Can't wait to see this finished so I can implement it in my app.
Good work.

Re: GPS NAV

Posted: Fri Sep 06, 2013 8:12 pm
by brm
ezio wrote:Can't wait to see this finished so I can implement it in my app.
Good work.

will be interesting - for sure

Re: GPS NAV

Posted: Thu Oct 03, 2013 8:20 pm
by rbirdie001
Hi eosbandi,
I know you probably have lot of work with preparing GPS navigation code but if once you have chance, can you please look at compatibility I2C GPS code with upcoming MW 2.3 ? There seems to be some troubles (at least I have it :( ) so if you could tune it a little to work well, it would be great! Here is my post about it: viewtopic.php?f=8&t=4077&start=60#p41872
Thanks!
Roman

Re: GPS NAV

Posted: Fri Oct 04, 2013 12:03 am
by timecop
I hope I2C GPS is killed with 2.3 so people move on and stop wasting time with trying to "navigate" on "promini".
ffs, its 16mhz with like 16k flash and 1k ram. give UP.

Re: GPS NAV

Posted: Fri Oct 04, 2013 7:17 am
by rbirdie001
timecop wrote:I hope I2C GPS is killed with 2.3 so people move on and stop wasting time with trying to "navigate" on "promini".
ffs, its 16mhz with like 16k flash and 1k ram. give UP.

Hi!
But what about people who don't want to navigate through waypoints? I want only fly and have Poshold / Return to home for safety reasons. I have bought several boards with 328 so why I should throw them away and buy something big and expensive when it's once solved with I2C GPS and until now it worked well...
Not all people have the same needs and this is magic of this project that is wide enough for all of us ;) .
Roman

Re: GPS NAV

Posted: Fri Oct 04, 2013 9:21 am
by ttcorse
The truth is that ported to C + + has been hurt and does not work, not even to me that I have a CRIUS aio.
I use the 2.2 for now and until the EOS does not put his hand to the code will not use the new relase.

Re: GPS NAV

Posted: Fri Oct 04, 2013 12:31 pm
by shikra
timecop wrote:I hope I2C GPS is killed with 2.3 so people move on and stop wasting time with trying to "navigate" on "promini".
ffs, its 16mhz with like 16k flash and 1k ram. give UP.


You realise its only like this because we know how much it annoys you :D

Re: GPS NAV

Posted: Fri Oct 04, 2013 8:58 pm
by scanman
my opinion on including waypoints in the main multiwii code is: instead of cluttering up the main code base, it should be a separate development, on a separate board, like EOS Bandi's I2C board or similar. I believe that the MSP is mature enough to support and encourage "add-on" developments for secondary functions, a bit like the various OSD options out there.

I think waypoint navigation is going to add a lot of complexity, especially into the GUI, the programming effort is going to kill other development. Then people are going to want geo-tagging of images, dynamic waypoint altering during flight, OSD waypoint information, and the list goes on.

Generally, in my observations of many different software systems , rather than try and "do everything" It is better to keep a tight core of code and encourage others to build their own systems that compliment it and work with it, by providing them with powerful API's or interfacing opportunities through things like MSP and the i2c bus.

encouraging waypoint navigation as a separate add-on development could be the start of many other similar developments with multiwii as a core.

just my 2 cents.

Re: GPS NAV

Posted: Sat Oct 05, 2013 1:53 pm
by ezio
scanman wrote:my opinion on including waypoints in the main multiwii code is: instead of cluttering up the main code base, it should be a separate development, on a separate board, like EOS Bandi's I2C board or similar. I believe that the MSP is mature enough to support and encourage "add-on" developments for secondary functions, a bit like the various OSD options out there.

I think waypoint navigation is going to add a lot of complexity, especially into the GUI, the programming effort is going to kill other development. Then people are going to want geo-tagging of images, dynamic waypoint altering during flight, OSD waypoint information, and the list goes on.

Generally, in my observations of many different software systems , rather than try and "do everything" It is better to keep a tight core of code and encourage others to build their own systems that compliment it and work with it, by providing them with powerful API's or interfacing opportunities through things like MSP and the i2c bus.

encouraging waypoint navigation as a separate add-on development could be the start of many other similar developments with multiwii as a core.

just my 2 cents.

+1

Re: GPS NAV

Posted: Sat Oct 05, 2013 5:24 pm
by U.Sentenza
ezio wrote:
scanman wrote:my opinion on including waypoints in the main multiwii code is: instead of cluttering up the main code base, it should be a separate development, on a separate board, like EOS Bandi's I2C board or similar. I believe that the MSP is mature enough to support and encourage "add-on" developments for secondary functions, a bit like the various OSD options out there.

I think waypoint navigation is going to add a lot of complexity, especially into the GUI, the programming effort is going to kill other development. Then people are going to want geo-tagging of images, dynamic waypoint altering during flight, OSD waypoint information, and the list goes on.

Generally, in my observations of many different software systems , rather than try and "do everything" It is better to keep a tight core of code and encourage others to build their own systems that compliment it and work with it, by providing them with powerful API's or interfacing opportunities through things like MSP and the i2c bus.

encouraging waypoint navigation as a separate add-on development could be the start of many other similar developments with multiwii as a core.

just my 2 cents.

+1

+1

Re: GPS NAV

Posted: Sat Oct 05, 2013 8:47 pm
by ttcorse
-1

Re: GPS NAV

Posted: Sun Oct 06, 2013 9:52 am
by Crashpilot1000
Well basically I2C GPS is not such a bad idea on Arduino because you can offload the main FC with the GPS cycles and even do more complex calculations that are not possible on a single Arduino handling FC and gps (like a precise bearing/heading calculation). The bytesize can be greatly reduced (IF thats a problem at all) by using the mwii serial routines instead of that arduino default serial call. Having said that there are also several downsides with an external unit on I2C. I completely understand why nobody is so keen on pushing that external solution ahead.... because it's a pain...

Re: GPS NAV

Posted: Sun Oct 06, 2013 1:50 pm
by rbirdie001
Hi guys,
sorry, I didn't want to make "war zone" of this practically oriented thread. I wrote my post for much more practical reasons: I have 3 different multicopters with 328 based flight controllers. They are flying great with MW 2.2 and are using I2C GPS to full satisfaction (THANKS eosbandi!). I don't need more so I don't wat to rebuild them for mega boards, but I like some improvements in coming MW 2.3 so I'd like use it in future. I found serious problems in communication between MW 2.3 and I2C GPS so I asked in 2.3 forum if someone can correct it (I can't code). Alex wrote, that we have to wait for eosbandi so I tried to notice him about that problem. And THAT'S ALL FOLKS! ;)
Thanks for understanding!
Roman

Re: GPS NAV

Posted: Sun Oct 06, 2013 3:08 pm
by scanman
yes sorry, i didnt want a war zone either, just a suggestion. The work done so far by EVERYONE on this forum is actually fantastic, something really special.
Also, I meant to say some serial device , rather than the I2C board, but a similar concept: using some other board, however over serial port. The MSP serial protocol is really great, its slimline, simple and does the job, my suggestion is to offload as much as possible onto some other board which communicates over MSP (not I2C!! - sorry my mistake!)

Re: GPS NAV

Posted: Mon Oct 07, 2013 8:54 pm
by EOSBandi
Quick note..... (I'm traveling in the US so no time to develop till end of Oct)...I2CGps_nav will be discontinued by me. There will be one update to 2.3 including all patches and recommendations. But it will not include waypoint nav. If anyone willing to take over it is the time. But it puts unneccessary complexity to the nav code and only good for providing profit for sellers who monetize the MultiWii platform via selling outdated 328p boards.
I' also interested that is there anyone who uses tinyGPS and GPSfromOSD ? It seems quite abandoned and sometimes buggy. I recommend to drop it from the main codebase.

Re: GPS NAV

Posted: Thu Oct 10, 2013 10:47 am
by dramida
I agree with Mr. EosBandi, good point in discontinuing old hardware which take time to debug and add unwanted hardware and software complexity.
Also i have a I2C navi board, i never used it after introduction of Atmega328 serial port sharing between GUI and GPS. And then AIOP with 2560 proc came widely available :)

Allow me to delight you with a multiwii cinematic fpv flight. Thank you all for making this possible with multiwii (AIOP board).


Re: GPS NAV

Posted: Thu Oct 10, 2013 10:18 pm
by rbirdie001
Hi dramida,
I have to do small "lobbing" for 328p boards and I2C GPS (at least with current functionality). As I wrote many times (because there were even voices wanting to discontinue 328p processor), these small and cheap boards are great for beginners and hobyists (not for professionals like you, dramida ;) ). I have three these and I'm satisfied with them. I use also I2C GPS modules, because (the only) serial port I need for (GREAT!) Minim OSD.
I never asked for waypoint navigation in I2C GPS module so it won't be big shame for me if it won't be implemented there, but it's great safety support when you can "park" or "call home" your multicopter when you need it. So to say it clearly - please keep 328p boards supported and if possible also I2C GPS at least for some time and at least with current functionality.
I like new features in 2.3 and don't want to be "cut off" and remain forever on 2.2 but also don't want to throw away all my boards just now :( .
Thanks!
Roman

Re: GPS NAV

Posted: Fri Oct 18, 2013 1:27 pm
by e_lm_70
timecop wrote:I hope I2C GPS is killed with 2.3 so people move on and stop wasting time with trying to "navigate" on "promini".
ffs, its 16mhz with like 16k flash and 1k ram. give UP.


Lovely TimeCop style ... LOL

ProMini is 32kb flash, and 2k ram the common 328 based ProMini ... yes 168 is dead since long time and no more supported.

:ugeek:

ps: navigation with 328 is possible ... eve without i2c stuff ... it is not possible to make it nice and clean and dummy proof ... but for quick and dirty hacked solution it is very easy to be done ...

Re: GPS NAV

Posted: Fri Oct 18, 2013 1:30 pm
by e_lm_70
EOSBandi wrote:Quick note..... (I'm traveling in the US so no time to develop till end of Oct)...I2CGps_nav will be discontinued by me. There will be one update to 2.3 including all patches and recommendations. But it will not include waypoint nav. If anyone willing to take over it is the time. But it puts unneccessary complexity to the nav code and only good for providing profit for sellers who monetize the MultiWii platform via selling outdated 328p boards.
I' also interested that is there anyone who uses tinyGPS and GPSfromOSD ? It seems quite abandoned and sometimes buggy. I recommend to drop it from the main codebase.


Take your time ... and yes, Navigation it is better suited with a atmega pro board. So, it is correct to get more freedom and make something nice and clean.

Anyhow ... don't rush your Navigation implementation ... I like to keep my exclusivity of Multiwii Does UAV : http://youtu.be/FO98kWumnHI

Re: GPS NAV

Posted: Wed Oct 30, 2013 12:59 am
by doughboy
e_lm_70 wrote:
timecop wrote:I hope I2C GPS is killed with 2.3 so people move on and stop wasting time with trying to "navigate" on "promini".
ffs, its 16mhz with like 16k flash and 1k ram. give UP.


Lovely TimeCop style ... LOL

ProMini is 32kb flash, and 2k ram the common 328 based ProMini ... yes 168 is dead since long time and no more supported.

:ugeek:

ps: navigation with 328 is possible ... eve without i2c stuff ... it is not possible to make it nice and clean and dummy proof ... but for quick and dirty hacked solution it is very easy to be done ...



the genius is the ability of the developers to jam in as much multiwii code into the 328. I respect the 328 based mw developers for that. It takes a lot of skill to be able to do that. not just any programmer can do it.
I got almost all features enabled and it still only use 25kb program space.

I just recently started using the i2c_gps_nav with a little change so I ask to not drop this feature from mw code.

I know it sucks to develop something and have someone make money out of it. I just developed an arduino based aquarium controller and I got contacted by someone from China planning to manufacture it. I have not heard back. He is probably just going to do it anyway, at least he's got the courtesy to ask. This is true for people in US also. I have posted circuits in DIY message forums and see others take advantage and make money out of it. US offenders are worse, they don't even give credit to where they stole the idea from. At least the Chinese mentions where it came from.

Re: GPS NAV

Posted: Wed Oct 30, 2013 9:49 am
by Hamburger
Tinygps is gone in pre v2.3 now. (since r1585)

Re: GPS NAV

Posted: Wed Oct 30, 2013 11:24 am
by haydent
i just switched to ublox from MTK, much better ! more satelites quicker and smoother nav

Re: GPS NAV

Posted: Thu Nov 14, 2013 5:59 pm
by EOSBandi
Hi !
Now I have time... so roadmap is the following :
1. Make WinGUI 2.3 ready (almost done) and finish WP upload code
2. Merge MW2.3 release into navi-dev codebase
3. Finish WP uploading code
4. Simulation tests
5. Flight tests

It shouldn't take more than 2 weeks.

You can follow (and/or test) here :
http://code.google.com/p/mw-wingui/
http://code.google.com/p/multiwii-navi-dev/

I'll post regular updates in this forum.

Re: GPS NAV

Posted: Thu Nov 14, 2013 7:56 pm
by -ralf-
Very good news, thank you :D

Re: GPS NAV

Posted: Thu Nov 14, 2013 9:08 pm
by U.Sentenza
fantastic thanks

Re: GPS NAV

Posted: Fri Nov 15, 2013 12:09 am
by rbirdie001
EOSBandi wrote:Quick note..... (I'm traveling in the US so no time to develop till end of Oct)...I2CGps_nav will be discontinued by me. There will be one update to 2.3 including all patches and recommendations. But it will not include waypoint nav. If anyone willing to take over it is the time. But it puts unneccessary complexity to the nav code and only good for providing profit for sellers who monetize the MultiWii platform via selling outdated 328p boards.
I' also interested that is there anyone who uses tinyGPS and GPSfromOSD ? It seems quite abandoned and sometimes buggy. I recommend to drop it from the main codebase.

HI eosbandi,
it's nice to hear that you have again some time and mind to bring some new features! ;)
Many users including me are still using your (great!) I2C_GPS_NAV code but now with new MW 2.3 release current version of NAV makes some I2C errors. Do you think you can add upgrade of this software into your "roadmap" ?
If so, please let me point out small typing error in the I2C_GPS_NAV_v2_2.ino on the line 724, which can be corrected at the same time:
Instead of

Code: Select all

case 7: i2c_dataset.ground_speed = (atof(string)*0.5144444)*10;      //convert to m/s*100
should be ...0.5144444)*100;
More info why I think this you can see here: viewtopic.php?f=8&t=2918&start=620#p42051
Thanks for you effort!
Roman

Re: GPS NAV

Posted: Fri Nov 15, 2013 3:29 am
by ezio
maybe heading should be in the WP struct too ?
And also could you add the possibility to check via MSP if the waypoint is reached ?

Bart

Re: GPS NAV

Posted: Sun Nov 17, 2013 2:42 pm
by Alexinparis
EOSBandi wrote:Hi !
Now I have time... so roadmap is the following :
1. Make WinGUI 2.3 ready (almost done) and finish WP upload code
2. Merge MW2.3 release into navi-dev codebase
3. Finish WP uploading code
4. Simulation tests
5. Flight tests

It shouldn't take more than 2 weeks.

You can follow (and/or test) here :
http://code.google.com/p/mw-wingui/
http://code.google.com/p/multiwii-navi-dev/

I'll post regular updates in this forum.


very good news :)

Re: GPS NAV

Posted: Sun Nov 17, 2013 10:23 pm
by EOSBandi
WinGUI 2.3 pre1 is uploaded to google code (http://code.google.com/p/mw-wingui/downloads/list)
It supposed to be Mw2.3 compatibile, but needs testing.
Waypoint planning is working in the GUI, but does not upload and download missions yet.

Some of the tabs are reorganized to better suit telemetry usage.
Please report issues via google code issue management (http://code.google.com/p/mw-wingui/issues/list)

moving to MW code now....

Re: GPS NAV

Posted: Fri Nov 22, 2013 6:11 pm
by tw-ryder
Created an account to let the developers know that the 2.3 code worked great for my first MultiWii experience. On a HK MWC Pro (Atmega2560) with MTK GPS, I had my fiberglass quad up and stable in no time. Thank you for what you do, I look forward to more updates, please keep up the amazing work! :D

Re: GPS NAV

Posted: Fri Nov 22, 2013 9:22 pm
by -ralf-
tw-ryder wrote:Created an account to let the developers know that the 2.3 code worked great for my first MultiWii experience. On a HK MWC Pro (Atmega2560) with MTK GPS, I had my fiberglass quad up and stable in no time. Thank you for what you do, I look forward to more updates, please keep up the amazing work! :D

GPS-NAV is working :ugeek:

Link to download ?

Re: GPS NAV

Posted: Mon Nov 25, 2013 12:44 am
by EOSBandi
I think tw-ryder refers to the WinGUI.


However GPS-NAV is waiting for flight test... quick update : http://www.youtube.com/watch?v=sVw2dcRbgzo
Once it flied, it will go into beta...

Re: GPS NAV

Posted: Mon Nov 25, 2013 1:03 am
by felixrising
Awesome! Love the music too =D

Re: GPS NAV

Posted: Mon Nov 25, 2013 11:43 am
by dramida
Great demo Mr. Eos, thank you. You give a new life to MWC.
I noticed the commands you can issue on Wingui and i think it would be very useful to have:

Loop (n_times) so it can repeat a pattern
RoI - set Region of Interest in x/y so copter would always face a part of a map until a next RoI is issued or yaw command comes from Tx.
CamTrig- triggers the camera/ servo after reaches a WP
PH_Climb(alt) - takes off to specified altitude before heading to first wp in PH mode (safety feature) and descend after RTH

Beware that GPS average filtering is not enough to safely navigate. Sometimes Hdop (horizontal dilution of precision) is so bad that error is tens of meters. Even so, Hdop dosen't change fast enough as errors come in so we need a X-Y positioning filter:
One ideea is to compare current position with previous position and 0.2ms x prev_gps_speed. If is in an acceptable range (how fast could copter accelerate?) then data is validated. If no valid data is provided in 1 second, then auto mode should be disengaged. Now it would be handy Inertial navigation only :)

Re: GPS NAV

Posted: Thu Nov 28, 2013 1:55 pm
by EOSBandi
One step at a moment. :D

GPS average filtering is there only for one reason, to allow some lever of jitter free poshold with low resolution NMEA output GPS modules.
I seriously contemplating that navigation could be enabled only with ubox or mtk1.9 protocols.

Bad hdop means bad gps reception or noise from the onboard electronics. It is better to use elevated and shielded gps module with a large antenna. (Esp. in central and eastern Europe, where the satellites are close to the horizon) or we should move to multi constellation gps receivers to use GPS and GLONASS simultaneously.
When you move from from point A to point B some intermittent errors will not cause significant problem, just some perturbation. I do believe that it's enough to halt navigation when sat count drops below 5.

Re: GPS NAV

Posted: Thu Nov 28, 2013 3:35 pm
by Wayne
Is there a GUI for the Crius Nav bds.?
My working setup has not GPS fixed for almost a week now. I used MiniGPS, GPS module is working, even re-flashed just to make sure.
I downloaded a clean copy of the GPS NAVsketch, did an eeprom clear and uploaded it to the Nav Bd.
I also tried reducing the GPS_SERIAL_SPEED in both the gps module and the nav bd.
Still no fix.
I would like to see what is happening inside the nav bd. before I throw it away and have to order a new one.

Re: GPS NAV

Posted: Fri Nov 29, 2013 2:20 pm
by Sebbi
"Now it would be handy Inertial navigation only" ... can't there be some kind of Kalman filter for the position? Combining IMU and GPS and other position/speed sensors to get more reliable information? I guess an Arduino wouldn't be fast enough, but an external µC could feed such filtered GPS data via the GUI protocol ;-)

Re: GPS NAV

Posted: Fri Nov 29, 2013 4:28 pm
by alll
That was the purpose of I2C_GPS_NAV, and is abonded... sad IMO. Now all is separated in code files, but treated by 1 cpu.

If GPS needs IMU information, then it is another story.

manu

Re: GPS NAV

Posted: Fri Nov 29, 2013 9:49 pm
by dramida
EOSBandi wrote:When you move from from point A to point B some intermittent errors will not cause significant problem, just some perturbation. I do believe that it's enough to halt navigation when sat count drops below 5.


Hello again Mr. EoBandis. Thanks for your interesting answer about GPS constelation.
But from Arducopter experience, when navigating, it is deadly important to have acurat GPS positioning or else random moves could suddenly smash your copter in ....anything, especially if you are in a urban canyon at ground level . This is not fiction but Arducopter facts. I helped with logs to find out this situation for arducopter and i guess you should also be aware about it.

One solution would be to compare actual gps position with previous gps position plus previous GPS velocity multiplied by 0.2s

Re: GPS NAV

Posted: Sun Dec 01, 2013 11:10 pm
by -ralf-
From r61 notes ....

Preparing for pre4 release on sunday


Next Sunday :?:

Re: GPS NAV

Posted: Mon Dec 02, 2013 1:27 am
by EOSBandi
-ralf- wrote:From r61 notes ....

Preparing for pre4 release on sunday


Next Sunday :?:

Almost... :D
First couple of flights has been made this weekend. Found some issues (not big ones). Dec 6th is the date... :D

Here is some eye candy until that.
http://youtu.be/hyiNJVYDyw0

Re: GPS NAV

Posted: Mon Dec 02, 2013 7:19 am
by Crashpilot1000
Comment deleted. Reason: Input obviously not needed/wanted.
Cheers
Rob