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

Re: GPS NAV

Postby EOSBandi » Sat Jan 04, 2014 4:16 pm

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
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby -ralf- » Sat Jan 04, 2014 6:37 pm

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)?
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: GPS NAV

Postby EOSBandi » Sat Jan 04, 2014 10:33 pm

-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.
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby schnupperm » Mon Jan 06, 2014 12:15 am

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.)
schnupperm
 
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Postby crazyal » Mon Jan 06, 2014 12:45 am

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.
crazyal
 
Posts: 84
Joined: Tue Sep 04, 2012 11:25 pm

Re: GPS NAV

Postby EOSBandi » Mon Jan 06, 2014 1:29 am

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.
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby Imen » Mon Jan 06, 2014 3:44 am

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
Imen
 
Posts: 20
Joined: Thu Sep 27, 2012 5:11 pm

Re: GPS NAV

Postby schnupperm » Mon Jan 06, 2014 12:32 pm

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

Postby schnupperm » Tue Jan 07, 2014 7:36 pm

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.
schnupperm
 
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Postby EOSBandi » Tue Jan 07, 2014 8:32 pm

Are you talking about manual alt change in BARO mode or altitude change during mission ?
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby schnupperm » Tue Jan 07, 2014 10:09 pm

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.
schnupperm
 
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Postby Gartenflieger » Wed Jan 08, 2014 6:59 am

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
Gartenflieger
 
Posts: 65
Joined: Sat Oct 01, 2011 10:07 pm
Location: Dortmund, Germany

Re: GPS NAV

Postby EOSBandi » Wed Jan 08, 2014 10:27 am

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...
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby joergw » Wed Jan 08, 2014 10:31 am

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?
joergw
 
Posts: 10
Joined: Wed Jan 08, 2014 10:11 am

Re: GPS NAV

Postby EOSBandi » Wed Jan 08, 2014 10:37 am

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.
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby joergw » Wed Jan 08, 2014 11:33 am

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
joergw
 
Posts: 10
Joined: Wed Jan 08, 2014 10:11 am

Re: GPS NAV

Postby schnupperm » Wed Jan 08, 2014 12:41 pm

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!
schnupperm
 
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Postby EOSBandi » Wed Jan 08, 2014 12:53 pm

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
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby Gartenflieger » Wed Jan 08, 2014 1:13 pm

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
Gartenflieger
 
Posts: 65
Joined: Sat Oct 01, 2011 10:07 pm
Location: Dortmund, Germany

Re: GPS NAV

Postby EOSBandi » Thu Jan 09, 2014 8:29 pm

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

Quick update

Postby EOSBandi » Thu Jan 09, 2014 8:33 pm

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
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby schnupperm » Thu Jan 09, 2014 9:03 pm

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
      }
schnupperm
 
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Postby mopedcrosser » Thu Jan 09, 2014 9:28 pm

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
mopedcrosser
 
Posts: 52
Joined: Sat Feb 23, 2013 12:35 pm

Re: GPS NAV

Postby szakacs » Sat Jan 11, 2014 10:46 pm

Would it be possible to show trim values in the GUI ?
szakacs
 
Posts: 18
Joined: Wed Dec 11, 2013 11:53 pm
Location: Sydney, NSW Australia

Re: Quick update

Postby Rob » Sat Jan 11, 2014 11:37 pm

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
User avatar
Rob
 
Posts: 77
Joined: Sun Apr 03, 2011 4:40 pm

Re: GPS NAV

Postby turkawa » Sat Jan 11, 2014 11:42 pm

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???
turkawa
 
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Postby mopedcrosser » Sun Jan 12, 2014 3:51 pm

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
mopedcrosser
 
Posts: 52
Joined: Sat Feb 23, 2013 12:35 pm

Re: GPS NAV

Postby EOSBandi » Sun Jan 12, 2014 5:03 pm

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

Re: GPS NAV

Postby EOSBandi » Sun Jan 12, 2014 5:10 pm

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

Re: Quick update

Postby EOSBandi » Sun Jan 12, 2014 5:14 pm

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

Re: GPS NAV

Postby EOSBandi » Sun Jan 12, 2014 5:15 pm

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
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby schnupperm » Sun Jan 12, 2014 5:39 pm

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

Postby schnupperm » Sun Jan 12, 2014 5:55 pm

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>
schnupperm
 
Posts: 31
Joined: Tue Jun 25, 2013 1:41 pm

Re: GPS NAV

Postby turkawa » Sun Jan 12, 2014 7:08 pm

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 ,
turkawa
 
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: Quick update

Postby Rob » Sun Jan 12, 2014 10:44 pm

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
Rob
 
Posts: 77
Joined: Sun Apr 03, 2011 4:40 pm

Re: NAV_CONTROLS_HEADING not working on some waypoints

Postby EOSBandi » Mon Jan 13, 2014 6:15 am

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

Re: GPS NAV

Postby EOSBandi » Mon Jan 13, 2014 6:16 am

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 ?
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby turkawa » Mon Jan 13, 2014 9:08 am

EOSBandi wrote:What is your windows language setting ?


Format is Turkish, OS language is English. OS is windows 7.
turkawa
 
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Postby -ralf- » Mon Jan 13, 2014 3:50 pm

Hi András.

don't forget ..... it's Beta-Monday ...... :mrgreen:
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: GPS NAV

Postby EOSBandi » Mon Jan 13, 2014 4:18 pm

-ralf- wrote:Hi András.

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


and it is also Midyear Business Review week at my work :(
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby Hypermobile » Mon Jan 13, 2014 9:01 pm

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.
Hypermobile
 
Posts: 94
Joined: Mon Jan 13, 2014 8:53 pm

Re: GPS NAV

Postby EOSBandi » Tue Jan 14, 2014 8:18 am

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...
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: Quick update

Postby felixrising » Tue Jan 14, 2014 1:01 pm

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
felixrising
 
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: GPS NAV

Postby EOSBandi » Tue Jan 14, 2014 11:28 pm

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
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby turkawa » Tue Jan 14, 2014 11:39 pm

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
turkawa
 
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Postby EOSBandi » Tue Jan 14, 2014 11:58 pm

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 :)
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby turkawa » Wed Jan 15, 2014 12:24 am

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!
turkawa
 
Posts: 29
Joined: Mon Dec 30, 2013 10:47 am

Re: GPS NAV

Postby Imen » Wed Jan 15, 2014 9:06 am

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 :)
Imen
 
Posts: 20
Joined: Thu Sep 27, 2012 5:11 pm

Re: GPS NAV

Postby EOSBandi » Wed Jan 15, 2014 9:15 am

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
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: GPS NAV

Postby Hypermobile » Wed Jan 15, 2014 8:09 pm

Double post....
Last edited by Hypermobile on Wed Jan 15, 2014 8:26 pm, edited 1 time in total.
Hypermobile
 
Posts: 94
Joined: Mon Jan 13, 2014 8:53 pm

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 9 guests

cron