GPS NAV

EOSBandi · Post by **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...

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

-ralf- · Post by **-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)?

EOSBandi · Post by **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.

schnupperm · Post by **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.)

crazyal · Post by **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.

EOSBandi · Post by **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.

Imen · Post by **Imen** » Mon Jan 06, 2014 3:44 am

Hi EOS,

just suggest, can you add some progress bar when upload the mission

and then about RSSI maybe this can be the option

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

thanks

schnupperm · Post by **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 · Post by **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.

EOSBandi · Post by **EOSBandi** » Tue Jan 07, 2014 8:32 pm

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

schnupperm · Post by **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.

Gartenflieger · Post by **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

EOSBandi · Post by **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...

joergw · Post by **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?

EOSBandi · Post by **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.

joergw · Post by **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

schnupperm · Post by **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!

EOSBandi · Post by **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.

Gartenflieger · Post by **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.

EOSBandi · Post by **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...

EOSBandi · Post by **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 :

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 · Post by **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
      }

mopedcrosser · Post by **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

szakacs · Post by **szakacs** » Sat Jan 11, 2014 10:46 pm

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

Rob · Post by **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

turkawa · Post by **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???

mopedcrosser · Post by **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

EOSBandi · Post by **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.

EOSBandi · Post by **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.

EOSBandi · Post by **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

EOSBandi · Post by **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

schnupperm · Post by **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 · Post by **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>

turkawa · Post by **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 ,

Rob · Post by **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

EOSBandi · Post by **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.

EOSBandi · Post by **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 ?

turkawa · Post by **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.

-ralf- · Post by **-ralf-** » Mon Jan 13, 2014 3:50 pm

Hi András.

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

EOSBandi · Post by **EOSBandi** » Mon Jan 13, 2014 4:18 pm

-ralf- wrote:Hi András.

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

and it is also Midyear Business Review week at my work

Hypermobile · Post by **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.

EOSBandi · Post by **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...

felixrising · Post by **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

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

EOSBandi · Post by **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

turkawa · Post by **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

EOSBandi · Post by **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

turkawa · Post by **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!

Imen · Post by **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

EOSBandi · Post by **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

Hypermobile · Post by **Hypermobile** » Wed Jan 15, 2014 8:09 pm

Double post....