GPS NAV

jANjALANi · Post by **jANjALANi** » Wed Mar 12, 2014 6:04 pm

Now i love my multiwii even better than my APM 2.5 thanks for this EOSBandi!

Quick question... how many waypoints can you have in a mission? what is the maximum? thanks!

Hypermobile · Post by **Hypermobile** » Wed Mar 12, 2014 6:10 pm

Bluetooth problem solved by Serial Speed in config.h

Calibrated the quad. let it sit for a while to get Satelites
Just tried a little mission.
(mission was double checked by downloading from the quad).

Flipped the Mission switch, And the quad was drifting away, fast... faster....WHAAAAA!!!
I quickly Flipped the Mission switch.
And i was JUST be able to recover the Quad from crashing bad.

AUX 's functions , Angle On, Horinzon ON, Mission ON.
(for most stable flight Horizon only?)

i've no Idea at the moment what happened. unfortunately...my GoPro SD was Full so no footage

Hypermobile · Post by **Hypermobile** » Wed Mar 12, 2014 6:51 pm

I just did another GPS Hold Test....But Only Horizon and every off...is more stable then with the GPS Hold on...

But i was hoovering above the ground....and Suddenly is flip 180 Degrees...and it was on the ground..

Instant Engine Failure (Hobbyking NTM series).... (not structrual damage

this time...Footage i'll post later).

I think if other People have good Pos Hold and can Fly Mission....Poiting to Firmware is not fair.
I would say...maybe the engine was giving some trouble earlier today. (more resitance or what so ever).

wareck · Post by **wareck** » Wed Mar 12, 2014 10:16 pm

Hi
I fly with his version since Christmas.
In order to have good result you must:

-fly in accro to tune your general PID
-Fly in horizon or angle to adjust level pid and digital trim
-when it's good, calibrate acc and mag
-tune GPS HOLD (must be accurate without and with Wind)
-tune baro (baro is needed for mission fly)

and after that your can try RTH an mission...
If you miss one of this step, fly in autonomous is dangerous...

scrat · Post by **scrat** » Thu Mar 13, 2014 8:05 am

wareck wrote:Hi
I fly with his version since Christmas.
In order to have good result you must:

-fly in accro to tune your general PID
-Fly in horizon or angle to adjust level pid and digital trim
-when it's good, calibrate acc and mag
-tune GPS HOLD (must be accurate without and with Wind)
-tune baro (baro is needed for mission fly)

and after that your can try RTH an mission...
If you miss one of this step, fly in autonomous is dangerous...

I think you have to calibrate acc and mag first. If you trim your copter in ANGLE mode and after that you calibrate ACC...trim is gone. So first thing is to calibrate ACC.

o_lampe · Post by **o_lampe** » Thu Mar 13, 2014 8:52 am

Hypermobile wrote:...
Flipped the Mission switch, And the quad was drifting away, fast... faster....WHAAAAA!!!
I quickly Flipped the Mission switch.
And i was JUST be able to recover the Quad from crashing bad.
...

After several missions successfully solved, I had the same problem with a dissappearing copter.
The only thing I changed in the code was, adding the beeper. The mission was still there after flashing. ( No CRC error message like I have seen before )
I didn't erase the eeprom before i flashed the new code, which in my opinion leads to a fatal error.

BTW: There is a program to erase eeprom in the arduino IDE. But it isn't erasing the whole memory of a Mega2560!!
How big is the eeprom in a mega2560??

<edit> just googled the eeprom size is 4kb= 4096 Byte. The code should be:

Code: Select all

/*
 * EEPROM Clear FOR ATMEGA2560
 *
 * Sets all of the bytes of the EEPROM to 0.
 * This example code is in the public domain.

 */

#include <EEPROM.h>

void setup()
{
  // write a 0 to all 4096 bytes of the EEPROM
  for (int i = 0; i < 4096; i++)
    EEPROM.write(i, 0);
    
  // turn the LED on when we're done
  digitalWrite(13, HIGH);
}

void loop()
{
}

Is that correct?

Hypermobile · Post by **Hypermobile** » Thu Mar 13, 2014 10:21 am

scrat wrote:
wareck wrote:Hi
I fly with his version since Christmas.
In order to have good result you must:

-fly in accro to tune your general PID
-Fly in horizon or angle to adjust level pid and digital trim
-when it's good, calibrate acc and mag
-tune GPS HOLD (must be accurate without and with Wind)
-tune baro (baro is needed for mission fly)

and after that your can try RTH an mission...
If you miss one of this step, fly in autonomous is dangerous...

I think you have to calibrate acc and mag first. If you trim your copter in ANGLE mode and after that you calibrate ACC...trim is gone. So first thing is to calibrate ACC.

Flying in Horizon was good. Mag & ACC were fresh calibrated.
But i think the Motor Mashed up some stability.

anyone suggestions for the new motors?
2.2 KG quad
1045 Carbon props
4S Lipo
30A ESC

Crash video.
http://youtu.be/Pk5Z6oaU66g

engamila · Post by **engamila** » Thu Mar 13, 2014 4:43 pm

Guys,I have a problem.Before switch to mission mode we need to drift the copter some height to increasing throttle?Can't we switch to mission mode in ground level?(without increasing throttle).

BKLronin · Post by **BKLronin** » Fri Mar 14, 2014 10:57 am

Hi!
Little question, is it possible to read out a state if a waypoint is reached? Need to transmit that to an Raspi via MSP. As far as I understood that part of MSP isn't complete yet?

dieterke · Post by **dieterke** » Fri Mar 14, 2014 6:27 pm

Hi
I use the MultiWii 2.3-navi-b5-baroFix - 5th beta and I'm verry happy with it. This evening I try my firs Mission with Landing. The Mission works verry good but the landing was funny. He lands and goes a long time up and down and the Motors don't stop. At the end he rolled over but it was nothing broken. The other thing is in RTH with " landing" button on but he don't land.
Is this normal in this Software Version?

Dieter

Hypermobile · Post by **Hypermobile** » Sat Mar 15, 2014 6:30 pm

o_lampe wrote:
Hypermobile wrote:...
Flipped the Mission switch, And the quad was drifting away, fast... faster....WHAAAAA!!!
I quickly Flipped the Mission switch.
And i was JUST be able to recover the Quad from crashing bad.
...

After several missions successfully solved, I had the same problem with a dissappearing copter.
The only thing I changed in the code was, adding the beeper. The mission was still there after flashing. ( No CRC error message like I have seen before )
I didn't erase the eeprom before i flashed the new code, which in my opinion leads to a fatal error.

BTW: There is a program to erase eeprom in the arduino IDE. But it isn't erasing the whole memory of a Mega2560!!
How big is the eeprom in a mega2560??

<edit> just googled the eeprom size is 4kb= 4096 Byte. The code should be:
Code: Select all
/*
 * EEPROM Clear FOR ATMEGA2560
 *
 * Sets all of the bytes of the EEPROM to 0.
 * This example code is in the public domain.

 */

#include <EEPROM.h>

void setup()
{
  // write a 0 to all 4096 bytes of the EEPROM
  for (int i = 0; i < 4096; i++)
    EEPROM.write(i, 0);
    
  // turn the LED on when we're done
  digitalWrite(13, HIGH);
}

void loop()
{
}
Is that correct?

I Didn't CLEAR EEPROM before uploading the new firmware. So that is the Same as in you case.

But maybe a good thing to do it every time you reflash; It doesn't hurt anybody if you do it.
And maybe (not sure) you can hurt someone if you don't.
Good to know i'm not the only one.

PID's were tested earlier, and it was stabile. (GPS HOLD & BARO; Hand free flying)

Just bought 4 new RCTimer 2830-14 750 KV (should be the same as TBS 750KV rebranded),
and to be sure 1 new ESC, of the Burned out Motor.

EOSBandi · Post by **EOSBandi** » Mon Mar 17, 2014 6:55 pm

Hypermobile wrote:
o_lampe wrote:
Hypermobile wrote:...
Flipped the Mission switch, And the quad was drifting away, fast... faster....WHAAAAA!!!
I quickly Flipped the Mission switch.
And i was JUST be able to recover the Quad from crashing bad.
...

After several missions successfully solved, I had the same problem with a dissappearing copter.
The only thing I changed in the code was, adding the beeper. The mission was still there after flashing. ( No CRC error message like I have seen before )
I didn't erase the eeprom before i flashed the new code, which in my opinion leads to a fatal error.

BTW: There is a program to erase eeprom in the arduino IDE. But it isn't erasing the whole memory of a Mega2560!!
How big is the eeprom in a mega2560??

<edit> just googled the eeprom size is 4kb= 4096 Byte. The code should be:
Code: Select all
/*
 * EEPROM Clear FOR ATMEGA2560
 *
 * Sets all of the bytes of the EEPROM to 0.
 * This example code is in the public domain.

 */

#include <EEPROM.h>

void setup()
{
  // write a 0 to all 4096 bytes of the EEPROM
  for (int i = 0; i < 4096; i++)
    EEPROM.write(i, 0);
    
  // turn the LED on when we're done
  digitalWrite(13, HIGH);
}

void loop()
{
}
Is that correct?
I Didn't CLEAR EEPROM before uploading the new firmware. So that is the Same as in you case.

But maybe a good thing to do it every time you reflash; It doesn't hurt anybody if you do it.
And maybe (not sure) you can hurt someone if you don't.
Good to know i'm not the only one.

PID's were tested earlier, and it was stabile. (GPS HOLD & BARO; Hand free flying)

Just bought 4 new RCTimer 2830-14 750 KV (should be the same as TBS 750KV rebranded),
and to be sure 1 new ESC, of the Burned out Motor.

I don't want to be rude, but I cannot put countermeasures into the code against gross negligence.....
If you reflash your controller NEVER assume that your EEPROM content is still valid, and most importantly NEVER assume that your mission is still valid.
Before initiate mission ALWAYS read back your mission to the GUI.

engamila · Post by **engamila** » Mon Mar 17, 2014 7:22 pm

Hello EOSBandi and all

When I try a mission using multiwii 2.3 navb7 version(Released 16/02/2014) unexpected thing happened.First I upload FC to one way point(altitude 10m) and RTH point.Then I drift the quad using throttle and after that I activate the mission.In this situation quad suddenly drift to some height (Not way point height) and come to the ground.(Not RTH).Again drift around 1m and felt down to the ground.

Second time I delete all the way points.After that I drift the quad increasing throttle(around 10m) and switched to auto land.In this situation quad lower down 2 -3m and suddenly lift more than 20m unexpectedly fly away at-least 1km. Fortunately we could find the quad.

I switched both auto-land and baro mode in same time.In the first case switched both mission and baro same time.What is the wrong in these steps? Please help me.!!!!!

EOSBandi · Post by **EOSBandi** » Mon Mar 17, 2014 7:26 pm

engamila wrote:Hello EOSBandi and all

When I try a mission using multiwii 2.3 navb7 version(Released 16/02/2014) unexpected thing happened.First I upload FC to one way point(altitude 10m) and RTH point.Then I drift the quad using throttle and after that I activate the mission.In this situation quad suddenly drift to some height (Not way point height) and come to the ground.(Not RTH).Again drift around 1m and felt down to the ground. Second time I delete all the way points.After that I drift the quad increasing throttle(around 10m) and switched to auto land.In this situation quad lower down 2 -3m and suddenly lift more than 20m unexpectedly fly away at-least 1km. Fortunately we could find the quad. I switched both auto-land and baro mode in same time.In the first case switched both mission and baro same time.What is the wrong in these steps? Please help me.!!!!!

Was your copter well trimmed ?
POSHOLD, ALTHOLD ANGLE and MAG modes were tested and working before you tried mission ?

Hypermobile · Post by **Hypermobile** » Mon Mar 17, 2014 8:13 pm

I don't want to be rude, but I cannot put countermeasures into the code against gross negligence.....
If you reflash your controller NEVER assume that your EEPROM content is still valid, and most importantly NEVER assume that your mission is still valid.
Before initiate mission ALWAYS read back your mission to the GUI.

hi Eos,
I actually did Clear the mission in WinGui, and Downloaded the mission from the quad to check to be sure is was Alright.

but is was also thinking...(found it on a Dutch Multicopter Site...)...Maybe you get interference with Solar storms?

http://www.hoogtezicht.nl/multirotors/m ... m-activity
and
http://www.hoogtezicht.nl/multirotors/m ... kopter-gps

There is a picture of a stationary Quad during a sun storm...
Gps Measured a traveling distance of 64 Meters, and speeds of 10 m/s

That would be a reasonable reason. or what do you think?

Just thinking, Maybe for a new feature in Wingui?!
Solar Storm Activity flying advice. The Information is available online.

EOSBandi · Post by **EOSBandi** » Mon Mar 17, 2014 8:19 pm

Hypermobile wrote:
I don't want to be rude, but I cannot put countermeasures into the code against gross negligence.....
If you reflash your controller NEVER assume that your EEPROM content is still valid, and most importantly NEVER assume that your mission is still valid.
Before initiate mission ALWAYS read back your mission to the GUI.

hi Eos,
I actually did Clear the mission in WinGui, and Downloaded the mission from the quad to check to be sure is was Alright.

but is was also thinking...(found it on a Dutch Multicopter Site...)...Maybe you get interference with Solar storms?

http://www.hoogtezicht.nl/multirotors/m ... m-activity
and
http://www.hoogtezicht.nl/multirotors/m ... kopter-gps

There is a picture of a stationary Quad during a sun storm...
Gps Measured a traveling distance of 64 Meters, and speeds of 10 m/s

That would be a reasonable reason. or what do you think?

Just thinking, Maybe for a new feature in Wingui?!
Solar Storm Activity flying advice. The Information is available online.

Well, it called gps glitch detection, and it is already sketched up.... it definitely will be implemented before final release.

Hypermobile · Post by **Hypermobile** » Mon Mar 17, 2014 8:47 pm

EOSBandi wrote:
Hypermobile wrote:
I don't want to be rude, but I cannot put countermeasures into the code against gross negligence.....
If you reflash your controller NEVER assume that your EEPROM content is still valid, and most importantly NEVER assume that your mission is still valid.
Before initiate mission ALWAYS read back your mission to the GUI.

hi Eos,
I actually did Clear the mission in WinGui, and Downloaded the mission from the quad to check to be sure is was Alright.

but is was also thinking...(found it on a Dutch Multicopter Site...)...Maybe you get interference with Solar storms?

http://www.hoogtezicht.nl/multirotors/m ... m-activity
and
http://www.hoogtezicht.nl/multirotors/m ... kopter-gps

There is a picture of a stationary Quad during a sun storm...
Gps Measured a traveling distance of 64 Meters, and speeds of 10 m/s

That would be a reasonable reason. or what do you think?

Just thinking, Maybe for a new feature in Wingui?!
Solar Storm Activity flying advice. The Information is available online.

Well, it called gps glitch detection, and it is already sketched up.... it definitely will be implemented before final release.

my trouble happened 13 march...KP over 4...Unstable

So it does make a lot of sense to me know.

Keep up the good work!

ezio · Post by **ezio** » Sun Mar 23, 2014 4:58 pm

Yesterday I tried a mission with POI, but the copter heading stayed the same all the time. Could someone explain me how the POI works?

Also autolanding should cut off the motors?

ezio · Post by **ezio** » Sun Mar 23, 2014 5:26 pm

just to let you know that there are two ovarlapping MSP commands:
MultiWii_shared:
#define MSP_ACC_TRIM 121 //out message get acc angle trim values
#define MSP_SET_ACC_TRIM 215 //in message set acc angle trim values

Nav beta7:
#define MSP_NAV_STATUS 121 //out message Returns navigation status
#define MSP_SET_NAV_CONFIG 215 //in message Sets nav config parameters - write to the eeprom

I've wrote about it here viewtopic.php?f=8&t=4574&start=10#p48160
but nobody cares.

Bart

stronnag · Post by **stronnag** » Sun Mar 23, 2014 9:38 pm

Seconded. Please can we avoid fragmentation and have some agreement on this, otherwise producing generic user interfaces becomes impossible.

As the changes in shared have yet (AFAIK) to be in a released MW, and -nav is a beta, perhaps before there is too much confusion could the authors agree to follow 'first implementation sets the rules' along the lines of:

MSP_ACC_TRIM / MSP_SET_ACC_TRIM : follow the lead of baseflight / timecop as that's the first implementation.
MSP_NAV_STATUS / MSP_SET_NAV_CONFIG : follow lead of -nav / eosbandi.

before it's too late and we can still avoid fragmentation.

engamila · Post by **engamila** » Mon Mar 24, 2014 4:57 am

Hello EOSBandi and all
There is a error on Multiwii 2.3 navb7 in Baro mode.Yesterday I lost my code due to this error.

What I do is after arming the quad switched to angle and mag modes.Then I drift my quad using RC.After that I switched to the baro mode.Before switched to baro mode it was at around 3m height from ground level.when I was switche d to baro mode suddenly it drifted around 25m and fly away.What was this? :?:

brm · Post by **brm** » Wed Mar 26, 2014 8:20 pm

houston, we have a problem...

************* Ausnahmetext **************
System.ArgumentOutOfRangeException: Der Wert 4 ist für Value ungültig. Value sollte zwischen 'Minimum' und 'Maximum' liegen.
Parametername: Value
bei System.Windows.Forms.NumericUpDown.set_Value(Decimal value)
bei MultiWiiWinGUI.mainGUI.update_gui() in z:\VS-projects\mw-wingui\MultiWiiWinGUI\mainGUI.cs:Zeile 2055.
bei MultiWiiWinGUI.mainGUI.b_connect_Click(Object sender, EventArgs e) in z:\VS-projects\mw-wingui\MultiWiiWinGUI\communication.cs:Zeile 240.
bei System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
bei System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
bei System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
bei System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
bei System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
bei System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
bei System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ScrollableControl.WndProc(Message& m)
bei System.Windows.Forms.ToolStrip.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

csurf · Post by **csurf** » Thu Mar 27, 2014 7:02 am

I'd like to please make a feature request for WinGUI...
please add a 'baro calibration' button in order to manually re-calibrate the barometer.

It's currently possible to do a baro/gyro calibration using the sticks, but I'm not sure if the serial protocol supports initiating barometer calibration separately. I believe this would require some sort of change to the serial protocol in order to be able to increase the 'calibratingB' variable that controls the baro calibration... Again, I'm not sure if the serial protocol currently supports this, though I doubt it...

The barometer sensors are subject to heat-induced drift due to the MWC board/PCB gradually heating up to its working temperature after being powered on. So, it would be helpful to be able to click a button and manually recalibrate the barometer after the board temperature has stabilized...

FYI, the APM supports doing a manual, general pre-flight calibration which also includes baro calibration.

As a side note, I find it somewhat strange that barometer calibration was setup this way (it depends upon the value of a global variable), instead of having a separate 'calibrateBaro()' function that can be called at will...

EOSBandi · Post by **EOSBandi** » Thu Mar 27, 2014 2:36 pm

csurf wrote:I'd like to please make a feature request for WinGUI...
please add a 'baro calibration' button in order to manually re-calibrate the barometer.

It's currently possible to do a baro/gyro calibration using the sticks, but I'm not sure if the serial protocol supports initiating barometer calibration separately. I believe this would require some sort of change to the serial protocol in order to be able to increase the 'calibratingB' variable that controls the baro calibration... Again, I'm not sure if the serial protocol currently supports this, though I doubt it...

The barometer sensors are subject to heat-induced drift due to the MWC board/PCB gradually heating up to its working temperature after being powered on. So, it would be helpful to be able to click a button and manually recalibrate the barometer after the board temperature has stabilized...

FYI, the APM supports doing a manual, general pre-flight calibration which also includes baro calibration.

As a side note, I find it somewhat strange that barometer calibration was setup this way (it depends upon the value of a global variable), instead of having a separate 'calibrateBaro()' function that can be called at will...

Gyro's are suffering the same temperature induced drift, so it is quite OK to calibrate gyro's and barometers simultaneously, and you HAVE to calibrate gyros too when temperature changes...

EOSBandi · Post by **EOSBandi** » Thu Mar 27, 2014 2:43 pm

For all : Sorry for the delays, the budgeting period started at my work, so i'll be swamped with work till April 15th... I'll be back then...

csurf · Post by **csurf** » Thu Mar 27, 2014 2:59 pm

EOSBandi wrote:
csurf wrote:I'd like to please make a feature request for WinGUI...
please add a 'baro calibration' button in order to manually re-calibrate the barometer.

It's currently possible to do a baro/gyro calibration using the sticks, but I'm not sure if the serial protocol supports initiating barometer calibration separately. I believe this would require some sort of change to the serial protocol in order to be able to increase the 'calibratingB' variable that controls the baro calibration... Again, I'm not sure if the serial protocol currently supports this, though I doubt it...

The barometer sensors are subject to heat-induced drift due to the MWC board/PCB gradually heating up to its working temperature after being powered on. So, it would be helpful to be able to click a button and manually recalibrate the barometer after the board temperature has stabilized...

FYI, the APM supports doing a manual, general pre-flight calibration which also includes baro calibration.

As a side note, I find it somewhat strange that barometer calibration was setup this way (it depends upon the value of a global variable), instead of having a separate 'calibrateBaro()' function that can be called at will...

Gyro's are suffering the same temperature induced drift, so it is quite OK to calibrate gyro's and barometers simultaneously, and you HAVE to calibrate gyros too when temperature changes...

ok, understood...
In that case, please consider adding a 'calibrate gyros/baro' button to the GUI & protocol that will take care of calibrating both...

csurf · Post by **csurf** » Thu Mar 27, 2014 3:33 pm

another quick question about RTH...
I'm looking at the code and trying to understand what happens during a GPS NAV event, such as RTH, if the GPS fix is temporarily lost (possibly due to issues with the serial link and/or if the sat count drops below 5).

For example, it *appears* that an RTH action will be completely aborted if the # of sat's drops below 5 or if the GPS fix is lost. Is this correct or incorrect?

If so, would it be possible to instead attempt to temporarily do an alt/pos hold in order to see if the fix comes back, and/or attempt to auto-land if the GPS fix/sat count doesn't improve within a pre-configured timeout???

It seems pretty dangerous & scary that an RTH/NAV event will be instantly & completely aborted if there are any issues with the GPS readings... What, then, happens to the quad? What throttle/control values will be passed on to it? It seems like a high risk for a fly-away or crash...it would be safer to at least try to do an alt-hold or land gracefully...

EOSBandi · Post by **EOSBandi** » Thu Mar 27, 2014 7:44 pm

csurf wrote:another quick question about RTH...
I'm looking at the code and trying to understand what happens during a GPS NAV event, such as RTH, if the GPS fix is temporarily lost (possibly due to issues with the serial link and/or if the sat count drops below 5).

For example, it *appears* that an RTH action will be completely aborted if the # of sat's drops below 5 or if the GPS fix is lost. Is this correct or incorrect?

If so, would it be possible to instead attempt to temporarily do an alt/pos hold in order to see if the fix comes back, and/or attempt to auto-land if the GPS fix/sat count doesn't improve within a pre-configured timeout???

It seems pretty dangerous & scary that an RTH/NAV event will be instantly & completely aborted if there are any issues with the GPS readings... What, then, happens to the quad? What throttle/control values will be passed on to it? It seems like a high risk for a fly-away or crash...it would be safer to at least try to do an alt-hold or land gracefully...

Two cases :
GPS fix lost : It is very likely a HW error. The assumptions (and experience) says that it will not fix itself in the fly... so aborting gps assisted modes is the only option. Without GPS there is no poshold, and without poshold autoland is very close to a semi controlled crash landing (it is more than likely that it will flip over at land....)
Throttle and RC control ALWAYS passed to the copter (even during navigation) so when you see the gps error then you simply fly home via rc controls... (Out of sight flying is prohibited or will be prohibited in many countries)

GPS satnum below five... it is usually a temporary event, so RTH or NAV is just paused till sats raised above 5. Why pause ? Since with 5 sats or below poshold is a crazy horse in a 20x20 meter area.... as always you will have an error message and you can decide what would you do.

csurf · Post by **csurf** » Fri Mar 28, 2014 10:05 am

EOSBandi wrote:
csurf wrote:another quick question about RTH...
I'm looking at the code and trying to understand what happens during a GPS NAV event, such as RTH, if the GPS fix is temporarily lost (possibly due to issues with the serial link and/or if the sat count drops below 5).

For example, it *appears* that an RTH action will be completely aborted if the # of sat's drops below 5 or if the GPS fix is lost. Is this correct or incorrect?

If so, would it be possible to instead attempt to temporarily do an alt/pos hold in order to see if the fix comes back, and/or attempt to auto-land if the GPS fix/sat count doesn't improve within a pre-configured timeout???

It seems pretty dangerous & scary that an RTH/NAV event will be instantly & completely aborted if there are any issues with the GPS readings... What, then, happens to the quad? What throttle/control values will be passed on to it? It seems like a high risk for a fly-away or crash...it would be safer to at least try to do an alt-hold or land gracefully...

Two cases :
GPS fix lost : It is very likely a HW error. The assumptions (and experience) says that it will not fix itself in the fly... so aborting gps assisted modes is the only option. Without GPS there is no poshold, and without poshold autoland is very close to a semi controlled crash landing (it is more than likely that it will flip over at land....)
Throttle and RC control ALWAYS passed to the copter (even during navigation) so when you see the gps error then you simply fly home via rc controls... (Out of sight flying is prohibited or will be prohibited in many countries)

GPS satnum below five... it is usually a temporary event, so RTH or NAV is just paused till sats raised above 5. Why pause ? Since with 5 sats or below poshold is a crazy horse in a 20x20 meter area.... as always you will have an error message and you can decide what would you do.

ok, thank you very much for that information...
I understand your position on out of line of sight flying, but it is not an issue in my case. I actually require RTH from MWC for situations where I am at the edge of my range and need to return safely (far beyond LOS).

The APM apparently offers a GPS failsafe option that will attempt to land the craft in the event that the GPS fix is lost. I would like to attempt to make this same change to the MWC NAV code if possible. Ideally, I would like to 'pause' in the same way as in the 'satcount below 5' situation, wait for a timeout (perhaps 5 seconds) before attempting to land... Can you please provide advice/recommendations on how to best incorporate this type of change into your code?
thanks

o_lampe · Post by **o_lampe** » Fri Mar 28, 2014 7:39 pm

Why is it be impossible to do a temporary PosHold after a GPS failure?
Just use the vertical acceleration values instead and try to keep them "zero". Or am I too naive?

Regarding the temperature drift: It would be possible to use a small heating element below the sensor area that keeps the temp on a steady value ( say 40°C ) MWII-software would start calibration once the temp has been reached and wouldn't have to be changed afterwards.

ttcorse · Post by **ttcorse** » Fri Mar 28, 2014 8:02 pm

if it gets hot?
We have a fan?

csurf · Post by **csurf** » Sat Mar 29, 2014 1:38 am

o_lampe wrote:Why is it be impossible to do a temporary PosHold after a GPS failure?
Just use the vertical acceleration values instead and try to keep them "zero". Or am I too naive?

Not sure if you mean 'alt hold' via the vertical accel readings or an actual position hold (which I think might be tough).

Perhaps a 'dead reckoning' algorithm can be used in order to try to apply counter-braking... i.e., if the last known speed & direction are known, then perhaps a certain amount of counter pitch/roll can be applied in order to try to slow the vehicle down and more/less hold it in place before trying to alt hold...

If you make the assumptions that 1) you were most likely already oriented correctly 2) headed in the right direction, and 3) had the appropriate speed during an RTH/NAV event when the GPS fix was lost, then I think that, in theory, a temporary ALT HOLD should be ok in most cases.

