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
User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

ezio wrote:Hi
I know that this is in MSP protocol for a while now, but I think that storing the NAV version in capability flag is not a good idea especialy when baseflight and cleanflight use the same bits for other staff. It starts to irritates me because there is no way to write universal GUI if there is no rules !


Bart, Well said. The situation was ridiculous, now it's untenable. Yesterday I added some mwptools based on CAP_CLEANFLIGHT_CONFIG, today the whole thing is broken because none of FC authors appear to consider that that there are any other implementations other than their own. At this rate there will be no 3rd party tools.

Welcome to the angry club.

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

Leo wrote:Bart,

wouldn't it be a better idea if you define the requirements needed for EZ-GUI otherwise everyone else is still going to cook their own soup?

Leo

So how much better would it be if alexinparis, eosbandi, timecop, dominicclifton et al could get together and agree:
  • The usage of capabilities (and revert the clashes, guarded by a minor increment to the version number e.g. (230 => 232));
  • Agree an MSP message that takes one parameter uniquely identifying the FC, and then a variable sized data field at the sole discretion of the FC author (e.g. for specific version info);
  • Agree other MSP message allocations; at least timecop and dominic appear to have done that in the range 32-63 and 64-, even without actually talking to each other.

With the combination of this message board, the wiki and IRC, it should not be this chaotic. Please.

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

enough_.jpg

msev
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: GPS NAV

Post by msev »

Hehehehehe

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: GPS NAV

Post by dominicclifton »

Code: Select all

#define CAP_CHANNEL_FORWARDING ((uint32_t)1 << 4)


that is deprecated, i will delete that now.

use

Code: Select all

#define CAP_CLEANFLIGHT_CONFIG ((uint32_t)1 << 29)


to detect cleanflight and cleanflight msp commands

stronnag wrote:So how much better would it be if alexinparis, eosbandi, timecop, dominicclifton et al could get together and agree:

The usage of capabilities (and revert the clashes, guarded by a minor increment to the version number e.g. (230 => 232));
Agree an MSP message that takes one parameter uniquely identifying the FC, and then a variable sized data field at the sole discretion of the FC author (e.g. for specific version info);
Agree other MSP message allocations; at least timecop and dominic appear to have done that in the range 32-63 and 64-, even without actually talking to each other.


* I didn't notice any other clashes with regards to the capability flags.
* I chose a range for new MSP commands that appeared to be unused. I have to start defining commands that i want to use and then make sure they will work with the tools before I settle on what is actually needed. This can be seen from the recent aux/mode changes.
* I didn't agree anything with timecop since he ignores me on the forum and on irc (and has done for months now). the onus is on him to be rational and sensible. It's pretty hard to agree on anything without actual communication. I would also speculate that due to his dislike of cleanflight he won't care about cleanflight MSP compatability, I sincerely hope I am mistaken in that regard.

* Since the MSP_IDENT command is already set in stone that can't really be changed now (it's too late), an additional command that, as you say, is variable length but identifies the FC. I agree that using a capabilities bitmask isn't so great for this. I would go with 4 bytes that use letters/numbers in upper case rather than a single one however.
* Then i think there should be an API version number in the response, so that authors of tools can know and build around API changes. Uniquely identifying the FC isn't enough.
* The API version is specific to the FC and is in addition to the MSP protocol version. This is so that the first MSP command issues by a tool finds the protocol version using MSP_IDENT and then the second command issues would be to the new command to find out the finer details.
* The API version should be in the format major/minor.
* Using a build version, in the format major.minor.patchlevel be standard for all FC's that support the new command and included in the response.
* Including build date/time in the response would be good, the baseflight MSP_BUILDINFO imho is not required and not good enough since it doesn't contain the time.
* Since baseflight and cleanflight both use git, including the short git revision number in the response would be good, it's trivial to do too, cleanflight already shows this in the cli via the version command.
* Then there should be an API and FC specific section, the contents of which should be documented by the FC authors.

Maybe i have more ideas, gotta get to work now...

cTn
Posts: 23
Joined: Sat Apr 13, 2013 12:03 pm

Re: GPS NAV

Post by cTn »

* I didn't agree anything with timecop since he ignores me on the forum and on irc (and has done for months now). the onus is on him to be rational and sensible. It's pretty hard to agree on anything without actual communication. I would also speculate that due to his dislike of cleanflight he won't care about cleanflight MSP compatability, I sincerely hope I am mistaken in that regard.


