GPS NAV

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

Re: GPS NAV

Post by EOSBandi »

Quick update:
In WinGUI I fixed most of the bugs that surfaced since xmas release.
in navi code there are many changes:
Navigation now able to take over control of BARO mode and throttle (necessary for failsafe and autoland)
navi code now identify itself in capability flag, prevents winGUI from crashing with vanilia mw.
Tinkering with GPS filters, still need to find out the best combination. (it is easy now, since filters are controllable via GUI)
Just tested autoland and disarm. It's working quite good. Also added land command to navigation
Added definable geofencing (simple CAN shaped fence).
some more will come... :D

a couple of days and test flights and I'll publish the next update :D

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

Re: GPS NAV

Post by -ralf- »

András,

thanks for all the great work! A little wish:

With erasing the EEPROM all configuration data are lost (ACC and MAG calibration, boxes, PID's etc.).
Is it possible to only erase the significant area that GPS-Nav needs (first and last byte in EEPROM)?

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:András,

thanks for all the great work! A little wish:

With erasing the EEPROM all configuration data are lost (ACC and MAG calibration, boxes, PID's etc.).
Is it possible to only erase the significant area that GPS-Nav needs (first and last byte in EEPROM)?


Sorry but no.
Selectively erease epprom content when changing version is a dangerous situation... it could cause more harm than good.
Save your settings to file and reload it.....
Once the navi conf structure is finalized then it won't need erasing at every version.

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Post by schnupperm »

hello,

I found the rate of altitude change in Baro mode a little bit slow.

1.) I found a bug (?), as I tried to improve it:
In IMU.cpp line 1296 the change of AltHold is computed according to the difference of rcCommand[THROTTLE] and
initialThrottleHold. As I understand the code, BaroPID should be also considered:

Code: Select all

  if (f.BARO_MODE) {
      static uint8_t isAltHoldChanged = 0;
      static int16_t AltHoldCorr = 0;
      if (abs(rcCommand[THROTTLE]-BaroPID-initialThrottleHold)>ALT_HOLD_THROTTLE_NEUTRAL_ZONE) { //BaroPID correction
        // Slowly increase/decrease AltHold proportional to stick movement ( +100 throttle gives ~ +50 cm in 1 second with cycle time about 3-4ms)
        AltHoldCorr+= rcCommand[THROTTLE] - BaroPID - initialThrottleHold ; //BaroPID correction
        if(abs(AltHoldCorr) > 512) {
          AltHold += AltHoldCorr/512;
          AltHoldCorr %= 512;
        }
        isAltHoldChanged = 1;
      } else if (isAltHoldChanged) {
        AltHold = alt.EstAlt;
        isAltHoldChanged = 0;
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID; // !!! rcCommand[THROTTLE] changed !!!
    }


2.) is it safe to change Line 292 in IMU.cpp from

Code: Select all

  BaroPID = constrain((conf.pid[PIDALT].P8 * error16 >>7), -150, +150);

to

Code: Select all

  BaroPID = constrain((conf.pid[PIDALT].P8 * error16 >>7), -250, +250);

for a faster climb/descent ?


3.) thank you again for the NAV-Version. No problems found so far, during 15 Batteries of test flights. (Three different missions flown with xmas-release.)

crazyal
Posts: 84
Joined: Tue Sep 04, 2012 11:25 pm

Re: GPS NAV

Post by crazyal »

schnupperm wrote:hello,

I found the rate of altitude change in Baro mode a little bit slow.

1.) I found a bug (?), as I tried to improve it:
In IMU.cpp line 1296 the change of AltHold is computed according to the difference of rcCommand[THROTTLE] and
initialThrottleHold. As I understand the code, BaroPID should be also considered:

Code: Select all

  if (f.BARO_MODE) {
      static uint8_t isAltHoldChanged = 0;
      static int16_t AltHoldCorr = 0;
      if (abs(rcCommand[THROTTLE]-BaroPID-initialThrottleHold)>ALT_HOLD_THROTTLE_NEUTRAL_ZONE) { //BaroPID correction
        // Slowly increase/decrease AltHold proportional to stick movement ( +100 throttle gives ~ +50 cm in 1 second with cycle time about 3-4ms)
        AltHoldCorr+= rcCommand[THROTTLE] - BaroPID - initialThrottleHold ; //BaroPID correction
        if(abs(AltHoldCorr) > 512) {
          AltHold += AltHoldCorr/512;
          AltHoldCorr %= 512;
        }
        isAltHoldChanged = 1;
      } else if (isAltHoldChanged) {
        AltHold = alt.EstAlt;
        isAltHoldChanged = 0;
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID; // !!! rcCommand[THROTTLE] changed !!!
    }


2.) is it safe to change Line 292 in IMU.cpp from

