GPS NAV
Re: GPS NAV
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
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
Re: GPS NAV
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)?
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)?
Re: GPS NAV
-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.
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
Re: GPS NAV
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:
2.) is it safe to change Line 292 in IMU.cpp from
to
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.)
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.)
Re: GPS NAV
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 fromCode: Select all
BaroPID = constrain((conf.pid[PIDALT].P8 * error16 >>7), -150, +150);
toCode: 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.
Re: GPS NAV
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.
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.
Re: GPS NAV
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
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
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
Re: GPS NAV
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....
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
Re: GPS NAV
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.
Re: GPS NAV
Are you talking about manual alt change in BARO mode or altitude change during mission ?
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
Re: GPS NAV
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
- Posts: 65
- Joined: Sat Oct 01, 2011 10:07 pm
- Location: Dortmund, Germany
Re: GPS NAV
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
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
Re: GPS NAV
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...
Re: GPS NAV
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?
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?
Re: GPS NAV
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.
Re: GPS NAV
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
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
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
Re: GPS NAV
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!
Re: GPS NAV
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.
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
- Posts: 65
- Joined: Sat Oct 01, 2011 10:07 pm
- Location: Dortmund, Germany
Re: GPS NAV
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.
Re: GPS NAV
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...
Quick update
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
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
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
Re: GPS NAV
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
}
-
- Posts: 52
- Joined: Sat Feb 23, 2013 12:35 pm
Re: GPS NAV
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'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
Re: GPS NAV
Would it be possible to show trim values in the GUI ?
Re: Quick update
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 :
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
Re: GPS NAV
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???
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???
-
- Posts: 52
- Joined: Sat Feb 23, 2013 12:35 pm
Re: GPS NAV
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
Seb
Re: GPS NAV
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.
Re: GPS NAV
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.
Re: Quick update
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 :
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
Re: GPS NAV
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
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
Re: GPS NAV
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
}
-
- Posts: 31
- Joined: Tue Jun 25, 2013 1:41 pm
NAV_CONTROLS_HEADING not working on some waypoints
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:
.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>
Re: GPS NAV
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 ,
Re: Quick update
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 :
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
Re: NAV_CONTROLS_HEADING not working on some waypoints
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.
Re: GPS NAV
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 ?
Re: GPS NAV
EOSBandi wrote:What is your windows language setting ?
Format is Turkish, OS language is English. OS is windows 7.
Re: GPS NAV
Hi András.
don't forget ..... it's Beta-Monday ......
don't forget ..... it's Beta-Monday ......
Re: GPS NAV
-ralf- wrote:Hi András.
don't forget ..... it's Beta-Monday ......
and it is also Midyear Business Review week at my work
-
- Posts: 94
- Joined: Mon Jan 13, 2014 8:53 pm
Re: GPS NAV
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.
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.
Re: GPS NAV
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...
-
- Posts: 244
- Joined: Sat Mar 23, 2013 12:34 am
- Location: Australia
Re: Quick update
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 :
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
Re: GPS NAV
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
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
Re: GPS NAV
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
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
Re: GPS NAV
RSSI and NOISE was mixed in B4, now it is OK in B5(pre8).
Is it the same with B5 ?
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
Re: GPS NAV
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!
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!
Re: GPS NAV
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
Re: GPS NAV
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
If they are 0 then geofencing is disabled
-
- Posts: 94
- Joined: Mon Jan 13, 2014 8:53 pm
Re: GPS NAV
Double post....
Last edited by Hypermobile on Wed Jan 15, 2014 8:26 pm, edited 1 time in total.