Considering the amount of people you managed to piss of during the short time that you are dealing with RC stuff, you are lucky that ignoring you is the only thing he is doing.

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: GPS NAV

Post by dominicclifton »

cTn wrote:Considering the amount of people you managed to piss of during the short time that you are dealing with RC stuff, you are lucky that ignoring you is the only thing he is doing.


Please keep this thread on topic, I will not engage in that drama. It's in the past.

Ctn, as the author of the configurator tool I value your input with regards to MSP command and protocol direction, do you have any technical related thoughts on this?

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

@dominicclifton: I think you'll find that blatting navi version over bits 28-31 has a detrimental effect on recognising 32 bit platforms.

Code: Select all

capability|DYNBAL<<2|FLAP<<3|NAVCAP<<4|EXTAUX<<5|((uint32_t)NAVI_VERSION<<28);   // //Navi version is stored in the upper four bits; 

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: GPS NAV

Post by dominicclifton »

Ok, after talks with bart (EzGUI) and stronnag (mwptools) I came up with this:

https://github.com/cleanflight/cleanfli ... 073ac1f747

Here's the details of the MSP_API_VERSION command, which is of course not final yet - pending tool authors feedback and some level of agreement.

Code: Select all

    case MSP_API_VERSION:
        // the components of this command are in an order such that future changes could be made to it without breaking clients.
        // i.e. most important first.
        headSerialReply(
            1 + // protocol version length
            API_VERSION_LENGTH +
            FLIGHT_CONTROLLER_IDENTIFIER_LENGTH +
            FLIGHT_CONTROLLER_VERSION_LENGTH +
            BOARD_IDENTIFIER_LENGTH +
            BOARD_HARDWARE_REVISION_LENGTH +
            BUILD_DATE_LENGTH +
            BUILD_TIME_LENGTH +
            1 + // scm reference length
            GIT_SHORT_REVISION_LENGTH +
            1 // additional FC specific length
            // no addition FC specific data yet.
        );
        serialize8(MSP_PROTOCOL_VERSION);

        serialize8(API_VERSION_MAJOR);
        serialize8(API_VERSION_MINOR);

        for (i = 0; i < FLIGHT_CONTROLLER_IDENTIFIER_LENGTH; i++) {
            serialize8(flightControllerIdentifier[i]);
        }

        serialize8(FC_VERSION_MAJOR);
        serialize8(FC_VERSION_MINOR);
        serialize8(FC_VERSION_PATCH_LEVEL);

        for (i = 0; i < BOARD_IDENTIFIER_LENGTH; i++) {
            serialize8(boardIdentifier[i]);
        }
#ifdef NAZE
        serialize16(hardwareRevision);
#else
        serialize16(0); // No other build targets currently have hardware revision detection.
#endif

        for (i = 0; i < BUILD_DATE_LENGTH; i++) {
            serialize8(buildDate[i]);
        }
        for (i = 0; i < BUILD_TIME_LENGTH; i++) {
            serialize8(buildTime[i]);
        }

        serialize8(GIT_SHORT_REVISION_LENGTH);
        for (i = 0; i < GIT_SHORT_REVISION_LENGTH; i++) {
            serialize8(shortGitRevision[i]);
        }
        serialize8(0); // No flight controller specific information to follow.
        break;


I've added some guidelines in the code, which I've copied below for reference.

Code: Select all

/**
 * MSP Guidelines, emphasis is used to clarify.
 *
 * Each FlightController (FC, Server) MUST change the API version when any MSP command is added, deleted, or changed.
 *
 * If you fork the FC source code and release your own version, you MUST change the Flight Controller Identifier.
 *
 * NEVER release a modified copy of this code that shares the same Flight controller IDENT and API version
 * if the API doesn't match EXACTLY.
 *
 * Consumers of the API (API clients) SHOULD first attempt to get a response from the MSP_API_VERSION command.
 * If no response is obtained then client MAY try the legacy MSP_IDENT command.
 *
 * API consumers should ALWAYS handle communication failures gracefully and attempt to continue
 * without the information if possible.  Clients MAY log/display a suitable message.
 *
 * API clients should NOT attempt any communication if they can't handle the API MAJOR VERSION.
 *
 * API clients SHOULD attempt communication if the API MINOR VERSION has increased from the time
 * the API client was written and handle command failures gracefully.  Clients MAY disable
 * functionality that depends on the commands while still leaving other functionality intact.
 * Clients SHOULD operate in READ-ONLY mode and SHOULD present a warning to the user to state
 * that the newer version may cause problems before using API command that change FC state.
 *
 * It is for this reason that each MSP command should be specific as possible, such that changes
 * to commands break as little functionality as possible.
 *
 * API client authors MAY use a compatibility matrix/table that when determining if they can support
 * a given command from a given flight controller at a given api version level.
 *
 * Developers MUST NOT create new MSP commands that do more than one thing.
 *
 * Failure to follow these guidelines will likely invoke the wrath of developers trying to write tools
 * that use the API and the users of those tools.
 */


