GPS NAV

ezio · Post by **ezio** » Sun Sep 21, 2014 9:08 am

carl1864 wrote:I'm trying this Nav version for the first time, but after hours, I cannot get it to work.

I had a fully working quad with multiwii 2.3, on a crius aiop board, and using the EZ Gui App to configure over bluetooth.

However after attempting to use this nav version, I am completely unable to connect to EZ Gui. I just get constant "No Data Recieved" Errors, even though I have nav protocol selected. I've tried the latest b7, as well as b5 baro fix. I cleared EEPROM multiple times, have compiled both nav versions multiple times, I made sure EZ Gui is updated, double checked all settings in config.h to match my working settings from version 2.3.

Anyone have any idea what the problem is?

Check serial speed in config.h
In nav version it is set to 57600 instead of 115200.

brewski · Post by **brewski** » Sun Sep 21, 2014 11:39 am

Yeah spot on Ezio. When I first loaded V2.3 Navi b7 my serial ports were incorrectly set so I just reset them to 115200. I noticed some other strange settings as well so I guess Andreas just uploaded the version he was running.

Hypermobile · Post by **Hypermobile** » Sun Sep 21, 2014 12:57 pm

Today i re-upgraded to Nav. Succesfully.

On my previous Quad...i had issues with onboard Mag sensor.
It was flying circles. (and went out of control).

Build another Quad with a External Mag & Gps antenna.
I also noticed that MAG calibration cann't be done Indoors. (i've never read that on the internet)
Problems are gone.

To double check the MAG ...i now use a analog Compass to confirm MAG is Right.

Today i flew my first mission. And put the GPS-result next to it.
It was very windy!

Thanks EOS!
Great piece of engineering!

EOSBandi · Post by **EOSBandi** » Sun Sep 21, 2014 6:17 pm

Well, you can try increase crosstrack gain to .5 - .7 and also increase the waypoint radius to 200cm.... with a bigger crosstrack gain, it will try to keep the calculated track more aggressively. And with a greater wp radius it will consider the wp reached if it within that radius...

Hypermobile · Post by **Hypermobile** » Mon Sep 22, 2014 8:02 am

EOSBandi wrote:Well, you can try increase crosstrack gain to .5 - .7 and also increase the waypoint radius to 200cm.... with a bigger crosstrack gain, it will try to keep the calculated track more aggressively. And with a greater wp radius it will consider the wp reached if it within that radius...

I'll try again with current settings in low wind.
And try another time with you suggestion.

and post the restults

thx anyway

ezio · Post by **ezio** » Mon Sep 22, 2014 8:33 am

EOSBandi wrote:Well, you can try increase crosstrack gain to .5 - .7 and also increase the waypoint radius to 200cm.... with a bigger crosstrack gain, it will try to keep the calculated track more aggressively. And with a greater wp radius it will consider the wp reached if it within that radius...

May I ask what crosstrack gain actually is and how it works?

EOSBandi · Post by **EOSBandi** » Mon Sep 22, 2014 9:01 am

ezio wrote:
EOSBandi wrote:Well, you can try increase crosstrack gain to .5 - .7 and also increase the waypoint radius to 200cm.... with a bigger crosstrack gain, it will try to keep the calculated track more aggressively. And with a greater wp radius it will consider the wp reached if it within that radius...

May I ask what crosstrack gain actually is and how it works?

Check this : http://jasonshort.com/crosstrack/CrossTrack2.html

Hypermobile · Post by **Hypermobile** » Mon Sep 22, 2014 8:45 pm

Increased the crosstrack gain today in the GUI.
It was Windy again. And the track was a little Tighter.
(logging failed unfortunately)

But i also noticed that Poshold was moving. I had it steady in the wind on Mw 2.3.
So i'll double check the values used over there.

But you didn't put "DO NOT TOUCH" there for no reason.

Code: Select all

// Weight factor of the crosstrack error in navigation calculations (do not touch)
  #define CROSSTRACK_GAIN            .4                  //(**)