Code: Select all

  BaroPID = constrain((conf.pid[PIDALT].P8 * error16 >>7), -150, +150);

to

Code: Select all

  BaroPID = constrain((conf.pid[PIDALT].P8 * error16 >>7), -250, +250);

for a faster climb/descent ?


3.) thank you again for the NAV-Version. No problems found so far, during 15 Batteries of test flights. (Three different missions flown with xmas-release.)


1. and 2. are wrong. You don't need to change the BaroPID range to get a faster descend and ascend rate. Simply change the 3 512 values to something smaller and the quad will ascend/descend faster.

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

Re: GPS NAV

Post by EOSBandi »

Exactly as CrazyAl said....
At althold you set the desired altitude, and the baro controller calculates the necessary BaroPID value. For faster or slower descent you have to increase the change rate of althold value.

Imen
Posts: 20
Joined: Thu Sep 27, 2012 5:11 pm

Re: GPS NAV

Post by Imen »

Hi EOS,

just suggest, can you add some progress bar when upload the mission :D
and then about RSSI maybe this can be the option

http://www.codeproject.com/Articles/512 ... ntrol-in-C

thanks

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Post by schnupperm »

crazyal wrote:1. and 2. are wrong. You don't need to change the BaroPID range to get a faster descend and ascend rate. Simply change the 3 512 values to something smaller and the quad will ascend/descend faster.


Thank you.
I changed the 512 to 128 the day before I posted, but it does not changed the climb rate. Maybe I did something wrong. I 'll try it again when the rain stops....

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Post by schnupperm »

schnupperm wrote:
crazyal wrote:1. and 2. are wrong. You don't need to change the BaroPID range to get a faster descend and ascend rate. Simply change the 3 512 values to something smaller and the quad will ascend/descend faster.


Thank you.
I changed the 512 to 128 the day before I posted, but it does not changed the climb rate. Maybe I did something wrong. I 'll try it again when the rain stops....



A new test today with

Code: Select all

       if(abs(AltHoldCorr) > 64) {
          AltHold += AltHoldCorr/64;
          AltHoldCorr %= 64;
        }
 

resulted in a climb/descent rate or 0.5 maybe 1 m/s for full/no throttle, not different to the unmodified code ?!

One thing I noticed today: I had two waypoints 10m apart with 40m altitude difference. The copter stopped climbing as soon the waypoint was reached over ground.

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

Re: GPS NAV

Post by EOSBandi »

Are you talking about manual alt change in BARO mode or altitude change during mission ?

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Post by schnupperm »

EOSBandi wrote:Are you talking about manual alt change in BARO mode or altitude change during mission ?

I' m talking about manual alt change in BARO mode. I want to test the climb rate in NAV mode today, but I get no result because of the stopp in climbing as soon as the waypoint is reached.

User avatar
Gartenflieger
Posts: 65
Joined: Sat Oct 01, 2011 10:07 pm
Location: Dortmund, Germany

Re: GPS NAV

Post by Gartenflieger »

A thought concerning the failsafe:

I think the user should ALWAYS be able to interfere. I imagine there should be a test if the user has moved the sticks. If so, either abort whatever is done currently or modify the action according to the stick movement.

For example: I see my copter returning home at a predefined altitude and think: Hmmm.. maybe I underestimated the height of those trees around here. Then I give some throttle and the Copter rises just above the trees while continuing his journey to the home position.

Regards
Christoph

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

Re: GPS NAV

Post by EOSBandi »

Gartenflieger wrote:A thought concerning the failsafe:

I think the user should ALWAYS be able to interfere. I imagine there should be a test if the user has moved the sticks. If so, either abort whatever is done currently or modify the action according to the stick movement.

For example: I see my copter returning home at a predefined altitude and think: Hmmm.. maybe I underestimated the height of those trees around here. Then I give some throttle and the Copter rises just above the trees while continuing his journey to the home position.

Regards
Christoph


During any UAV maneuver, user always have the option to abort and take over the control by switching mode. However aborting on a stick movement could be dangerous. Aborting should be a well defined sequence. So in your example case... when you realized that you are too low, just switch to poshold (or manual) change altitude and re-engage rth again.

Another example : geofence failsafe... you fly outside the fence, copter switch to RTH, but if you still have stick control then you can move outside the fence, and fight against rth... If you does not have stick control, you have to switch mode to abort rth, to regain control, otherwise copter will rth...

joergw
Posts: 10
Joined: Wed Jan 08, 2014 10:11 am