I've had issues where, for whatever reason, the MWC reports the GPS fix as being temporarily lost for a couple of cycles even though my UBLOX GPS has a solid fix. I think this has something to do with errors or latency on the serial link, but I'm not sure. I've tried both lowering and increasing the GPS baud rates, but it still happens occasionally. It only happens briefly, but I think it might be enough to cancel an RTH attempt. This is why I think it would be a good idea to allow for a brief pause after a GPS fix is lost in order to see if the fix comes back within the next couple of sensor read cycles...

Ideally, I'd then like to initiate an auto-landing if the fix doesn't come back within a few seconds... If you've been alt-holding for a few seconds, then perhaps your speed has diminished enough to be able to attempt a slow landing.

o_lampe wrote:Regarding the temperature drift: It would be possible to use a small heating element below the sensor area that keeps the temp on a steady value ( say 40°C ) MWII-software would start calibration once the temp has been reached and wouldn't have to be changed afterwards.

interesting idea, would be cool to see someone try this...

I did some testing on an APM board housed in a plastic case & with the 'baro foam', and the temp drift was a much bigger problem. The temperature can go from ambient (~25C) and slowly rise close to 40C over the span of a few minutes. Since the board is insulated inside of the APM's protective case, the prop wash doesn't help much to to control temperature (this is even worse of a problem for planes when the APM is mounted inside the airframe). This can cause a pretty large drift in altitude readings (I even saw it go up to the 15-20m range in a couple of tests).