!! Also noticed that saving WinGui Settings; and Reloading those again gave me error messages.
(I'm Back to screenshot to save setting). (Pre10 b7)

"Options file contains invalid data around LINE:47"

shikra · Post by **shikra** » Wed Sep 24, 2014 3:41 pm

Flew my first mission today. No tuning of baro PID or anything and it worked well...

Congrats to EOS for implementation.

My only question - I selected mission switch on copter whilst on ground - I thought it would rise straight up to alt of first waypoint and then progress to it. I guess thats not how it works as it wanted to head towards it whilst slightly climbing.
So basically launch manually then flick the mission switch. Works for me now I know!

Any consideration for the initial launch to rise to the next waypoint height instead of dragging along the floor??

EOSBandi · Post by **EOSBandi** » Wed Sep 24, 2014 8:09 pm

shikra wrote:Flew my first mission today. No tuning of baro PID or anything and it worked well...

Congrats to EOS for implementation.

My only question - I selected mission switch on copter whilst on ground - I thought it would rise straight up to alt of first waypoint and then progress to it. I guess thats not how it works as it wanted to head towards it whilst slightly climbing.
So basically launch manually then flick the mission switch. Works for me now I know!

Any consideration for the initial launch to rise to the next waypoint height instead of dragging along the floor??

It called autotakeoff and yes it is on the list

Hypermobile · Post by **Hypermobile** » Wed Sep 24, 2014 8:43 pm

Little issue in the Mission tab.

If you Select RTH > you get lat 0 long 0
If you change that to LAND it remains lat 0 long 0.

It will fly to Middle africa :roll:

...and Land if it will make it to there

Also got a display error, while zooming in on the last waypoint before this changed Land.

Yesterday is showed me a Land position nearby on the map (but in the table Lat 0 Long 0.
(cannot reproduce unfortunately).

i Got that mistake by Uploading & Downloading the mission.
So there was no problem.

But maybe change something so you cannot change RTH to something else.
Or get the Lat Long from the previous position.
or another better idea

DorsetFlyer · Post by **DorsetFlyer** » Thu Sep 25, 2014 8:48 am

I tried to initiate a mission from rest (with the throttle closed) but the props just spun up to what I suppose was MINTHROTTLE (1100) and it just set there. I assume this is a safety feature to prevent an inadvertent take off by mistakenly moving a switch. If so, I think that this is the right approach. Any implementation of auto take off needs to be thought through very thoroughly to avoid inadvertent activation.

shikra · Post by **shikra** » Thu Sep 25, 2014 9:30 am

EOSBandi wrote:It called autotakeoff and yes it is on the list

Your the man... Serious !

Just had second mission and tested RTH. All worked as expected. Nice one.

shikra · Post by **shikra** » Thu Sep 25, 2014 9:35 am

DorsetFlyer wrote:I tried to initiate a mission from rest (with the throttle closed) but the props just spun up to what I suppose was MINTHROTTLE (1100) and it just set there. I assume this is a safety feature to prevent an inadvertent take off by mistakenly moving a switch. If so, I think that this is the right approach. Any implementation of auto take off needs to be thought through very thoroughly to avoid inadvertent activation.

I think having to arm it first would be enough? Thats kinda saying you've done all checks etc and ready to go.
Also suggest perhaps not being able to arm if in mission mode? similar to not arming with baro active. Maybe its already there as not tested.

shikra · Post by **shikra** » Thu Sep 25, 2014 3:55 pm

@ EOSBandi - am adding some support into MWOSD for your navi software. Just to display waypoint / step no and that is on a mission. MAybe a bit more later.

I want to pull out the current waypoint or step number. Looking at MSP I thought it was this:
MSP_NAV_STATUS 4th byte (mission_step.number)

Is this correct MSP / byte - and should it change at each step?

On on a test mission this morning I did not see the 4th byte change. I have tried changing the byte with a simulator for this MSP and it looks OK. From 15 secs in:

Rust · Post by **Rust** » Thu Sep 25, 2014 6:39 pm

Hey Andras,
any plans to include the ACC in Position Hold? Seems to be one of the lacking features compared to naza/apm/harakiri?
Otherwise great work. I'm using your firmware exclusively with no problems so far!

EOSBandi · Post by **EOSBandi** » Fri Sep 26, 2014 2:42 pm

shikra wrote:@ EOSBandi - am adding some support into MWOSD for your navi software. Just to display waypoint / step no and that is on a mission. MAybe a bit more later.

I want to pull out the current waypoint or step number. Looking at MSP I thought it was this:
MSP_NAV_STATUS 4th byte (mission_step.number)

Is this correct MSP / byte - and should it change at each step?

On on a test mission this morning I did not see the 4th byte change. I have tried changing the byte with a simulator for this MSP and it looks OK. From 15 secs in:

Is should changed during mission execution. It always contains the number of the current mission step.
It could be also useful to display the NAV_state and the NAV_error...

EOSBandi · Post by **EOSBandi** » Fri Sep 26, 2014 2:44 pm

Rust wrote:Hey Andras,
any plans to include the ACC in Position Hold? Seems to be one of the lacking features compared to naza/apm/harakiri?
Otherwise great work. I'm using your firmware exclusively with no problems so far!

Do you mean the fusion of horizontal acceleration data with GPS position ?

shikra · Post by **shikra** » Fri Sep 26, 2014 10:31 pm

EOSBandi wrote:Is should changed during mission execution. It always contains the number of the current mission step.

Thanks. I think I figured it out. OSD receiving OK, but the request invalid, Compiler does not interpret bitshift for more than 16 bits :
#define REQ_MSP_NAV_STATUS (1 << 15)

I am now hopefull test flight will be OK :lol:

grrrr...

Rust · Post by **Rust** » Sat Sep 27, 2014 12:05 pm

EOSBandi wrote:
Rust wrote:Hey Andras,
any plans to include the ACC in Position Hold? Seems to be one of the lacking features compared to naza/apm/harakiri?
Otherwise great work. I'm using your firmware exclusively with no problems so far!

Do you mean the fusion of horizontal acceleration data with GPS position ?

Exactly

matster · Post by **matster** » Sun Sep 28, 2014 8:09 am

Hi, I wonder if someone could help me?

I'm very new to this, but have a managed to upload the navi B7 code onto my FC, gone through the set-up and am able to communicate with my FC on the pre10(b7) GUI, however I just can't seem to get a GPS signal. If I reload the normal 2.3 code, I get the GPS, but obviously, no additional functionality. I have tried copying the settings from the code that works to the navi B7 code, with no success.

I do get a blinking green light on the GPS section of the GUI, so it looks like its communicating, although, I'm not really sure if that means it's connected to the GPS or not.

I have the following FC: MultiWii PRO Flight Controller w/MTK GPS Module, https://www.hobbyking.com/hobbyking/store/__26588__MultiWii_PRO_Flight_Controller_w_MTK_GPS_Module.html, here's the general spec;
(MultiWii PRO)
• SMD component design with Atmega2560
• ITG3205 Triple Axis Gyro
• BMA180 Accelerometer
• BMP085 Barometer
• HMC5883L Magnetometer

GPS Module
(MTK 3329 GPS Module)
• Based on MediaTek Single Chip Architecture.
• L1 Frequency, C/A code, 66 channels
• High Sensitivity, Up to -165dBm tracking, providing superior urban performance
• DGPS(WAAS, EGNOS, MSAS) support (optional by firmware)
• USB/UART Interface
• Supports AGPS function (Offline mode: EPO valid up to 14 days)

The above, was just taken from the website, to save clicking on the link.

Any help would be appreciated, I'm sure it should work, I'm just missing something simple probably!

o_lampe · Post by **o_lampe** » Sun Sep 28, 2014 8:34 am

@matster
you probably missed the different baud rate for GPS in the NAV SW? In NAV SW every serialport is set to 115200, reduce it to 57600 ( or what has been set in the 2.3 SW ) and try again.

<edit> Don't forget to erase eeprom between flashing a different MWII SW. ( all 4096 Bytes )

matster · Post by **matster** » Sun Sep 28, 2014 8:44 am

Fixed it! It was a wiring fault lol, generated from my most recent crash! It must have just been a coincidence that it work when I had the old code loaded, then stopped after I loaded the new code! Thanks for the help though, it is appreciated!!

Hypermobile · Post by **Hypermobile** » Tue Sep 30, 2014 4:47 pm

Finally got my 2nd Mission logged; Looking pretty nice.

Last time...for some reason (my mistake of course) PID Nav was 20.0 instead of 2.0

Luckily there is a 'Banking limit' set to 45 degrees : 8-)

EOSBandi · Post by **EOSBandi** » Wed Oct 01, 2014 4:16 pm

Rust wrote:
EOSBandi wrote:
Rust wrote:Hey Andras,
any plans to include the ACC in Position Hold? Seems to be one of the lacking features compared to naza/apm/harakiri?
Otherwise great work. I'm using your firmware exclusively with no problems so far!

Do you mean the fusion of horizontal acceleration data with GPS position ?

Exactly

Well, for that we need horizontal acceleration data rotated to earth frame reference. I checked harakiri code, and that implementation is quite calculation expensive. Perhaps Alex can modify the IMU code to provide that data....

NNagib · Post by **NNagib** » Wed Oct 01, 2014 7:56 pm

I had a horrible crash today. Everything looked fine, until I switched on GPS Hold. That launched the copter like the projectile, and it hit the building. The damage was severe. I am frustrated because I spent a lot of time to tune the board (red multiwii pro from hk), PIDs etc. and the quad was stable and fine.

What could be the reason for this terrific flyaway?

NNagib · Post by **NNagib** » Wed Oct 01, 2014 8:03 pm

shikra wrote:@ EOSBandi - am adding some support into MWOSD for your navi software. Just to display waypoint / step no and that is on a mission. MAybe a bit more later.

I want to pull out the current waypoint or step number. Looking at MSP I thought it was this:
MSP_NAV_STATUS 4th byte (mission_step.number)

Is this correct MSP / byte - and should it change at each step?

On on a test mission this morning I did not see the 4th byte change. I have tried changing the byte with a simulator for this MSP and it looks OK. From 15 secs in:

I bought minim osd 1.1 from hk. Using the USBASP I flashed KV Osd and burnt the bootloader. I only have black screen on the output. No video pass from the camera (mobius) and no overlay at all. Do you have any idea what could be the reason. I tried everything

EOSBandi · Post by **EOSBandi** » Wed Oct 01, 2014 8:30 pm

NNagib wrote:I had a horrible crash today. Everything looked fine, until I switched on GPS Hold. That launched the copter like the projectile, and it hit the building. The damage was severe. I am frustrated because I spent a lot of time to tune the board (red multiwii pro from hk), PIDs etc. and the quad was stable and fine.

What could be the reason for this terrific flyaway?

What were your settings ?
How many sats did you saw ?
Did you calibrate mag correctly ?
Tested power influence on mag ?
Did you enabled angle and MAG mode also alongside with gps hold ?

And finally why did you tested it without enough free space ?

Rust · Post by **Rust** » Wed Oct 01, 2014 9:21 pm

EOSBandi wrote:
EOSBandi wrote:
Rust wrote:Do you mean the fusion of horizontal acceleration data with GPS position ?

Exactly

Well, for that we need horizontal acceleration data rotated to earth frame reference. I checked harakiri code, and that implementation is quite calculation expensive. Perhaps Alex can modify the IMU code to provide that data....

Hopefully!

NNagib · Post by **NNagib** » Wed Oct 01, 2014 10:13 pm

EOSBandi wrote:
NNagib wrote:I had a horrible crash today. Everything looked fine, until I switched on GPS Hold. That launched the copter like the projectile, and it hit the building. The damage was severe. I am frustrated because I spent a lot of time to tune the board (red multiwii pro from hk), PIDs etc. and the quad was stable and fine.

What could be the reason for this terrific flyaway?

What were your settings ?
How many sats did you saw ?
Did you calibrate mag correctly ?
Tested power influence on mag ?
Did you enabled angle and MAG mode also alongside with gps hold ?

And finally why did you tested it without enough free space ?

In fact, I wasn't testing - I was recording. Some reports of my previous tests were posted on ez-gui thread. I have full log of that flight (ez-gui) and I still don't understand what could be the reason, that's why I ask you. Everything was good, clear sky, 10 satellites.
How is it possible that simple GPS hold switch launches the copter as the projectile? Is it possible that EPROM became corrupted? How often do you clear all 4k of EPROM?

Tnx

DorsetFlyer · Post by **DorsetFlyer** » Thu Oct 02, 2014 2:01 pm

Hi NNagib, very sorry to hear about your crash. The cause may have been a faulty flight controller. I had a similar problem with the HK Red Board. Although my quad flew well, whenever I switched to a function involving BARO it shot off vertically and did not stop until I switched it off. I swapped the board for an HK Crius AIO clone, without making any changes to the settings, and the problem disappeared. Now all GPS functions work well. I sent the Red Board back to Hobby King and got a full refund.

NNagib · Post by **NNagib** » Thu Oct 02, 2014 6:00 pm

Thank you! I am thinking about switching to APM. I am not interested in another Multiwii board.

EDIT: I figured out what happened: log shows horrible GPS performance. It is Mediatek GPS. Despite the clear sky, the GPS data were horribly inaccurate and even the GPS fix was lost for short period. Mystery is solved, and my copter is broken. I collected parts and tried to assemble it again, but one ESC is dead (I replaced the capacitor with no luck). Now waiting for the parcel with new ESC and props ... I hope that FC has survived.

Alexinparis · Post by **Alexinparis** » Thu Oct 02, 2014 10:50 pm

EOSBandi wrote:Well, for that we need horizontal acceleration data rotated to earth frame reference. I checked harakiri code, and that implementation is quite calculation expensive. Perhaps Alex can modify the IMU code to provide that data....

Hi,

I think this data is quite simple to get:
just insert this piece of code somewhere in getEstimatedAttitude()

Code: Select all

debug[0] = (EstG.V16.X-imu.accSmooth[ROLL])/cos(PI/1800*att.angle[ROLL]);
debug[1] = (EstG.V16.Y-imu.accSmooth[PITCH])/cos(PI/1800*att.angle[PITCH]);

imu.accSmooth can be replaced by imu.accADC for unfiltered ACC

the way to integrate this for a XY ACC POS HOLD is another story

Bmays · Post by **Bmays** » Sun Oct 05, 2014 11:17 pm

For my build I'm using https://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=49274
With the neo-6m GPS module.

Ive read about two different baud rates mentioned (57600 and 115200) so 57600 should be set?

brewski · Post by **brewski** » Tue Oct 07, 2014 8:52 pm

Bmays wrote:For my build I'm using https://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=49274
With the neo-6m GPS module.

Ive read about two different baud rates mentioned (57600 and 115200) so 57600 should be set?

I suggest using 38400 baud which gives best accuracy (see below from config.h) & I've proved this in tests I've run.
If your UBlox 6m was advertised for MW then it should already be set to 38400. If not use UCentre to set baud rate.

#define GPS_SERIAL 2 // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
//#define GPS_PROMINI_SERIAL // Will Autosense if GPS is connected when ardu boots.

// avoid using 115200 baud because with 16MHz arduino the 115200 baudrate have more than 2% speed error (57600 have 0.8% error)
#define GPS_BAUD 38400

/* GPS protocol
NMEA - Standard NMEA protocol GGA, GSA and RMC sentences are needed
UBLOX - U-Blox binary protocol, use the ublox config file (u-blox-config.ublox.txt) from the source tree
MTK_BINARY16 and MTK_BINARY19 - MTK3329 chipset based GPS with DIYDrones binary firmware (v1.6 or v1.9)
With UBLOX and MTK_BINARY you don't have to use GPS_FILTERING in multiwii code !!! */

//#define NMEA
#define UBLOX
//#define MTK_BINARY16
//#define MTK_BINARY19
//#define INIT_MTK_GPS // initialize MTK GPS for using selected speed, 5Hz update rate and GGA & RMC sentence or binary settings

Hypermobile · Post by **Hypermobile** » Wed Oct 08, 2014 9:14 am

Useful tip for Multiwii Nav Users:

I've made a adjustement for the 6 position Modification found here:
http://diydrones.com/profiles/blogs/universal-6-position-mode-switch-for-any-tx

I added a Action button...So you can now Pre-select a 5 other Flightmodes.
(i've got only 1 AUX left for Flighmodes).

When Tuning PID for Mission or RTH or PosHold.... it's useful to abort the mission quickly when something goes wrong. (Rotating the Pos Switch is slow).
I almost lost my quad rotating the switch...with a Flip switch...Less drama

kenl · Post by **kenl** » Mon Oct 13, 2014 12:25 am

Is the POI function working in this release?
I have only set it once, after the first way point, and then flown around the the POI with a set of 6 waypoints.
The quad always faces the direction of travel and not the POI, in my case.

Thanks

brewski · Post by **brewski** » Mon Oct 13, 2014 4:01 am

NNagib wrote:Thank you! I am thinking about switching to APM. I am not interested in another Multiwii board.

EDIT: I figured out what happened: log shows horrible GPS performance. It is Mediatek GPS. Despite the clear sky, the GPS data were horribly inaccurate and even the GPS fix was lost for short period. Mystery is solved, and my copter is broken. I collected parts and tried to assemble it again, but one ESC is dead (I replaced the capacitor with no luck). Now waiting for the parcel with new ESC and props ... I hope that FC has survived.

I also suggest replacing your Mediatek with UBlox Neo6m V2. Make sure you get the V2 with larger rechargeable battery as V1 goes flat in a couple of days.
Before I arm I wait for at least 5flashed from GPS status Hi Intensity LED ( from LED on my Crius AIOP V2). This means at least 8sats lock. I then check quad position on EZ-GUI to see that home position is actually correct. You also get accurate number of sats shown in EZ-GUI. If you follow this routine you will never have a flyaway unless something goes radically wrong with FC or GPS.

EOSBandi · Post by **EOSBandi** » Tue Oct 14, 2014 3:57 am

brewski wrote:
NNagib wrote:Thank you! I am thinking about switching to APM. I am not interested in another Multiwii board.

EDIT: I figured out what happened: log shows horrible GPS performance. It is Mediatek GPS. Despite the clear sky, the GPS data were horribly inaccurate and even the GPS fix was lost for short period. Mystery is solved, and my copter is broken. I collected parts and tried to assemble it again, but one ESC is dead (I replaced the capacitor with no luck). Now waiting for the parcel with new ESC and props ... I hope that FC has survived.

I also suggest replacing your Mediatek with UBlox Neo6m V2. Make sure you get the V2 with larger rechargeable battery as V1 goes flat in a couple of days.
Before I arm I wait for at least 5flashed from GPS status Hi Intensity LED ( from LED on my Crius AIOP V2). This means at least 8sats lock. I then check quad position on EZ-GUI to see that home position is actually correct. You also get accurate number of sats shown in EZ-GUI. If you follow this routine you will never have a flyaway unless something goes radically wrong with FC or GPS.

I can agree with the above. GPS glitch detection is always on my list (which is longer and longer day by day

)

EOSBandi · Post by **EOSBandi** » Tue Oct 14, 2014 3:59 am

kenl wrote:Is the POI function working in this release?
I have only set it once, after the first way point, and then flown around the the POI with a set of 6 waypoints.
The quad always faces the direction of travel and not the POI, in my case.

Thanks

MAG mode most be enabled to make POI work....

kenl · Post by **kenl** » Tue Oct 14, 2014 1:37 pm

Thank you for the reply EOSBandi,
I am pretty sure that I didn't have Mag enabled with my mission, should I assume that all missions should have Mag enabled, and does it matter where in the mission the POI is set?
Also, if I may............. How often do I need to calibrate my Mag? At the moment I do it every flight, sometimes with good results and sometimes not so good..

psitana · Post by **psitana** » Thu Oct 16, 2014 10:40 am

can anybody help me what i must do ?, I try to setup gps multiwii SE 2.5, i2c with neo6m module, when i see in configuration the gps have fix but when i move tuning in aux GPS hold and GPS home always red

brewski · Post by **brewski** » Thu Oct 16, 2014 10:56 am

Are you doing this outside, well away from buildings, trees etc with clear view of sky?
Initial fix requires up to 30 minutes to build up constellation map which is stored in UBlox. This must be done under ideal conditions. After UBlox has stored constellation map this data is backed up for several days (Mk1) or several weeks (MK2 with larger battery) & you should get a 3D fix from cold start in open view in approx. 60 seconds. When you have a 3D fix of 5 or more satellites (I don't arm until I see at least 6) you can start to set & use GPS functions.

o_lampe · Post by **o_lampe** » Thu Oct 16, 2014 4:53 pm

psitana wrote: I try to setup gps multiwii SE 2.5, i2c with neo6m module,

I2C is no longer supported with the GPS Nav_b7 version.

dfruehwald · Post by **dfruehwald** » Thu Oct 16, 2014 6:46 pm

Do the GPS Nav versions have the latest S.Bus support that is in 2.3 - 1648?

-ralf- · Post by **-ralf-** » Thu Oct 16, 2014 6:57 pm

o_lampe wrote:
psitana wrote: I try to setup gps multiwii SE 2.5, i2c with neo6m module,

I2C is no longer supported with the GPS Nav_b7 version.

Have a look at r1717

Leo · Post by **Leo** » Thu Oct 16, 2014 7:37 pm

-ralf- wrote:
o_lampe wrote:
psitana wrote: I try to setup gps multiwii SE 2.5, i2c with neo6m module,

I2C is no longer supported with the GPS Nav_b7 version.

Have a look at r1717

Nice

ezio · Post by **ezio** » Fri Oct 17, 2014 2:34 am

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 !

Code: Select all

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

Code: Select all

/*************baseflight***************
//   #define CAP_PLATFORM_32BIT          ((uint32_t)1 << 31)
//   #define CAP_BASEFLIGHT_CONFIG       ((uint32_t)1 << 30)
//   #define CAP_DYNBALANCE              ((uint32_t)1 << 2)
//   #define CAP_FLAPS                   ((uint32_t)1 << 3)
   /*****************************************/

Code: Select all

/****************cleanflight******************
   // #define CAP_DYNBALANCE ((uint32_t)1 << 2)
   // #define CAP_FLAPS ((uint32_t)1 << 3)
   // #define CAP_CHANNEL_FORWARDING ((uint32_t)1 << 4)
   // #define CAP_PLATFORM_32BIT ((uint32_t)1 << 31)
   // +#define CAP_BASEFLIGHT_CONFIG ((uint32_t)1 << 30)
   // +#define CAP_CLEANFLIGHT_CONFIG ((uint32_t)1 << 29)
   /**********************************************/

Leo · Post by **Leo** » Fri Oct 17, 2014 7:49 am

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

Leo · Post by **Leo** » Fri Oct 17, 2014 7:55 am

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