Re: GPS NAV

Post by joergw »

Hi all,

i am new here, so Hello to everybody.
Using Multiwii now for one year on a F450 with Crius AIO Pro V2. Changed to that FC due to Navigation with Multiwii.
I Have now a question about POI. Would it be possible to manual steer the multicopter and "look" towards a specified POI?

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

Re: GPS NAV

Post by EOSBandi »

joergw wrote:Hi all,

i am new here, so Hello to everybody.
Using Multiwii now for one year on a F450 with Crius AIO Pro V2. Changed to that FC due to Navigation with Multiwii.
I Have now a question about POI. Would it be possible to manual steer the multicopter and "look" towards a specified POI?


1. you can define POI, and copter will turn towards the poi.
2. during normal mission you have yaw control, so you can turn your copter.

joergw
Posts: 10
Joined: Wed Jan 08, 2014 10:11 am

Re: GPS NAV

Post by joergw »

Hi EOSBandi, thx for quick answer.

i know, what i want is manual control of position by stick-input and automatic control of the heading towards the POI. E.g. for pictures with large zoom. Safes me the video-downlink to control the heading visually

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Post by schnupperm »

joergw wrote:
i know, what i want is manual control of position by stick-input and automatic control of the heading towards the POI.

You can't change a POI only by changing the heading. You must also specify the distance!

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

Re: GPS NAV

Post by EOSBandi »

I see. It is not on the short term list, but it is definitely on the list of future developments.
I’m using multiwii for cinematography too (my cinestar flies better with multiwii than with MK), and plan is to create a small poi device. It’s a gps receiver and a short range data radio in a very small package. You can give it to your actor or put it on the vehicle that you want to film. Then it directly transfers poi position information to the copter. So copter will always heading to the poi. Your flight operator need to take care only the trajectory, and gimbal operator needed only to correct framing.

User avatar
Gartenflieger
Posts: 65
Joined: Sat Oct 01, 2011 10:07 pm
Location: Dortmund, Germany

Re: GPS NAV

Post by Gartenflieger »

EOSBandi wrote:
Gartenflieger wrote:A thought concerning the failsafe:

I think the user should ALWAYS be able to interfere. I imagine there should be a test if the user has moved the sticks. If so, either abort whatever is done currently or modify the action according to the stick movement.

For example: I see my copter returning home at a predefined altitude and think: Hmmm.. maybe I underestimated the height of those trees around here. Then I give some throttle and the Copter rises just above the trees while continuing his journey to the home position.

Regards
Christoph


During any UAV maneuver, user always have the option to abort and take over the control by switching mode. However aborting on a stick movement could be dangerous. Aborting should be a well defined sequence. So in your example case... when you realized that you are too low, just switch to poshold (or manual) change altitude and re-engage rth again.

Another example : geofence failsafe... you fly outside the fence, copter switch to RTH, but if you still have stick control then you can move outside the fence, and fight against rth... If you does not have stick control, you have to switch mode to abort rth, to regain control, otherwise copter will rth...


Yes, I see your point here. However, knowing myself I think that once things start to go wrong I will just wrestle with the sticks as I am used to with helicopters instead of follwing the 'well defined procedure'. Probably there is a different approach to the escape from unwanted flight situations depending on whether one learned to fly unstabilized or stabilized first.

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

Re: GPS NAV

Post by EOSBandi »

Gartenflieger wrote:
EOSBandi wrote:
Gartenflieger wrote:A thought concerning the failsafe:

I think the user should ALWAYS be able to interfere. I imagine there should be a test if the user has moved the sticks. If so, either abort whatever is done currently or modify the action according to the stick movement.

For example: I see my copter returning home at a predefined altitude and think: Hmmm.. maybe I underestimated the height of those trees around here. Then I give some throttle and the Copter rises just above the trees while continuing his journey to the home position.

Regards
Christoph


During any UAV maneuver, user always have the option to abort and take over the control by switching mode. However aborting on a stick movement could be dangerous. Aborting should be a well defined sequence. So in your example case... when you realized that you are too low, just switch to poshold (or manual) change altitude and re-engage rth again.

Another example : geofence failsafe... you fly outside the fence, copter switch to RTH, but if you still have stick control then you can move outside the fence, and fight against rth... If you does not have stick control, you have to switch mode to abort rth, to regain control, otherwise copter will rth...


Yes, I see your point here. However, knowing myself I think that once things start to go wrong I will just wrestle with the sticks as I am used to with helicopters instead of follwing the 'well defined procedure'. Probably there is a different approach to the escape from unwanted flight situations depending on whether one learned to fly unstabilized or stabilized first.