What I've wondered is if this type of drift can somehow be compensated for in software. Say, for example, a particular setup has a stable operating temp range of '40C' idling and '35C' when flying. It would be cool if these values could be somehow configured in software and then used as an offset to determine a 'stable/average' temp for use in calculating the altitude. dunno if this would work though or how such an algorithm could be setup...

e_lm_70 · Post by **e_lm_70** » Sat Mar 29, 2014 3:46 am

@csruf

MultiWii code has already the temperature reading of the baro sensor for properly adjust the altitude reading.

csurf · Post by **csurf** » Sat Mar 29, 2014 3:53 am

e_lm_70 wrote:@csruf

MultiWii code has already the temperature reading of the baro sensor for properly adjust the altitude reading.

yes, that's correct, but I was referring to the gradual temperature rise during the time that the board slowly heats up to operating temp after being powered on from a cold start. This change in board temperature can cause a big error in the calculated altitude readings... The APM suffers a lot from this problem; I admit that I haven't really tested it a lot on the MWC though... I was hoping that a 'calibrate baro' function could be added to the GUI in order to allow the user to manually recalibrate the baro on demand (just in case...).

QuadBow · Post by **QuadBow** » Sat Mar 29, 2014 8:51 am

csurf wrote: This change in board temperature can cause a big error in the calculated altitude readings.