feedback?

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

Re: GPS NAV

Post by timecop »

Feedback? Fork EZ-GUI and make your own version. It's the only way to go.

bicycle
Posts: 27
Joined: Sun May 06, 2012 4:58 am

Re: GPS NAV

Post by bicycle »

dominicclifton wrote:Ctn, as the author of the configurator tool I value your input with regards to MSP command and protocol direction, do you have any technical related thoughts on this?


He does! but he probably won't post them here, because you'll just change all the variable names and call it your own work.

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

Re: GPS NAV

Post by brm »

cTn wrote:
* I didn't agree anything with timecop since he ignores me on the forum and on irc (and has done for months now). the onus is on him to be rational and sensible. It's pretty hard to agree on anything without actual communication. I would also speculate that due to his dislike of cleanflight he won't care about cleanflight MSP compatability, I sincerely hope I am mistaken in that regard.


Considering the amount of people you managed to piss of during the short time that you are dealing with RC stuff, you are lucky that ignoring you is the only thing he is doing.


there are prob more people who completely ignore TC as vice versa.

User avatar
treym
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: GPS NAV

Post by treym »

bicycle wrote:
dominicclifton wrote:Ctn, as the author of the configurator tool I value your input with regards to MSP command and protocol direction, do you have any technical related thoughts on this?


He does! but he probably won't post them here, because you'll just change all the variable names and call it your own work.



hello bicycle,

I have read all your post and contriibution Also Ctn just told me on irc that you are making bias assuption,

Unless you are 100% entitled , dont speak in other name .

thanks in advance.

User avatar
treym
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: GPS NAV

Post by treym »

stronnag wrote:So how much better would it be if alexinparis, eosbandi, timecop, dominicclifton et al could get together and agree:

With the combination of this message board, the wiki and IRC, it should not be this chaotic. Please.


indeed , there are people talking about such initative ...

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

Re: GPS NAV

Post by EOSBandi »

Leo wrote:I just compiled the latest dev r1717 for my 328 FC board.