Yes, you are right. It mostly depends on the background what we have on flying. I will try to think out a configurable solution...

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

Quick update

Post by EOSBandi »

I'm working on the code, but weather does not allow outside testing, which is important to dial in the autoland parameters. I hope weather clears out at the second half of the week and I can make the necessary testing and release the next cycle.

Meanwhile farnell finally got these in stock again :
WP_20140109_20_27_32_Pro.jpg


These are real multi constellation gps modules (GPS+GLONASS+GALIEO) and they are capable to output RAW gps phase data. (RTK anyone ? )
Time to make some PCB's

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Post by schnupperm »

schnupperm wrote:
EOSBandi wrote:Are you talking about manual alt change in BARO mode or altitude change during mission ?

I' m talking about manual alt change in BARO mode. I want to test the climb rate in NAV mode today, but I get no result because of the stopp in climbing as soon as the waypoint is reached.


I flew a new test mission today and climb rates in NAV mode matched my expectations (as far as I understand the code ;-). I doubled them by changing the _scale in GPS.cpp lines 873-893:

Code: Select all

   int8_t         _scale    = 3;

   if (alt_to_hold < target_altitude)
      {
      // we are below the target alt
      if(diff < 200)   _scale = 4;
       else _scale = 2;
      }
   else
      {
         // we are above the target, going down
         if(diff < 400) _scale = 4;      //Slow down if only 4meters above
         if(diff < 100) _scale = 5;      //Slow down further if within 1meter
      }

mopedcrosser
Posts: 52
Joined: Sat Feb 23, 2013 12:35 pm

Re: GPS NAV

Post by mopedcrosser »

Hi,

I'd suggest a stick control like in GPS hold mode. Once stick input is given the mission is paused and will be continued after sticks are neutral again. This may only be for pan / tilt because mission would be paused if you use yaw to align your camera during missions.

Another feature should be that the copter cant be armed in mission mode.. which may be pretty dangerous.

Regarding the failsafe, I am glad to see so many replies sharing the same concerns.. With the current fs it would just crash anywhere where it looses signal during the mission. I think RTH with predefined altitude would be most useful. For people who think to know what they do a possibility to continue mission at signal loss should be provided to make missions out of rc range possible. A definable "emergency" waypoint would also be a good option (should be home as default). With this option you could set a safe area without trees or people where a troublesome copter can go down with least damage.

Thanks for your awesome work!

Sebastian

szakacs
Posts: 18
Joined: Wed Dec 11, 2013 11:53 pm
Location: Sydney, NSW Australia

Re: GPS NAV

Post by szakacs »

Would it be possible to show trim values in the GUI ?

User avatar
Rob
Posts: 77
Joined: Sun Apr 03, 2011 4:40 pm

Re: Quick update

Post by Rob »

EOSBandi wrote:I'm working on the code, but weather does not allow outside testing, which is important to dial in the autoland parameters. I hope weather clears out at the second half of the week and I can make the necessary testing and release the next cycle.

Meanwhile farnell finally got these in stock again :
WP_20140109_20_27_32_Pro.jpg


These are real multi constellation gps modules (GPS+GLONASS+GALIEO) and they are capable to output RAW gps phase data. (RTK anyone ? )
Time to make some PCB's


Do you need somebody draw the schematic and PCB?
If you need a proto, I can arrange something.

Rob

turkawa
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Post by turkawa »

sorry for this really noob question but!
I have never been able to open wingui!!
that nasty invalid data around line 6..
i have changed the . to , and vise versa.. no use..
when i erase all text inside config23 it opens but no values.
i was getting used to original multiwii gui but now there is waypoint issue and i really want to use wingui!!!
Is there a fix i am missing???

mopedcrosser
Posts: 52
Joined: Sat Feb 23, 2013 12:35 pm

Re: GPS NAV

Post by mopedcrosser »

Mhmm shouldnt´t be too hard. Are you sure you downloaded the WinGUI seperately ? Its not included in the Multiwii Xmas Release. You have to download the GUI from EOS site (follow link in first post). Then simply open the exe.. Works ?

Seb

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

Re: GPS NAV

Post by EOSBandi »

schnupperm wrote:
schnupperm wrote:
EOSBandi wrote:Are you talking about manual alt change in BARO mode or altitude change during mission ?

I' m talking about manual alt change in BARO mode. I want to test the climb rate in NAV mode today, but I get no result because of the stopp in climbing as soon as the waypoint is reached.


I flew a new test mission today and climb rates in NAV mode matched my expectations (as far as I understand the code ;-). I doubled them by changing the _scale in GPS.cpp lines 873-893:

