GPS NAV

rbirdie001 · Post by **rbirdie001** » Sun Oct 06, 2013 1:50 pm

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 · Post by **scanman** » Sun Oct 06, 2013 3:08 pm

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

EOSBandi · Post by **EOSBandi** » Mon Oct 07, 2013 8:54 pm

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.

dramida · Post by **dramida** » Thu Oct 10, 2013 10:47 am

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 · Post by **rbirdie001** » Thu Oct 10, 2013 10:18 pm

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 · Post by **e_lm_70** » Fri Oct 18, 2013 1:27 pm

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 · Post by **e_lm_70** » Fri Oct 18, 2013 1:30 pm

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 · Post by **doughboy** » Wed Oct 30, 2013 12:59 am

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.

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.

Hamburger · Post by **Hamburger** » Wed Oct 30, 2013 9:49 am

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

haydent · Post by **haydent** » Wed Oct 30, 2013 11:24 am

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

EOSBandi · Post by **EOSBandi** » Thu Nov 14, 2013 5:59 pm

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- · Post by **-ralf-** » Thu Nov 14, 2013 7:56 pm

Very good news, thank you

U.Sentenza · Post by **U.Sentenza** » Thu Nov 14, 2013 9:08 pm

fantastic thanks

rbirdie001 · Post by **rbirdie001** » Fri Nov 15, 2013 12:09 am

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

ezio · Post by **ezio** » Fri Nov 15, 2013 3:29 am

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 · Post by **Alexinparis** » Sun Nov 17, 2013 2:42 pm

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

EOSBandi · Post by **EOSBandi** » Sun Nov 17, 2013 10:23 pm

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 · Post by **tw-ryder** » Fri Nov 22, 2013 6:11 pm

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!

-ralf- · Post by **-ralf-** » Fri Nov 22, 2013 9:22 pm

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!

GPS-NAV is working :ugeek:

Link to download ?

EOSBandi · Post by **EOSBandi** » Mon Nov 25, 2013 12:44 am

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 · Post by **felixrising** » Mon Nov 25, 2013 1:03 am

Awesome! Love the music too =D

dramida · Post by **dramida** » Mon Nov 25, 2013 11:43 am

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

EOSBandi · Post by **EOSBandi** » Thu Nov 28, 2013 1:55 pm

One step at a moment.

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 · Post by **Wayne** » Thu Nov 28, 2013 3:35 pm

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 · Post by **Sebbi** » Fri Nov 29, 2013 2:20 pm

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

alll · Post by **alll** » Fri Nov 29, 2013 4:28 pm

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

dramida · Post by **dramida** » Fri Nov 29, 2013 9:49 pm

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- · Post by **-ralf-** » Sun Dec 01, 2013 11:10 pm

From r61 notes ....

Preparing for pre4 release on sunday

Next Sunday :?:

EOSBandi · Post by **EOSBandi** » Mon Dec 02, 2013 1:27 am

-ralf- wrote:From r61 notes ....

Preparing for pre4 release on sunday

Next Sunday

Almost...

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

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

Crashpilot1000 · Post by **Crashpilot1000** » Mon Dec 02, 2013 7:19 am

Comment deleted. Reason: Input obviously not needed/wanted.
Cheers
Rob

-ralf- · Post by **-ralf-** » Mon Dec 02, 2013 9:50 am

Very very good

Thank's for all .....

-ralf- · Post by **-ralf-** » Mon Dec 02, 2013 11:44 am

Hi András,

will you be so kind and write a new documentation like you did for r33?

Noctaro · Post by **Noctaro** » Mon Dec 02, 2013 12:28 pm

EOSBandi, that rocks! Looking forward to test your nav feature. (As soon as my ordered OSD, and BT-module arrives.) Thank you for your great ideas and conversions! Nice trailer!

