GPS NAV

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

GPS NAV

Post 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.
Last edited by EOSBandi on Mon Mar 17, 2014 6:56 pm, edited 3 times in total.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: GPS NAV

Post by e_lm_70 »

Good job

Will you also update the MultiWii gui ?

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: GPS NAV

Post 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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: GPS NAV

Post 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

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post by EOSBandi »

e_lm_70 wrote:Good job

Will you also update the MultiWii gui ?


Yes

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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.

fryefryefrye
Posts: 57
Joined: Thu Apr 11, 2013 7:19 am

Re: GPS NAV

Post 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.

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: GPS NAV

Post by ezio »

Can't wait to see this finished so I can implement it in my app.
Good work.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: GPS NAV

Post 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

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: GPS NAV

Post 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

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: GPS NAV

Post 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.

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: GPS NAV

Post 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

ttcorse
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

Re: GPS NAV

Post 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.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: GPS NAV

Post 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

scanman
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa
Contact:

Re: GPS NAV

Post 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.

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: GPS NAV

Post 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

User avatar
U.Sentenza
Posts: 17
Joined: Fri May 17, 2013 11:44 am

Re: GPS NAV

Post 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

ttcorse
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

Re: GPS NAV

Post by ttcorse »

-1

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: GPS NAV

Post 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...

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: GPS NAV

Post 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

scanman
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa
Contact:

Re: GPS NAV

Post 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!)

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS NAV

Post 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).


rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: GPS NAV

Post 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

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: GPS NAV

Post 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 ...

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: GPS NAV

Post 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

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: GPS NAV

Post 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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: GPS NAV

Post by Hamburger »

Tinygps is gone in pre v2.3 now. (since r1585)

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: GPS NAV

Post by haydent »

i just switched to ublox from MTK, much better ! more satelites quicker and smoother nav

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: GPS NAV

Post by -ralf- »

Very good news, thank you :D

User avatar
U.Sentenza
Posts: 17
Joined: Fri May 17, 2013 11:44 am

Re: GPS NAV

Post by U.Sentenza »

fantastic thanks

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: GPS NAV

Post 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

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: GPS NAV

Post 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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: GPS NAV

Post 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 :)

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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....

tw-ryder
Posts: 1
Joined: Fri Nov 22, 2013 5:40 pm

Re: GPS NAV

Post 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

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: GPS NAV

Post 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 ?

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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...

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: GPS NAV

Post by felixrising »

Awesome! Love the music too =D

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS NAV

Post 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 :)

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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.

Wayne
Posts: 86
Joined: Sun Jul 31, 2011 10:44 pm

Re: GPS NAV

Post 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.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: GPS NAV

Post 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 ;-)

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: GPS NAV

Post 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

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS NAV

Post 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

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: GPS NAV

Post by -ralf- »

From r61 notes ....

Preparing for pre4 release on sunday


Next Sunday :?:

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS NAV

Post 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

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: GPS NAV

Post by Crashpilot1000 »

Comment deleted. Reason: Input obviously not needed/wanted.
Cheers
Rob
Last edited by Crashpilot1000 on Mon Dec 02, 2013 5:57 pm, edited 1 time in total.

Post Reply