Why should a digital microcontroller show a big error when temperature changes?
The only parts being affected by a temperature change are the analogue sensors.

e_lm_70 wrote:MultiWii code has already the temperature reading of the baro sensor for properly adjust the altitude reading.

But, as it has already been pointed out, the baro has an integrated temperature chip which not only provides the temperature information to multiwii but mainly is used for an internal compensation of the temperature drift.

csurf wrote: This change in board temperature can cause a big error in the calculated altitude readings...

Therefore, the error you are afraid of has already been minimized by the multiwii design.

csurf · Post by **csurf** » Sat Mar 29, 2014 9:11 am

QuadBow wrote:
csurf wrote: This change in board temperature can cause a big error in the calculated altitude readings.

Why should a digital microcontroller show a big error when temperature changes?
The only parts being affected by a temperature change are the analogue sensors.
e_lm_70 wrote:MultiWii code has already the temperature reading of the baro sensor for properly adjust the altitude reading.

But, as it has already been pointed out, the baro has an integrated temperature chip which not only provides the temperature information to multiwii but mainly is used for an internal compensation of the temperature drift.
csurf wrote: This change in board temperature can cause a big error in the calculated altitude readings...

Therefore, the error you are afraid of has already been minimized by the multiwii design.

uggh, another antagonistic response, what a pain...