Sketch uses 28,628 bytes (93%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,582 bytes (77%) of dynamic memory, leaving 466 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.

Am I in any danger?

If so, is it possible to deactivate the "Mission" and "Land" function within MultiWii as I don't really need it?

Leo


Since i2c gps is not supported atm in the code, gps functions are not supported on 328 based boards.....

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

Re: GPS NAV

Post by -ralf- »

EOSBandi wrote:
Leo wrote:I just compiled the latest dev r1717 for my 328 FC board.

Sketch uses 28,628 bytes (93%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,582 bytes (77%) of dynamic memory, leaving 466 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.

Am I in any danger?

If so, is it possible to deactivate the "Mission" and "Land" function within MultiWii as I don't really need it?

Leo


Since i2c gps is not supported atm in the code, gps functions are not supported on 328 based boards.....


András,

Alex wrote in the description of r1717

- in GPS.cpp: separate clearly code for parsing GPS device / code for navigation
- reintroduction of I2C_GPS used like a basic and generic GPS device


For me this means I2C-GPS is again supported from now.

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:
EOSBandi wrote:
Leo wrote:I just compiled the latest dev r1717 for my 328 FC board.

Sketch uses 28,628 bytes (93%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,582 bytes (77%) of dynamic memory, leaving 466 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.

Am I in any danger?

If so, is it possible to deactivate the "Mission" and "Land" function within MultiWii as I don't really need it?

Leo


Since i2c gps is not supported atm in the code, gps functions are not supported on 328 based boards.....


András,

Alex wrote in the description of r1717

- in GPS.cpp: separate clearly code for parsing GPS device / code for navigation
- reintroduction of I2C_GPS used like a basic and generic GPS device


For me this means I2C-GPS is again supported from now.

Yepp, I missed that update. However i thing that gps funcions are no longer supported (recommended) on 328p boards, due memory issues.

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

Short video illustrating mwnav accuracy (pretty good imho).


brewski
Posts: 483
Joined: Tue Apr 29, 2014 12:04 am
Location: Cleveland Qld Australia

Re: GPS NAV

Post by brewski »

Very Impressive for an opensource firmware & controller! I doubt that a Nasa could do better.
How did you produce the GPD data overlay? Did you have onboard logging or use EZ-GUI? I couldn't enlarge image enough to read.

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

mwptools. Play at back full screen on YouTube with sound to see the full capability. mwp ("multiwii planner") is a linux tool to do the sort of stuff EZ-GUI and WinGUI do; mission planning, real time mission logging, recording and play back. The YT video illustrates loading the mission, then replaying the logged data with audio prompts. Recorded via 3DR radio on the quad and laptop, MW Mega2560 FC, and the last usable nav version from SVN (i.e. before r1717).

josepo
Posts: 6
Joined: Mon Oct 13, 2014 11:17 pm

Re: GPS NAV

Post by josepo »

Hello
Read the forum translating it with google because they are not English
But that have asked me to translate:

I've assembled the quadricopter with the electronic indicated below, and once I have managed to fly stable I have tried to test the navigation activating maintain position, but soon after activating it I have to get the control, then I have activated position and barometer, and it keeps height pretty well fluctuating meter up or down on the position of activation, but the position goes drifting and I'm following up to the limit of the field, and then I have to get the control, GPS gives position well and also I hear as the barometer is active and maintaining position on the phone, but it does not, every time I activate it, it drift to a different direction until I have to get the control and I don’t know what other thing I can do, I have not tried mission because I´m afraid of a violent response and I do not want to try it until achieve to maintain the position, so I ask you to help me out to see how I can solve it. : :oops:

hardware:
Multiwiipro (HK) processor 2560 integrated 3 accelerometer , 3 gyroscopes , barometer and compass
GPS ublos NEO6 38400 Bd
Connect Bt (libor)
sof: 2.3 multiwi B7 eosbandi navi, win-gui, ez-gui
Radio: Futaba
phone samsung s4

Best regards

GUSHELFER
Posts: 14
Joined: Mon Apr 07, 2014 5:31 pm

Re: GPS NAV

Post by GUSHELFER »

excelente !!!!!!! muchas gracias a todos los que hacen posible este proyecto.
Recien termino de volar mi 1° RTH funcion, impecable !! perfecto !!!! en multiwii 2.2 win gui2.2 , crius multiwii v2.5 , i2c gpsnav, ublox, quadx.
desde Argentina ( la cola del mundo ) jajajj
ya estoy con el nuevo proyecto, en un hexa con 2560, , para usar multiwii 2.3 y todas su funciones, en un par de meses calculo estara volando !!!!
muchas gracias !!!!!

o_lampe
Posts: 117
Joined: Sat Nov 02, 2013 5:09 pm

Re: GPS NAV

Post by o_lampe »

@josepo
It's probably the compass giving you false reading. Did you calibrate the compass outdoors? Did you check the mag heading with the GUI at zero throttle and full throttle? ( Fix copter to the ground )

izeman
Posts: 57
Joined: Tue Sep 16, 2014 10:49 am

GPS NAV

Post by izeman »

spanish forum?

visper
Posts: 14
Joined: Sun Feb 16, 2014 5:28 pm

Re: GPS NAV

Post by visper »

I have a question: what is the optimal setting in GPS receiver "dynamic model" for this software? Airborne 4G, automotive or pedestrial?

Arakon
Posts: 196
Joined: Thu Jul 17, 2014 2:22 pm

Re: GPS NAV

Post by Arakon »

Supposedly pedestrial is meant to work best for our slow moving copters.

josepo
Posts: 6
Joined: Mon Oct 13, 2014 11:17 pm

Re: GPS NAV

Post by josepo »

See on the screen that the compass works, is not as sensitive as the accelerometers detect movimintos but only above 4 or 5 degrees.
The first GPS probe and pedestrian and now I have it in portable
translated with Google.

Regars

josepo

josepo
Posts: 6
Joined: Mon Oct 13, 2014 11:17 pm

Re: GPS NAV

Post by josepo »

So strange to me is that it goes smoothly without skidding make the slightest attempt to keep the position, maintains direction, height and speed but not the position.
translated with Google

Regards

Josepo

Bmays
Posts: 5
Joined: Sun Oct 05, 2014 11:08 pm

Re: GPS NAV

Post by Bmays »

o_lampe wrote:@josepo
It's probably the compass giving you false reading. Did you calibrate the compass outdoors? Did you check the mag heading with the GUI at zero throttle and full throttle? ( Fix copter to the ground )



@josepo

This was exactly my problem. Looking at the graphs at half/full throttle the "yaw" for magnetometer would go crazy. I have since ordered an external mag/compass.

Make sure you are not getting magnetic interference.

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: GPS NAV

Post by Leo »

Or you could take this route which I did.

I placed this under one of the plates and mounted it below the FC:

Image

Works wonderfully.

Rust
Posts: 36
Joined: Wed Nov 20, 2013 8:39 am

Re: GPS NAV

Post by Rust »

Leo wrote:Or you could take this route which I did.

I placed this under one of the plates and mounted it below the FC:

Image

Works wonderfully.


Hey, this looks interesting :)
Where can I get one?

o_lampe
Posts: 117
Joined: Sat Nov 02, 2013 5:09 pm

Re: GPS NAV

Post by o_lampe »

Rust wrote:
Hey, this looks interesting :)
Where can I get one?


Here: http://www.lessemf.com/mag-shld.html

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: GPS NAV

Post by Leo »

Rust wrote:Hey, this looks interesting :)
Where can I get one?