Code: Select all

   int8_t         _scale    = 3;

   if (alt_to_hold < target_altitude)
      {
      // we are below the target alt
      if(diff < 200)   _scale = 4;
       else _scale = 2;
      }
   else
      {
         // we are above the target, going down
         if(diff < 400) _scale = 4;      //Slow down if only 4meters above
         if(diff < 100) _scale = 5;      //Slow down further if within 1meter
      }

You find a right spot bro...
I admit it's a quick hack, i'll replace it with a real vario speed based controller.

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

Re: GPS NAV

Post by EOSBandi »

mopedcrosser wrote:Hi,

I'd suggest a stick control like in GPS hold mode. Once stick input is given the mission is paused and will be continued after sticks are neutral again. This may only be for pan / tilt because mission would be paused if you use yaw to align your camera during missions.

Another feature should be that the copter cant be armed in mission mode.. which may be pretty dangerous.

Regarding the failsafe, I am glad to see so many replies sharing the same concerns.. With the current fs it would just crash anywhere where it looses signal during the mission. I think RTH with predefined altitude would be most useful. For people who think to know what they do a possibility to continue mission at signal loss should be provided to make missions out of rc range possible. A definable "emergency" waypoint would also be a good option (should be home as default). With this option you could set a safe area without trees or people where a troublesome copter can go down with least damage.

Thanks for your awesome work!

Sebastian

I still think that mission abort or pause should be a well defined switch of modes. Controlling mission pause based on stick movement makes things unnecessary complicated. Plus it does not makes sense, since when you pause a mission (either poshold or enroute) you also resets all PID controllers so for example if you have a nice I value which accumulated to compensate for wind, you will loose it.

prohibiting arm in mission mode is a good idea.

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

Re: Quick update

Post by EOSBandi »

Rob wrote:
EOSBandi wrote:I'm working on the code, but weather does not allow outside testing, which is important to dial in the autoland parameters. I hope weather clears out at the second half of the week and I can make the necessary testing and release the next cycle.

Meanwhile farnell finally got these in stock again :
WP_20140109_20_27_32_Pro.jpg


These are real multi constellation gps modules (GPS+GLONASS+GALIEO) and they are capable to output RAW gps phase data. (RTK anyone ? )
Time to make some PCB's


Do you need somebody draw the schematic and PCB?
If you need a proto, I can arrange something.

Rob

Thanks ROB, but I have everything at home to do PCB's up to 8-10mil track width :D

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

Re: GPS NAV

Post by EOSBandi »

szakacs wrote:Would it be possible to show trim values in the GUI ?

It is a good idea, plus perhaps you can change them from gui... it could be faster than changing trim with stick controls :D

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Post by schnupperm »

schnupperm wrote:
schnupperm wrote:
EOSBandi wrote:Are you talking about manual alt change in BARO mode or altitude change during mission ?

I' m talking about manual alt change in BARO mode. I want to test the climb rate in NAV mode today, but I get no result because of the stopp in climbing as soon as the waypoint is reached.


I flew a new test mission today and climb rates in NAV mode matched my expectations (as far as I understand the code ;-). I doubled them by changing the _scale in GPS.cpp lines 873-893:

Code: Select all

   int8_t         _scale    = 3;

   if (alt_to_hold < target_altitude)
      {
      // we are below the target alt
      if(diff < 200)   _scale = 4;
       else _scale = 2;
      }
   else
      {
         // we are above the target, going down
         if(diff < 400) _scale = 4;      //Slow down if only 4meters above
         if(diff < 100) _scale = 5;      //Slow down further if within 1meter
      }


This weekend the climb rates seemed also very small. (During the quoted test I had 5 bft. turbulent wind, so I think I got a wrong impression.)

I solved the problem now by increasing BaroPID in IMU.cpp lines 290-293

Code: Select all

   int16_t error16 = constrain(AltHold - alt.EstAlt, -500, 500); // orig. -300,300
    applyDeadband(error16, 10); //remove small P parametr to reduce noise near zero position
    BaroPID = constrain((conf.pid[PIDALT].P8 * error16 >>7), -250, +250); // orig. -150 150

and changed Muliwii.cpp lines 1302-1305:

Code: Select all

    if(abs(AltHoldCorr) > 128) { //orig. 512
          AltHold += AltHoldCorr/128; //orig. 512
          AltHoldCorr %= 128; // orig.512
    }

schnupperm
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

NAV_CONTROLS_HEADING not working on some waypoints

Post by schnupperm »

I noticed that on the way to some waypoints the heading of the copter is off by about 30 degrees. In the attached mission the error occurs between waypoint 3 and 4. I have the feeling that the error occurs if the change of direction is near to 180 degrees.