read closely...After a cold start, a flight controller's PCB board will vary in temperature from a starting ambient temp to a final operating temp, usually in the range of 30-40 degrees Celsius. This is much more apparent and drastic when the flight controller is contained within a protective case and with foam covering the barometric pressure sensor... During that temperature rise time, the readings will experience a positive altitude error until the flight controller's temperature stabilizes...

Even the APM suffers from this type of drift, and its code also uses temperature in order to calculate air pressure.
https://github.com/diydrones/ardupilot/ ... P_Baro.cpp

anyway... all of that is off of the topic...

The request for a manual gyro/baro calibration via the serial protocol/GUI doesn't seem like an unreasonable one. Anything that can be done via the sticks should also be possible via the serial protocol, and the ability to calibrate gyros & baro is already accessible via stick commands.

QuadBow · Post by **QuadBow** » Sat Mar 29, 2014 10:15 am

csurf wrote:uggh, another antagonistic response, what a pain...

I would not name my respond antagonistic. Might it be the case that you don't allow others to have a different opinion?

csurf wrote:Even the APM suffers from this type of drift, and its code also uses temperature in order to calculate air pressure.

That would mean, your copter altitude is drifting until the final temperature has been reached.
Sorry to tell you, but I don't notice such a drifting. I use multiwii 2.3 and a MS5611 baro.