I got it from here: http://www.yshield.com/

Rust
Posts: 36
Joined: Wed Nov 20, 2013 8:39 am

Re: GPS NAV

Post by Rust »

Thanks!

Bmays
Posts: 5
Joined: Sun Oct 05, 2014 11:08 pm

Re: GPS NAV

Post by Bmays »

Quick question in regards to disabling the onboard mag in 2.3navi. I have the HK Crius aio clone (v1 Crius). I was getting major mag interference so I have completely removed the on-board mag from the board and wired an external mag to I2C.

I have defined the def.h file to #define MPU6050_I2C_AUX_MASTER however, NO sensors now work at all. No acc, no gyro, and of course no mag.

I have verified the sensors working with MPNG however I do NOT want to use that firmware. I like the 2.3navi. I have tried everything, eeprom clears, reloading fresh firmware etc. No senors work and massive I2C errors. All I did was remove the mag. This seems to have freaked out the code. Please help/Thanks

brewski
Posts: 483
Joined: Tue Apr 29, 2014 12:04 am
Location: Cleveland Qld Australia

Re: GPS NAV

Post by brewski »

Bmays wrote:Quick question in regards to disabling the onboard mag in 2.3navi. I have the HK Crius aio clone (v1 Crius). I was getting major mag interference so I have completely removed the on-board mag from the board and wired an external mag to I2C.

I have defined the def.h file to #define MPU6050_I2C_AUX_MASTER however, NO sensors now work at all. No acc, no gyro, and of course no mag.

I have verified the sensors working with MPNG however I do NOT want to use that firmware. I like the 2.3navi. I have tried everything, eeprom clears, reloading fresh firmware etc. No senors work and massive I2C errors. All I did was remove the mag. This seems to have freaked out the code. Please help/Thanks


I hope you didn't damage PCB when removing the onboard mag. All you really need to do with Crius AIOP V1 is cut the SDA & SCL pins on chip (Google HMC5883).
With AIOP V2 there are pads provided which you cut. Disconnect the ext mag & see if sensors are functioning without 12C errors. If all ok then & bus stops when ext board connected you have either wired ext mag board incorrectly or it is possibly faulty.

Mods to Def.h-

In multiwii 2.3 in the def.h tab under #if defined(CRIUS_AIO_PRO_V1)
change this line: #define MPU6050_I2C_AUX_MASTER // MAG connected to the AUX I2C bus of MPU6050
to this: //#define MPU6050_I2C_AUX_MASTER // MAG connected to the AUX I2C bus of MPU6050

I ordered a 5v external 5883 mag board from ebay (about $3) and connected it to the I2C port (I2C are providing 5v).
I did mag calibration and gave 100% throttle with props installed - Not even 1 degree difference.

visper
Posts: 14
Joined: Sun Feb 16, 2014 5:28 pm

Re: GPS NAV

Post by visper »