.mission file:

Code: Select all

<?xml version="1.0"?>
<!--MultiWiiWinGUI, Version 2.3.5105.40820-->
<!--MultiWii mission-->
<!--MultiWii FC software revision 2.3dev-->
<MISSION>
    <VERSION value="2.3 pre7" />
    <MISSIONITEM no="1" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2697955" lon="10,5540204" alt="20" />
    <MISSIONITEM no="2" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2701566" lon="10,5548412" alt="25" />
    <MISSIONITEM no="3" action="POSHOLD_TIME" parameter1="15" parameter2="0" parameter3="0" lat="52,2705538" lon="10,5554688" alt="32" />
    <MISSIONITEM no="4" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2699399" lon="10,5544227" alt="25" />
    <MISSIONITEM no="5" action="SET_POI" parameter1="0" parameter2="0" parameter3="0" lat="52,2697298" lon="10,5540365" alt="0" />
    <MISSIONITEM no="6" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2700417" lon="10,5542243" alt="15" />
    <MISSIONITEM no="7" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2700318" lon="10,5540150" alt="15" />
    <MISSIONITEM no="8" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2699399" lon="10,5538005" alt="15" />
    <MISSIONITEM no="9" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2698316" lon="10,5537307" alt="15" />
    <MISSIONITEM no="10" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2697364" lon="10,5536878" alt="15" />
    <MISSIONITEM no="11" action="POSHOLD_TIME" parameter1="60" parameter2="0" parameter3="0" lat="52,2699760" lon="10,5540097" alt="50" />
    <MISSIONITEM no="12" action="POSHOLD_UNLIM" parameter1="0" parameter2="0" parameter3="0" lat="52,2699563" lon="10,5541438" alt="10" />
</MISSION>

turkawa
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Post by turkawa »

mopedcrosser wrote:Mhmm shouldnt´t be too hard. Are you sure you downloaded the WinGUI seperately ? Its not included in the Multiwii Xmas Release. You have to download the GUI from EOS site (follow link in first post). Then simply open the exe.. Works ?

Seb


tried that and every other version..
still invalid data around bla bla
with . or ,

User avatar
Rob
Posts: 77
Joined: Sun Apr 03, 2011 4:40 pm

Re: Quick update

Post by Rob »

EOSBandi wrote:
Rob wrote:
EOSBandi wrote:I'm working on the code, but weather does not allow outside testing, which is important to dial in the autoland parameters. I hope weather clears out at the second half of the week and I can make the necessary testing and release the next cycle.

Meanwhile farnell finally got these in stock again :
WP_20140109_20_27_32_Pro.jpg


These are real multi constellation gps modules (GPS+GLONASS+GALIEO) and they are capable to output RAW gps phase data. (RTK anyone ? )
Time to make some PCB's


Do you need somebody draw the schematic and PCB?
If you need a proto, I can arrange something.

Rob

Thanks ROB, but I have everything at home to do PCB's up to 8-10mil track width :D


:P

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

Re: NAV_CONTROLS_HEADING not working on some waypoints

Post by EOSBandi »

schnupperm wrote:I noticed that on the way to some waypoints the heading of the copter is off by about 30 degrees. In the attached mission the error occurs between waypoint 3 and 4. I have the feeling that the error occurs if the change of direction is near to 180 degrees.

.mission file:

Code: Select all

<?xml version="1.0"?>
<!--MultiWiiWinGUI, Version 2.3.5105.40820-->
<!--MultiWii mission-->
<!--MultiWii FC software revision 2.3dev-->
<MISSION>
    <VERSION value="2.3 pre7" />
    <MISSIONITEM no="1" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2697955" lon="10,5540204" alt="20" />
    <MISSIONITEM no="2" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2701566" lon="10,5548412" alt="25" />
    <MISSIONITEM no="3" action="POSHOLD_TIME" parameter1="15" parameter2="0" parameter3="0" lat="52,2705538" lon="10,5554688" alt="32" />
    <MISSIONITEM no="4" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2699399" lon="10,5544227" alt="25" />
    <MISSIONITEM no="5" action="SET_POI" parameter1="0" parameter2="0" parameter3="0" lat="52,2697298" lon="10,5540365" alt="0" />
    <MISSIONITEM no="6" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2700417" lon="10,5542243" alt="15" />
    <MISSIONITEM no="7" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2700318" lon="10,5540150" alt="15" />
    <MISSIONITEM no="8" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2699399" lon="10,5538005" alt="15" />
    <MISSIONITEM no="9" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2698316" lon="10,5537307" alt="15" />
    <MISSIONITEM no="10" action="WAYPOINT" parameter1="0" parameter2="0" parameter3="0" lat="52,2697364" lon="10,5536878" alt="15" />
    <MISSIONITEM no="11" action="POSHOLD_TIME" parameter1="60" parameter2="0" parameter3="0" lat="52,2699760" lon="10,5540097" alt="50" />
    <MISSIONITEM no="12" action="POSHOLD_UNLIM" parameter1="0" parameter2="0" parameter3="0" lat="52,2699563" lon="10,5541438" alt="10" />