Keep it up dude!
Your copter seems to behave very predictable, i like this.
Could there be a way to calculate and set the travelspeed between waypoints in common KM/H and/or MP/H? Would be great i think.(With a limit around 25KM/H?) Or will it complicate things because of wind and weather circumstances? I dont know if its a good idea, but maybe we could depend travelspeed also to GPS-fix. If GPS drop below 7 sats, limit it to 10km/h travelspeed for example, to reduce the offset errors.

Greetz Noc

-ralf- · Post by **-ralf-** » Mon Dec 02, 2013 3:05 pm

BTW ...... NAV-PID's are defined twice in multiwii.h ........

NikTheGreek · Post by **NikTheGreek** » Mon Dec 02, 2013 3:50 pm

Great Work EOSBandi...

I know that probably is premature to make requests but "Duplicate way-point" button is one of the things i wanted to see in the next releases.

Thank you.

EOSBandi · Post by **EOSBandi** » Mon Dec 02, 2013 4:25 pm

NikTheGreek wrote:Great Work EOSBandi...

I know that probably is premature to make requests but "Duplicate way-point" button is one of the things i wanted to see in the next releases.

Thank you.

Errrr, what is it supposed to do ? and how can be it usefull ?

EOSBandi · Post by **EOSBandi** » Mon Dec 02, 2013 4:26 pm

-ralf- wrote:BTW ...... NAV-PID's are defined twice in multiwii.h ........

Cleaning up code right now

NikTheGreek · Post by **NikTheGreek** » Mon Dec 02, 2013 5:26 pm

Errrr, what is it supposed to do ? and how can be it usefull ?

Hmmm...
The user can duplicate the LAT LON coordinates easily and change only the Altitude for example...

steps

1)Go to LAT-LON...stay for 5 sec there
2)-- Duplicate button --
3) keeps LAT -LON the same and change the ALT only

Does it make sense now ? :oops:

Thank you.

hinkel · Post by **hinkel** » Mon Dec 02, 2013 8:05 pm

Crashpilot1000 wrote:Comment deleted. Reason: Input obviously not needed/wanted.
Cheers
Rob

Sorry Crashpilot1000 !
I have not see your comment, I think all your inputs are extremely important !
Feel free to share your comment !

Regards
hinkel

EOSBandi · Post by **EOSBandi** » Mon Dec 02, 2013 8:49 pm

Noctaro wrote::shock:
EOSBandi, that rocks! Looking forward to test your nav feature. (As soon as my ordered OSD, and BT-module arrives.) Thank you for your great ideas and conversions! Nice trailer! Keep it up dude!
Your copter seems to behave very predictable, i like this.
Could there be a way to calculate and set the travelspeed between waypoints in common KM/H and/or MP/H? Would be great i think.(With a limit around 25KM/H?) Or will it complicate things because of wind and weather circumstances? I dont know if its a good idea, but maybe we could depend travelspeed also to GPS-fix. If GPS drop below 7 sats, limit it to 10km/h travelspeed for example, to reduce the offset errors.

Greetz Noc

Travel speed is a config parameter for NAV.- NAV_SPEED_MAX and NAV_SPEED_MIN the unit is cm/sec.
connecting nav_speed to gps reception quality is an interesting idea, will worth a try.

EOSBandi · Post by **EOSBandi** » Mon Dec 02, 2013 8:52 pm

Crashpilot1000 wrote:Comment deleted. Reason: Input obviously not needed/wanted.
Cheers
Rob

If I don't answer to something that does not mean that I did not read or considered it...

-ralf- · Post by **-ralf-** » Mon Dec 02, 2013 9:04 pm

EOSBandi wrote:
Noctaro wrote::shock:
EOSBandi, that rocks! Looking forward to test your nav feature. (As soon as my ordered OSD, and BT-module arrives.) Thank you for your great ideas and conversions! Nice trailer! Keep it up dude!
Your copter seems to behave very predictable, i like this.
Could there be a way to calculate and set the travelspeed between waypoints in common KM/H and/or MP/H? Would be great i think.(With a limit around 25KM/H?) Or will it complicate things because of wind and weather circumstances? I dont know if its a good idea, but maybe we could depend travelspeed also to GPS-fix. If GPS drop below 7 sats, limit it to 10km/h travelspeed for example, to reduce the offset errors.