I use NEO M8N with GPS / Glonass. Outdoor normally receiving 20 satellites. But there is a problem with WAAS / EGNOS because it sends the data only for the GPS constellation. When 3D / DGPS activated, the Russian satellites are rigorously excluded. When I turn off the SBAS then Multiwii NAVb7 software turn on SBAS again.

Bmays
Posts: 5
Joined: Sun Oct 05, 2014 11:08 pm

Re: GPS NAV

Post by Bmays »

brewski wrote:
I hope you didn't damage PCB when removing the onboard mag. All you really need to do with Crius AIOP V1 is cut the SDA & SCL pins on chip (Google HMC5883).
With AIOP V2 there are pads provided which you cut. Disconnect the ext mag & see if sensors are functioning without 12C errors. If all ok then & bus stops when ext board connected you have either wired ext mag board incorrectly or it is possibly faulty.

Mods to Def.h-

In multiwii 2.3 in the def.h tab under #if defined(CRIUS_AIO_PRO_V1)
change this line: #define MPU6050_I2C_AUX_MASTER // MAG connected to the AUX I2C bus of MPU6050
to this: //#define MPU6050_I2C_AUX_MASTER // MAG connected to the AUX I2C bus of MPU6050

I ordered a 5v external 5883 mag board from ebay (about $3) and connected it to the I2C port (I2C are providing 5v).
I did mag calibration and gave 100% throttle with props installed - Not even 1 degree difference.


Thanks brewski, however I give up. Constant I2C errors when External Mag is plugged in. I know the FC was not damaged when onboard mag was removed however looking back, I should have simply cut the traces rather than remove the entire component.

I have tried using external pullup resistors, enable/disable internal pullups, hard wiring the SDA SCL lines etc. Nothing seems to work. All sensors other than the mag DO work however. Looks like I'll be ordering a new FC to replace this on. Is there a better option than the Crius AIOP or HK AIOP clones? Navigation is required.

brewski
Posts: 483
Joined: Tue Apr 29, 2014 12:04 am
Location: Cleveland Qld Australia

Re: GPS NAV

Post by brewski »

If all other onboard sensors (which connect using 12C bus) are functioning in MW Config & not giving 12C errors with ext mag disconnected then FC is fine. If you are getting 12C errors with the external mag board connected it could be wiring issue or faulty ext Mag board. I would try another Mag board before scrapping FC.
If FC is proved defective then from my experience stay away from the HK AIOP clones & pay a bit more for Crius AIOP V2.
As I mentioned, it is simple to disable onboard mag by just cutting jumper on pads. The only thing to be aware of though is like APM there is a diode in series with input +5 so you really need to feed it with a 5.5V UBec or if you have a UBec that is 6V selectable install another (Shottky) diode in series with 6V & you will end up with 5V to Atmega2560.

Bmays
Posts: 5
Joined: Sun Oct 05, 2014 11:08 pm

Re: GPS NAV

Post by Bmays »

I don't want to derail the thread but appreciate your assistance. I ordered a crius aiop v2 this evening. I may order a new mag as well just to be safe. The v1 FC functions fine except mag so I may use it in another non-gps build. Thanks again!

dragon/
Posts: 3
Joined: Mon Nov 03, 2014 1:27 pm

Re: GPS NAV

Post by dragon/ »

Hi! My first post. Be kind :lol:

I'm using eosbandi firmware (MultiWii 2.3navi B7 (2014/02/16)) and the wingui from his website. Everything seems fine, but i have questions:

1. How is waypoint altitude calculated? From GPS alt? Sometimes the flying altitude does alter from time to time, could be from gps noise or battery voltage... I'm guessing the wp alt is calculated from GPS alt when armed on ground...

2. Would it be possible for "wait for wp alt" and "wait for mag heading" options for navigation? Similar to "wait for RTH alt"


Heres a quick video from today! http://youtu.be/mgwDsxsfU1w

One waypoint was up to 20m. Really windy day.

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

Altitude is from the baro and relative to home position.

dragon/
Posts: 3
Joined: Mon Nov 03, 2014 1:27 pm

Re: GPS NAV

Post by dragon/ »

Ok, so its just a relative number to the baro reading at take off?

Nav alt seems a bit iffy to me, sometimes its off by 2-3meters after flying for 10min.

Edit. The auto land fuctions seems to work fine, but descending to waypoints is slow.

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: GPS NAV

Post by stronnag »