</MISSION>


Thanks,
I'll take a look at it.

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

Re: GPS NAV

Post by EOSBandi »

turkawa wrote:
mopedcrosser wrote:Mhmm shouldnt´t be too hard. Are you sure you downloaded the WinGUI seperately ? Its not included in the Multiwii Xmas Release. You have to download the GUI from EOS site (follow link in first post). Then simply open the exe.. Works ?

Seb


tried that and every other version..
still invalid data around bla bla
with . or ,

What is your windows language setting ?

turkawa
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Post by turkawa »

EOSBandi wrote:What is your windows language setting ?


Format is Turkish, OS language is English. OS is windows 7.

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

Re: GPS NAV

Post by -ralf- »

Hi András.

don't forget ..... it's Beta-Monday ...... :mrgreen:

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:Hi András.

don't forget ..... it's Beta-Monday ...... :mrgreen:


and it is also Midyear Business Review week at my work :(

Hypermobile
Posts: 94
Joined: Mon Jan 13, 2014 8:53 pm

Re: GPS NAV

Post by Hypermobile »

Hi There, Following the Multiwii Project for a while now.

getting into it :-). I like it.

But why is the Nav code seperate from the MW2.3?
Shouldn't this Nav code be MW2.4 Beta?

keep up the good work.

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

Re: GPS NAV

Post by EOSBandi »

Hypermobile wrote:Hi There, Following the Multiwii Project for a while now.

getting into it :-). I like it.

But why is the Nav code seperate from the MW2.3?
Shouldn't this Nav code be MW2.4 Beta?

keep up the good work.

This is how multiwii dev works. If you develop a new function, you have to do it in a separate branch, once it ready then you can integrate into _shared...

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

Re: Quick update

Post by felixrising »

EOSBandi wrote:
Rob wrote:
EOSBandi wrote:I'm working on the code, but weather does not allow outside testing, which is important to dial in the autoland parameters. I hope weather clears out at the second half of the week and I can make the necessary testing and release the next cycle.

Meanwhile farnell finally got these in stock again :
WP_20140109_20_27_32_Pro.jpg


These are real multi constellation gps modules (GPS+GLONASS+GALIEO) and they are capable to output RAW gps phase data. (RTK anyone ? )
Time to make some PCB's


Do you need somebody draw the schematic and PCB?
If you need a proto, I can arrange something.

Rob

Thanks ROB, but I have everything at home to do PCB's up to 8-10mil track width :D


Interesting stuff... especially with piksi kickstarter successfully funded, and being oss and oshw... They're also actively talking to various flight controller teams

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

Re: GPS NAV

Post by EOSBandi »

Ok guys.
Beta5 of the navi code is out, and also the Pre8(b5) of the WinGUI.

CAUTION ::: when using autoland!
ALWAYS disarm your copter manually too, and switch off MISSION or LAND mode before approaching your landed copter !!!!!




Quick summary of changes "
WinGUI
Added geofence //todo: draw fence on map
add throttle control and baro mode control settings
add version checking. Now navi functions are disabled with plain MW 2.3
Added LAND command
Map exception error fix (drawing MarkerRect fails at extra zoom outs)
Added battery gauge
rearrange indicator lamps on Flight Deck
show indicator lamps on Mission page
Moved context menu to Mission page

Navi Code
Added Geofencing
Added capability flag to indicate navi capability
LAND mission step
Added LAND box to test autolanding. Very likely it will be removed in the future....
RTH parameter1 indicates that copter lands once it arrived at home
RTH mission step altitude is now overrides the global RTH alt setting. (if not zero)
Codebase merged with _shared R1648. Now it's up to date...


The biggest news it the autoland capability. I would ask you to test it, since it is necessary to have a 100% working autoland to move forward with failsafe stuff.
The land speed parameter is between 0 and 256. 100 approx. equals with 50cm/s descent speed. I would recommend to use it. Also you will need a properly tuned althold !!!