Greetz Noc

Travel speed is a config parameter for NAV.- NAV_SPEED_MAX and NAV_SPEED_MIN the unit is cm/sec.
connecting nav_speed to gps reception quality is an interesting idea, will worth a try.

Code: Select all

  #define NAV_SPEED_MIN              100    // cm/sec
  #define NAV_SPEED_MAX              300    // cm/sec
  #define NAV_SLOW_NAV               true
  #define NAV_BANK_MAX 3000        //30deg max banking when navigating (just for security and testing)

András,

maybe a better place is in config.h then in gps.cpp ....

EOSBandi · Post by **EOSBandi** » Tue Dec 03, 2013 1:02 am

Just a short note !
FORGET Bluetooth - Get a 3DR Radio !
http://www.goodluckbuy.com/single-ttl-3 ... -apm2.html

There will be a MultiWii optimized firmware

(it's pretty high on my project list)

prodrone · Post by **prodrone** » Tue Dec 03, 2013 12:33 pm

EOSBandi wrote:Just a short note !
FORGET Bluetooth - Get a 3DR Radio !
http://www.goodluckbuy.com/single-ttl-3 ... -apm2.html

There will be a MultiWii optimized firmware (it's pretty high on my project list)

I think this will interfere with long range UHF RC control Rx/Tx, frequently used for FPV flying, like the immersion EzUHF, right ?

EOSBandi · Post by **EOSBandi** » Tue Dec 03, 2013 1:11 pm

prodrone wrote:
EOSBandi wrote:Just a short note !
FORGET Bluetooth - Get a 3DR Radio !
http://www.goodluckbuy.com/single-ttl-3 ... -apm2.html

There will be a MultiWii optimized firmware (it's pretty high on my project list)

I think this will interfere with long range UHF RC control Rx/Tx, frequently used for FPV flying, like the immersion EzUHF, right ?

If you live in EU you can use 868Mhz, if in US then 900. No interference.

TTRCmedia · Post by **TTRCmedia** » Tue Dec 03, 2013 2:14 pm

EOSBandi wrote: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.

Oh well, so no chance for me to test GPS NAV on friday

jaames74 · Post by **jaames74** » Tue Dec 03, 2013 4:04 pm

TTRCmedia wrote:
EOSBandi wrote: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.

Oh well, so no chance for me to test GPS NAV on friday

+1

well,, time has come for us pathetic i2c_gps users, to put our 328 boards in our a...s and start ordering mega boards :cry:

EOSBandi · Post by **EOSBandi** » Tue Dec 03, 2013 8:16 pm

It simply won't fit.
some parts of the navigation logic, and code for WP uploading/downloading could not be moved to the i2c_gps code. Plus you need a working alt hold with high prec. baro and a mag. Including all these functions brings the code size to the limit. Plus nav needs a lot's of RAM space for variables. RAM space is the most sparse resource with MultiWii on 328p. If you run out of RAM space that is a disaster and almost impossible to debug.

So considering all the factors it is very unlikely that waypoint navigation can be implemented on i2c_gps. Even if it crammed in, it wont be safe....

In these times, the last thing that I would like to see a is runaway multiwii copter in the news.

copterrichie · Post by **copterrichie** » Tue Dec 03, 2013 8:20 pm

The End of an Age.

-ralf- · Post by **-ralf-** » Tue Dec 03, 2013 8:44 pm

EOSBandi wrote:Just a short note !
FORGET Bluetooth - Get a 3DR Radio !
http://www.goodluckbuy.com/single-ttl-3 ... -apm2.html

There will be a MultiWii optimized firmware (it's pretty high on my project list)

OK, ordered ..... so go on to make it work