csurf wrote:The request for a manual gyro/baro calibration via the serial protocol/GUI doesn't seem like an unreasonable one.

I am still trying to find a use case for your proposal. What is the benefit of zeroing the baro in the air? You better do so on the ground - and that is already been done by multiwii.

csurf · Post by **csurf** » Sat Mar 29, 2014 3:09 pm

QuadBow wrote:
csurf wrote:uggh, another antagonistic response, what a pain...

I would not name my respond antagonistic. Might it be the case that you don't allow others to have a different opinion?

challenging a perfectly reasonable request with a counter-argument with no real basis other than for the sake of being conflictive can easily be considered antagonistic...

QuadBow wrote:
csurf wrote:Even the APM suffers from this type of drift, and its code also uses temperature in order to calculate air pressure.

That would mean, your copter altitude is drifting until the final temperature has been reached.

yes, that is exactly what happens...
just because it doesn't happen to you, does not mean that it doesn't happen to others...

QuadBow wrote:
csurf wrote:The request for a manual gyro/baro calibration via the serial protocol/GUI doesn't seem like an unreasonable one.

I am still trying to find a use case for your proposal. What is the benefit of zeroing the baro in the air? You better do so on the ground - and that is already been done by multiwii.

who said anything about zeroing it in the air??? That would be insane...It's a pre-flight calibration step and nothing more...