Now you can set parameter1 in the RTH mission step to indicate that copter must land when arrived at home.
(please note that when land is activated copter will wait for 5 seconds to settle down before start descending.)
When copter landed you can pull back throttle to disarm immediately or wait for 5 seconds (then copter will disarm).
ALWAYS disarm your copter manually too, and switch off MISSION or LAND mode before approaching your landed copter !!!!!


Takeover BARO mode - when starting a mission copter will automatically switch to BARO,
Ignore Thorttle ... - When doing a mission and RTH copter will not respond to throttle changes

turkawa
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Post by turkawa »

I have an 2 interesting problems..

1-In 3drradio.exe the signal is healthy and noise is low.
In wingui noise is high and signal is low.
And after the initial connection (which starts as %100) the signal goes down fast and it loses telemetry in less than a minute.
but connection stays and stays strong.. (images below)

Re uploading the b5 fixed gps not showing at telemetry!
2-With <MultiWii_2.3-navi-b4-xmas> telemetry and/or bluetooth not showing gps connection
but with standard multiwii 2.3 they both shows gps just fine..


what am i doing wrong?

PS: EOSBandi: thanks for the tip about language settings..Finally i am using wingui :)
Attachments
Capture.PNG
3dr.PNG

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

Re: GPS NAV

Post by EOSBandi »

RSSI and NOISE was mixed in B4, now it is OK in B5(pre8).
Is it the same with B5 ?

turkawa wrote:I have an 2 interesting problems..

1-In 3drradio.exe the signal is healthy and noise is low.
In wingui noise is high and signal is low.
And after the initial connection (which starts as %100) the signal goes down fast and it loses telemetry in less than a minute.
but connection stays and stays strong.. (images below)


Re uploading the b5 fixed gps not showing at telemetry!
2-With <MultiWii_2.3-navi-b4-xmas> telemetry and/or bluetooth not showing gps connection
but with standard multiwii 2.3 they both shows gps just fine..


what am i doing wrong?

PS: EOSBandi: thanks for the tip about language settings..Finally i am using wingui :)

turkawa
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Post by turkawa »

Nope!!..
All working great on b5..
sorry for confusing you..
when i started to write the post there was no b5 :)
I wish i have waited 2 minutes more before posting it!

Imen
Posts: 20
Joined: Thu Sep 27, 2012 5:11 pm

Re: GPS NAV

Post by Imen »

EOSBandi wrote:Ok guys.
Beta5 of the navi code is out, and also the Pre8(b5) of the WinGUI.

CAUTION ::: when using autoland!
ALWAYS disarm your copter manually too, and switch off MISSION or LAND mode before approaching your landed copter !!!!!




Quick summary of changes "
WinGUI
Added geofence //todo: draw fence on map
add throttle control and baro mode control settings
add version checking. Now navi functions are disabled with plain MW 2.3
Added LAND command
Map exception error fix (drawing MarkerRect fails at extra zoom outs)
Added battery gauge
rearrange indicator lamps on Flight Deck
show indicator lamps on Mission page
Moved context menu to Mission page

Navi Code
Added Geofencing
Added capability flag to indicate navi capability
LAND mission step
Added LAND box to test autolanding. Very likely it will be removed in the future....
RTH parameter1 indicates that copter lands once it arrived at home
RTH mission step altitude is now overrides the global RTH alt setting. (if not zero)
Codebase merged with _shared R1648. Now it's up to date...


The biggest news it the autoland capability. I would ask you to test it, since it is necessary to have a 100% working autoland to move forward with failsafe stuff.
The land speed parameter is between 0 and 256. 100 approx. equals with 50cm/s descent speed. I would recommend to use it. Also you will need a properly tuned althold !!!

Now you can set parameter1 in the RTH mission step to indicate that copter must land when arrived at home.
(please note that when land is activated copter will wait for 5 seconds to settle down before start descending.)
When copter landed you can pull back throttle to disarm immediately or wait for 5 seconds (then copter will disarm).
ALWAYS disarm your copter manually too, and switch off MISSION or LAND mode before approaching your landed copter !!!!!


Takeover BARO mode - when starting a mission copter will automatically switch to BARO,
Ignore Thorttle ... - When doing a mission and RTH copter will not respond to throttle changes


Hi EOSbandi,

how to add the fences, thanks :)

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

Re: GPS NAV

Post by EOSBandi »

Either in config.h or at Flight tuning tab... it called.... FENCE RADIUS and MAX NAV ALTITUDE.
If they are 0 then geofencing is disabled

Hypermobile
Posts: 94
Joined: Mon Jan 13, 2014 8:53 pm

Re: GPS NAV

Post by Hypermobile »

Double post....
Last edited by Hypermobile on Wed Jan 15, 2014 8:26 pm, edited 1 time in total.

Post Reply