Somewhat less "iffy" than GPS altitude.
Last edited by stronnag on Mon Nov 03, 2014 9:33 pm, edited 1 time in total.

dragon/
Posts: 3
Joined: Mon Nov 03, 2014 1:27 pm

Re: GPS NAV

Post by dragon/ »

Nvm guys, I think i had the alt hold pids way too low. Increased p from 0.7 to 8 and D from 7 to 30 :D
Seems to help a lot with navigation altitude.

brewski
Posts: 483
Joined: Tue Apr 29, 2014 12:04 am
Location: Cleveland Qld Australia

Re: GPS NAV

Post by brewski »

stronnag wrote:Somewhat less "iffy" than GPS altitude.


I totally agree & more than a bit scared to try Patricks Airplane Nav code that ONLY uses GPS data for altitude.
Even with >9 sats on good solar day my Ublox 6m V2 GPS Altitude can be off by +/-8 metres!
I have run extensive tests with BS5611 Baro on my Crius AIOP V2 & although a factor of 10 better accuracy than BM085, it does drift considerably when module & board warms up. I believe the foam covering makes this worse as it traps heat. Drift can be several metres from cold & if you have unstable atmospheric pressure (a storm or front approaching) I have seen my hovering quad slowly descend or rise several metres & then level off due to atmospherics. Provided you allow several minutes for >6 sats confirmation from FC GPS LED this also allows the Baro temp to stabilise. If you are connected to EZ-GUI for telemetry as I definitely recommend, then you will see that you have accurate Home position superimposed on map with readout of GPS sats as well as Baro altitude. Unfortunately MW does not zero Baro on arming (as APM does) but If you know Home altitude is 3 metres you can allow for this.
You can zero Baro by reconnecting Lipo but then you will have to wait several minutes again to get home position accurate to several metres horizontal & even longer if using vertical accuracy.

elahi
Posts: 1
Joined: Wed Dec 10, 2014 10:09 pm

Re: GPS NAV

Post by elahi »

Hi all,

are there any way to disable all that new NAV code allowing 328 boards to use pure GPS at least for OSD but also benefit from other latest code improvements?

jmfixitman
Posts: 6
Joined: Sat Dec 06, 2014 3:13 am

Re: GPS NAV

Post by jmfixitman »

Hi All,

I have tried loading bandi's sketch (http://eosbandi.com/downloads) on my multiwii mega 2560 board. While I can get it to load, I cant arm my quadcopter, or get it to connect to the GUI unless I drop the speed to 57600. Once I drop the connection speed to 57600, then I can load the RC control settings, but it still wont arm? Anyone else had the same problem or know what I may be doing wrong? I bought the board from witespy, and can load his megaezgps sketch and fly, but I was hoping to get the better gps refresh rate of this sketch... Any ideas are appreciated! thanks!

brewski
Posts: 483
Joined: Tue Apr 29, 2014 12:04 am
Location: Cleveland Qld Australia

Re: GPS NAV

Post by brewski »

You need to uncomment as shown here
/******************************** ARM/DISARM *********************************/
/* optionally disable stick combinations to arm/disarm the motors.
* In most cases one of the two options to arm/disarm via TX stick is sufficient */
#define ALLOW_ARM_DISARM_VIA_TX_YAW
//#define ALLOW_ARM_DISARM_VIA_TX_ROLL

If you check your port speeds in Config.h I'm pretty sure that they are all set to 57600. Just set them all to 115200.
You don't want 115200 for GPS on port 2 but the port setting in GPS section will override the 115200. It is suggested to run GPS at 38400 for best accuracy & less errors.
Many GPS module come configured already set to this. If not you will have to set using FTDI adapter using UCentre assuming you have a UBlox GPS such as the Ne 6M. I also recommend using an ext mag. Check if you get any deviation in MWConfig when increasing throttle with props on & holding firmly from below. If more than 5 degrees use ext mag. Only $5 or you can get a GPS with Mag combo for less than $20

jmfixitman
Posts: 6
Joined: Sat Dec 06, 2014 3:13 am

Re: GPS NAV

Post by jmfixitman »

Thank you! You were right, that fixed the connection speed issue and it connects to the GUI perfectly! I still cant get it to arm though? I ended up using the old sketch and putting some of bandi's settings in configh... works!
Last edited by jmfixitman on Sat Dec 13, 2014 2:46 am, edited 1 time in total.

Post Reply