*Someone* must have thought it was a worthwhile option, otherwise it would have never been coded as a stick combination option...
http://code.google.com/p/multiwii/sourc ... r=1648#852

visper · Post by **visper** » Sat Apr 05, 2014 8:18 am

It is possible to program the failsafe (when they lose the signal) as RTH?

Hypermobile · Post by **Hypermobile** » Mon Apr 07, 2014 1:18 pm

If your receiver support failsafe all Channels.

you can program you Failsafe in such way...that you can activate RTH...
no Multiwii code neccesary

GUSHELFER · Post by **GUSHELFER** » Mon Apr 07, 2014 8:22 pm

hola, podria ayudarme ?? estoy trabajando con una crius multiwii v2.5 con gps en i2c, modulo nav , bluetoot, lcd, TODO FUNCIONA O.K !!! PERO llegue al punto que no puedo usar mas que multiwii2.3 ya que las otra versiones "NAV" NO ESTA TERMINADO EL I2C PARA EL GPS, ADEMAS LOS SKETCH SON MUY GRANDES PARA ELLA, TENDRE ALGUNA SOLUCION??? COMO CONECTO EL GPS DE I2C A SERIE???? COMO ACHICO EL SKETCH ??? GRACIAS

EOSBandi · Post by **EOSBandi** » Mon Apr 07, 2014 9:43 pm

GUSHELFER wrote:hola, podria ayudarme ?? estoy trabajando con una crius multiwii v2.5 con gps en i2c, modulo nav , bluetoot, lcd, TODO FUNCIONA O.K !!! PERO llegue al punto que no puedo usar mas que multiwii2.3 ya que las otra versiones "NAV" NO ESTA TERMINADO EL I2C PARA EL GPS, ADEMAS LOS SKETCH SON MUY GRANDES PARA ELLA, TENDRE ALGUNA SOLUCION??? COMO CONECTO EL GPS DE I2C A SERIE???? COMO ACHICO EL SKETCH ??? GRACIAS

Cimbora, tiszteld már meg az itt lévőket azzal, hogy veszed a fáradságot és angolul írod a mondandódat...

howardhb · Post by **howardhb** » Mon Apr 07, 2014 11:49 pm

GUSHELFER wrote:
hola, podria ayudarme ?? estoy trabajando con una crius multiwii v2.5 con gps en i2c, modulo nav , bluetoot, lcd, TODO FUNCIONA O.K !!! PERO llegue al punto que no puedo usar mas que multiwii2.3 ya que las otra versiones "NAV" NO ESTA TERMINADO EL I2C PARA EL GPS, ADEMAS LOS SKETCH SON MUY GRANDES PARA ELLA, TENDRE ALGUNA SOLUCION??? COMO CONECTO EL GPS DE I2C A SERIE???? COMO ACHICO EL SKETCH ??? GRACIAS

Cimbora, tiszteld már meg az itt lévőket azzal, hogy veszed a fáradságot és angolul írod a mondandódat...

Miskien ken die ou nie hoe om te Google Translate :lol:

http://translate.google.com/

@GUSHELFER,I2C NAV no es compatible, y, no en crius multiwii v2.5 (AtMega328) ---> NAV does not support I2C, and, not Crius MultiWii v2.5 (ATmega328)

Plüschi · Post by **Plüschi** » Tue Apr 08, 2014 6:21 am

In gps.cpp, function GPS_bearing()

Code: Select all

*bearing = 9000 + atan2(-off_y, off_x) * 5729.57795f;

could be simpler, faster and shorter

Code: Select all

*bearing = atan2(off_x,off_y) * 5729.57795f;

Also the parameters

Code: Select all

int32_t* lat1, int32_t* lon1, int32_t* lat2, int32_t* lon2,

of the function do not need to be pointers. Instead they can be declared as

Code: Select all

int32_t pos1[], int32_t pos2[]

and the function can be called with

Code: Select all

GPS_bearing(GPS_coord,GPS_poi,...

which makes the whole thing much more readable, short and simple.

scrat · Post by **scrat** » Tue Apr 08, 2014 7:53 am

EOSBandi wrote:
GUSHELFER wrote:hola, podria ayudarme ?? estoy trabajando con una crius multiwii v2.5 con gps en i2c, modulo nav , bluetoot, lcd, TODO FUNCIONA O.K !!! PERO llegue al punto que no puedo usar mas que multiwii2.3 ya que las otra versiones "NAV" NO ESTA TERMINADO EL I2C PARA EL GPS, ADEMAS LOS SKETCH SON MUY GRANDES PARA ELLA, TENDRE ALGUNA SOLUCION??? COMO CONECTO EL GPS DE I2C A SERIE???? COMO ACHICO EL SKETCH ??? GRACIAS

Cimbora, tiszteld már meg az itt lévőket azzal, hogy veszed a fáradságot és angolul írod a mondandódat...

ROFL

BeringBullet · Post by **BeringBullet** » Tue Apr 08, 2014 4:06 pm

Is this code base stable enough to use as a daily flyer? if I am not using the nav point, I like the idea of the fence/RTH code.

Hypermobile · Post by **Hypermobile** » Wed Apr 09, 2014 9:03 am

If you don't use Nav..Multiwii 2.3 has a official release.
Nav is still in beta. But the rest is pretty much the same as 2.3

csurf · Post by **csurf** » Wed Apr 09, 2014 10:47 pm

BeringBullet wrote:Is this code base stable enough to use as a daily flyer? if I am not using the nav point, I like the idea of the fence/RTH code.

I'm currently using it for daily flying. I don't use the NAV features other than RTH, pos hold, and LAND. It seems to work fine; there's not much difference from the regular 2.3 version, except for changes to the NAV/GPS code. If you only want RTH, you could probably get by with the regular 2.3 version as well. However, note that I've modified and cleaned up a few different items in the code myself, so if you're not a hands-on type with the code, perhaps you'd be better served with the regular 2.3 version?

csurf · Post by **csurf** » Wed Apr 09, 2014 11:00 pm

Plüschi wrote:In gps.cpp, function GPS_bearing()
Code: Select all
*bearing = 9000 + atan2(-off_y, off_x) * 5729.57795f; 
could be simpler, faster and shorter
Code: Select all
*bearing = atan2(off_x,off_y) * 5729.57795f;
Also the parameters
Code: Select all
int32_t* lat1, int32_t* lon1, int32_t* lat2, int32_t* lon2,
of the function do not need to be pointers. Instead they can be declared as
Code: Select all
int32_t pos1[], int32_t pos2[]
and the function can be called with
Code: Select all
GPS_bearing(GPS_coord,GPS_poi,...
which makes the whole thing much more readable, short and simple.

there are a WHOLE LOT of things like this that should be cleaned up & refactored.
There's no apparent standard for anything...
- lot's of global variables scattered throughout the code
- too many void functions that don't have a distinct purpose and/or randomly perform op's on global variables
- large chunks of code that should be moved to separate functions yet that are stuffed into one giant mega-function
- inconsistent use of references as function args
- 'magic numbers' galore, some pretty significant values that are used in comparisons/evaluations yet that aren't defined as a user-configurable parameter
- terrible, inconsistent use of spacing, variable naming, etc. just plain horrible programming style in general
... and the list goes on...

Code: Select all

void do_something_specific(*uint8_t someParam){
if (someGlobalVariable > 5) //magic number usage
    doSomethingElse(someParam);

anotherGlobalVariable=10; //why the hell would we do this here and risk causing problems elsewhere??? 
someOtherGlobal = SOME_GLOBAL_DEFINE * 3556.35334f; //huh? magic numbers and global defines FTW!!!

//return nothing, operate on globals in a mashed-up fashion, i.e. this was a pointless function
}

lfield22 · Post by **lfield22** » Tue Apr 15, 2014 7:26 pm

When I try to compile any of the MultiWiiNAV2_3 b5-b7 files, I receive a "Too Big" error ( without even making any changes to the files). What can I do to make the files smaller?