Release 2.2 is coming
Re: Release 2.2 is coming
The release notes do not include AP_MODE, how it works and how to disable it.
r_1356 does not compile for me with AP_MODE commented out.
Thank you for all your hard work.
r_1356 does not compile for me with AP_MODE commented out.
Thank you for all your hard work.
Re: Release 2.2 is coming
Alexinparis wrote:This is something that will change for next release, I promise
annex .ino -> .c+.h or .h only
most probably with a structure like this:
http://code.google.com/p/mwc-ng/source/ ... comp%2Fsrc

manu
Re: Release 2.2 is coming
re Release notes: from wishlist v2.1 viewtopic.php?f=7&t=2077#p18946
+ force sensors orientation to override board specific defaults now
+ 3 sets of configuration in eeprom, user selectable via Stick combos
+ spektrum 12 channel
+ eeprom sanity checking (especially useful after recompilation with different feature set)
+ LCDconfig menu: with THROTTLE=High, increment is 10 times of normal
+ optional fixate cycle time (by burning cpu time away)
+ optional Repeat the Gyrocalibration if the copter is moved in the process of calibration
+ optional permanent logging to eeprom
+ optional spektrum bind support
+ servos are moved to neutral position during calibration and lcd.configuration
+ perfect euler angle computation in case of 9DOF (better heading)
+ allow override of motor/servo mixing from config.h - no need to edit Output.ino
+ faster cycle time than with v2.1 (?)
+ force sensors orientation to override board specific defaults now
+ 3 sets of configuration in eeprom, user selectable via Stick combos
+ spektrum 12 channel
+ eeprom sanity checking (especially useful after recompilation with different feature set)
+ LCDconfig menu: with THROTTLE=High, increment is 10 times of normal
+ optional fixate cycle time (by burning cpu time away)
+ optional Repeat the Gyrocalibration if the copter is moved in the process of calibration
+ optional permanent logging to eeprom
+ optional spektrum bind support
+ servos are moved to neutral position during calibration and lcd.configuration
+ perfect euler angle computation in case of 9DOF (better heading)
+ allow override of motor/servo mixing from config.h - no need to edit Output.ino
+ faster cycle time than with v2.1 (?)
Last edited by Hamburger on Sun Mar 03, 2013 8:48 pm, edited 1 time in total.
Re: Release 2.2 is coming
I made a diff from the 15.7.2012 release-2.1 commit. Addtitional changes I could identify:
+ new file Alarms.ino, probably with new stuff in there that wasn't in Buzzer.ino or LED.ino (both gone)
+ GPS.ino: MTK support, GPS Lead Filter, Ublox support
+ IMU.ino: default ACC LPF factor reduced from 100 to 4, gyro/acc complementary filter value increased from 400 to 600 and gyro/mag complementary filter now set to 250 instead of 200, gyro scale factor changed from 2380 to 2279, _atan2() function changed, accelerometer now used below 1.15G and above 0.8G instead of previous 1.4G/0.6G settings, changed calculation of pitch and heading (more accurate), calculation of barometric altitude changed to include temperature, improved baro hold (PID) algorithm that includes the accelerometer z-axis
+ LCD.ino: lots of changes I am not familiar with
+ Output.ino: PWM values got adjusted (no +2), more PWM outputs on Arduino Mega, MY_PRIVATE_MIXING (support for custom mixtables ... where is the documentation for that feature?), Hex6H mix, AUX channels used for gimbal can be set now, GOVERNOR (maintain RPM through ptich/voltage changes), normalisation of motors values (LEAVE_HEADROOM_FOR_MOTORS, placement in config.h suggests it has something to do with custom mixes, but the code seems universal),
+ RX.ino: variable number of channels possible (12 channels Spektrum), failsafe detection (on throttle pin, GoodPulses?), PPM_SUM on throttle pin on MEGA boards
+ Sensors.ino: MPU3050 (gyro), MMA8451Q (acc), better HMC5883 (compass) support, gyro calibration failsafe, SENSORS_TILT_45DEG_LEFT/RIGHT to change X/P configuration, longer gyro and acc calibration periods, barometer code changed (uses temperature, faster updates)
+ Serial.ino: Promicro (new) & MEGA (revised) use of more than one UART support, MSPs changed but is still version 0 (MSP_RC supports more than 8 channels, MSP_ALTITUDE with variometer info, MSP_BAT renamed to MSP_ANALOG and supports rssi now, new MSP_BOXIDS, MSP_WP_SET is now MSP_SET_WP, new MSP_SELECT_SETTING to select settings, new MSP_SET_HEAD to define new heading hold direction, new MSP_BIND, new MSP_DEBUGMSG
+ config.h: support for new boards (SIRIUSGPS, SIRIUS_AIR, SIRIUS_AIR_GPS, MICROWII, GY_521, MultiWiiMega, DESQUARED6DOFV2GO, DESQUARED6DOFV4, LADYBIRD, MEGAWAP_V2_STD, MEGAWAP_V2_ADV, HK_MultiWii_SE_V2, HK_MultiWii_328P, RCNet_FC, FLYDU_ULTRA), Bi-Copter pitch direction setting, USE_THROTTLESERVO (for airplanes), COLLECTIVE_RANGE changed (second value not offset anymore), overrides for pins (bat, led, buzzer), AP_MODE, LANDING_LIGHTS_ADOPT_LED_FLASHER_PATTERN, OSD_SWITCH, LCD_TTY, LCD_DUMMY, LCD keys changed, PILOTLAMP, variometer options, BOARD_NAME, CYCLETIME_FIXATED, LOG_PERMANENT (logging of certain values to eeprom)
and last but not least:
+ MultiWii.ino: Horizon mode (acts like Angle mode - formally known as ACC mode - when sticks are neutral), go_arm() and go_disarm() and server2Neutral() functions (who named these? consistency!), new stick handling code, GPS_LED_INDICATOR, better (more efficient) task loop, fixed cycle time code, altitude hold related throttle handling code
That's all I could identify with a quick look through the code. Might have forgotten something and I don't understand all the LCD code well enough to know what changed there.
P.S.: It would easier to compile changelogs with an issue tracker and commits refering to the issues when a feature is implemented or bug got fixed
+ new file Alarms.ino, probably with new stuff in there that wasn't in Buzzer.ino or LED.ino (both gone)
+ GPS.ino: MTK support, GPS Lead Filter, Ublox support
+ IMU.ino: default ACC LPF factor reduced from 100 to 4, gyro/acc complementary filter value increased from 400 to 600 and gyro/mag complementary filter now set to 250 instead of 200, gyro scale factor changed from 2380 to 2279, _atan2() function changed, accelerometer now used below 1.15G and above 0.8G instead of previous 1.4G/0.6G settings, changed calculation of pitch and heading (more accurate), calculation of barometric altitude changed to include temperature, improved baro hold (PID) algorithm that includes the accelerometer z-axis
+ LCD.ino: lots of changes I am not familiar with
+ Output.ino: PWM values got adjusted (no +2), more PWM outputs on Arduino Mega, MY_PRIVATE_MIXING (support for custom mixtables ... where is the documentation for that feature?), Hex6H mix, AUX channels used for gimbal can be set now, GOVERNOR (maintain RPM through ptich/voltage changes), normalisation of motors values (LEAVE_HEADROOM_FOR_MOTORS, placement in config.h suggests it has something to do with custom mixes, but the code seems universal),
+ RX.ino: variable number of channels possible (12 channels Spektrum), failsafe detection (on throttle pin, GoodPulses?), PPM_SUM on throttle pin on MEGA boards
+ Sensors.ino: MPU3050 (gyro), MMA8451Q (acc), better HMC5883 (compass) support, gyro calibration failsafe, SENSORS_TILT_45DEG_LEFT/RIGHT to change X/P configuration, longer gyro and acc calibration periods, barometer code changed (uses temperature, faster updates)
+ Serial.ino: Promicro (new) & MEGA (revised) use of more than one UART support, MSPs changed but is still version 0 (MSP_RC supports more than 8 channels, MSP_ALTITUDE with variometer info, MSP_BAT renamed to MSP_ANALOG and supports rssi now, new MSP_BOXIDS, MSP_WP_SET is now MSP_SET_WP, new MSP_SELECT_SETTING to select settings, new MSP_SET_HEAD to define new heading hold direction, new MSP_BIND, new MSP_DEBUGMSG
+ config.h: support for new boards (SIRIUSGPS, SIRIUS_AIR, SIRIUS_AIR_GPS, MICROWII, GY_521, MultiWiiMega, DESQUARED6DOFV2GO, DESQUARED6DOFV4, LADYBIRD, MEGAWAP_V2_STD, MEGAWAP_V2_ADV, HK_MultiWii_SE_V2, HK_MultiWii_328P, RCNet_FC, FLYDU_ULTRA), Bi-Copter pitch direction setting, USE_THROTTLESERVO (for airplanes), COLLECTIVE_RANGE changed (second value not offset anymore), overrides for pins (bat, led, buzzer), AP_MODE, LANDING_LIGHTS_ADOPT_LED_FLASHER_PATTERN, OSD_SWITCH, LCD_TTY, LCD_DUMMY, LCD keys changed, PILOTLAMP, variometer options, BOARD_NAME, CYCLETIME_FIXATED, LOG_PERMANENT (logging of certain values to eeprom)
and last but not least:
+ MultiWii.ino: Horizon mode (acts like Angle mode - formally known as ACC mode - when sticks are neutral), go_arm() and go_disarm() and server2Neutral() functions (who named these? consistency!), new stick handling code, GPS_LED_INDICATOR, better (more efficient) task loop, fixed cycle time code, altitude hold related throttle handling code
That's all I could identify with a quick look through the code. Might have forgotten something and I don't understand all the LCD code well enough to know what changed there.
P.S.: It would easier to compile changelogs with an issue tracker and commits refering to the issues when a feature is implemented or bug got fixed

Re: Release 2.2 is coming
thanks everybody for all you hard working!it s a great step for multiwii
Re: Release 2.2 is coming
re Release notes: (from the updated README.txt)
===============================================================
For Users:
===============================================================
Documentation for releases should be in the official wiki at
http://www.multiwii.com/wiki
For development versions you are on your own - good luck.
For discussion and questions the official forum is at
http://www.multiwii.com/forum
===============================================================
For Users:
===============================================================
Documentation for releases should be in the official wiki at
http://www.multiwii.com/wiki
For development versions you are on your own - good luck.
For discussion and questions the official forum is at
http://www.multiwii.com/forum
Re: Release 2.2 is coming
Hi,
I don't know if it's my setup or a multiwii-2.2pre bug, but i'm not able to compile with my CRIUS_AIO_PRO_V1 board on Mega 2560 target in Arduino 1.0.1
first error is : "error: ISO C++ forbids incrementing a pointer of type 'void*'"
I just uncommented " CRIUS_AIO_PRO_V1 " in config.h and the QUAD_X one.
Here is my compile log:
http://pastebin.com/W5jHmF1e
Thanks for your help =)
I don't know if it's my setup or a multiwii-2.2pre bug, but i'm not able to compile with my CRIUS_AIO_PRO_V1 board on Mega 2560 target in Arduino 1.0.1
first error is : "error: ISO C++ forbids incrementing a pointer of type 'void*'"
I just uncommented " CRIUS_AIO_PRO_V1 " in config.h and the QUAD_X one.
Here is my compile log:
http://pastebin.com/W5jHmF1e
Thanks for your help =)
Re: Release 2.2 is coming
mlkob2d
I can't comment on your compile log but I just loaded this new firmware using the same board types as you and it worked fine for me. I also set up for GPS so I changed that in config.h.
The only difference I see is that I use Arduino 1.0.3
ecohawk
I can't comment on your compile log but I just loaded this new firmware using the same board types as you and it worked fine for me. I also set up for GPS so I changed that in config.h.
The only difference I see is that I use Arduino 1.0.3
ecohawk
-
- Posts: 4
- Joined: Mon Mar 04, 2013 10:47 am
Re: Release 2.2 is coming
Hi All ,
Thank you to all the people of this community for the hard work you do.
I would like to know if it is possible to have something like a FAILSAFE_RTH option. I think it is the safest caracteristic we can have inside the FC of our copters.
I guess it would be easy to set GPSHOME mode ON just checking the failsafeCnt variable.
I have hacked the cheap Turnigy RF9X-V2 module getting a wire from the led indicator, in order to have a DIY failsafe option. The wire is connected to an analog input of my Crius card, so I can trigger the failsafe just swithcing off my radio emitter. I define in config.h a RSSIPIN as A6 input and then I trigger the failsafe in the mail loop if that value is less than 0.6V. It works fine and is a cheap solution if you have a cheap radio w/o failsafe, but this "only" lands the copter.
But independently of this I think It would be fine to get an automatic RTH if we lost radio contact with the copter.
Thank you to all the people of this community for the hard work you do.
I would like to know if it is possible to have something like a FAILSAFE_RTH option. I think it is the safest caracteristic we can have inside the FC of our copters.
I guess it would be easy to set GPSHOME mode ON just checking the failsafeCnt variable.
I have hacked the cheap Turnigy RF9X-V2 module getting a wire from the led indicator, in order to have a DIY failsafe option. The wire is connected to an analog input of my Crius card, so I can trigger the failsafe just swithcing off my radio emitter. I define in config.h a RSSIPIN as A6 input and then I trigger the failsafe in the mail loop if that value is less than 0.6V. It works fine and is a cheap solution if you have a cheap radio w/o failsafe, but this "only" lands the copter.
But independently of this I think It would be fine to get an automatic RTH if we lost radio contact with the copter.
- NikTheGreek
- Posts: 348
- Joined: Thu Dec 08, 2011 4:17 pm
- Location: Greece
- Contact:
Re: Release 2.2 is coming
I have hacked the cheap Turnigy RF9X-V2 module getting a wire from the led indicator
Could you please give us more details ?
Re: Release 2.2 is coming
ecohawk wrote:mlkob2d
I can't comment on your compile log but I just loaded this new firmware using the same board types as you and it worked fine for me. I also set up for GPS so I changed that in config.h.
The only difference I see is that I use Arduino 1.0.3
ecohawk
That's it ! =)
Works fine now with arduino 1.0.3 now with same sources.
Thanks for your answer

-
- Posts: 4
- Joined: Mon Mar 04, 2013 10:47 am
Re: Release 2.2 is coming
NikTheGreek wrote:I have hacked the cheap Turnigy RF9X-V2 module getting a wire from the led indicator
Could you please give us more details ?
Sure !, I didnt take photos during the proccess, but it was very easy. (I will try to take some photos soon).
I soldered a wire to the led that the RF9X-V2 has to indicate it is connected to the radio emitter. This led goes OFF if you switch off the radio, i.e. if you lose your radio link. Then you connect this wire to a free analog input from your FC card.
Then in Multiwwi code I added in config.h
Code: Select all
#define RSSIPIN A6
And in MultiWii.ino, in failsafe area:
Code: Select all
if (analogRead(A6) < 600){ //check input voltage from hacked Turnigy 9x receiver
if(failsafeCnt > 20) failsafeCnt -= 20; else failsafeCnt = 0; }// if its OK then clear failsafeCnt
}
This is a newbie hack, as I am. Easy to do, and far from be perfect, but it works. I think this can prevent some flyaways.
To get the GPS_HOME active with a triggered failsafe I think it is easy to change the code, but I prefer that to be changed by the masters.

NOTE: The idea is not mine, it comes from here: http://www.multiwii.com/forum/viewtopic.php?f=13&t=1615
(sorry if this if a bit off-topic, but I was sure that in the new 2.2 version the RTH FAILSAFE was to be included).
Re: Release 2.2 is coming
Peter wrote:Alexinparis wrote:I don't think it's a known problem. I don't remember having such a problem with my setups. I will try to reproduce this arm issue.
I upgraded my quad to r1349 and I haven't seen the problem again. Will test further, trying endpoint adjustment and my plane.
I upgraded my plane to 1356 and I kept the same problem. I even swapped the board to a Crius SE. Same problem.
When I try to arm, the cycle times get to high to be usable. Yesterday morning there were no problems, yesterday evening the problems were back. Nothing changed in that time.
My quad does not have these problems. Seems related to airplane mode.
Are there others that test the airplane mode of 2.2?
Re: Release 2.2 is coming
On horizon and on acro modes for faster small loop we have to drop throttle but if we drop throttle to zero the copter just drop in upside down position without steering possibility. This absence of steering also is a source of unstable descend at zero throttle, but people often use fast descend method.
Is it possible to allow steering and stabilisation at all flight phases and at any throttle stick positions but not at the ground ?
Is it possible to allow steering and stabilisation at all flight phases and at any throttle stick positions but not at the ground ?
Last edited by AndrejLV on Mon Mar 04, 2013 7:39 pm, edited 1 time in total.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Release 2.2 is coming
AndrejLV wrote:On horizon and on acro modes for faster small loop we have to drop throttle but if we drop throttle to zero the copter just drop in upside down position without steering possibility.
I am not sure if this is related however, what I am seeing is a change in the axis[PITCH] value based upon the throttle stick position. This happens while the copter is sitting motionless on my work bench and in all three modes.
viewtopic.php?f=8&t=3180
Re: Release 2.2 is coming
My Crius AIOP tricopter drops when activating alt hold.
http://www.youtube.com/watch?v=61igHwNymK8
I was using latest dev version 1349.
The throttle was in middle position.
http://www.youtube.com/watch?v=61igHwNymK8
I was using latest dev version 1349.
The throttle was in middle position.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Release 2.2 is coming
copterrichie wrote:AndrejLV wrote:On horizon and on acro modes for faster small loop we have to drop throttle but if we drop throttle to zero the copter just drop in upside down position without steering possibility.
I am not sure if this is related however, what I am seeing is a change in the axis[PITCH] value based upon the throttle stick position. This happens while the copter is sitting motionless on my work bench and in all three modes.
viewtopic.php?f=8&t=3180
My problem was fixed with a EEPROM reset, seems in my situation, the dynP8 and dynD8 were not set to zero. I had never used the Dynamic PID settings before so when I installed the news version of the firmware, items were shifted about.
Note: There was talk in the past about doing an EEPROM validation check, maybe that discussion should be revisited.
Re: Release 2.2 is coming
Hey guys
Before the release of 2.2 I want to add something: I tried to use Bicopter with the MultiWii_dev_r1311 version but it doesn't work properly: The two servos do not work on pin 2 and 6 (mega board). However, if I plug in a servo on pin 12 it works but only one and the correct one should be 2 or 6 right?
Does anyone know, where I can change that: I looked into the def.h file but I don't really see where to change what to remove the error!?
I tried to change the numbers under:
but it had no effect?
Or has this been corrected in the lastest dev? (there's nothing written in the change.txt file).
BTW: In MW 2.1 the BiCopter configuration works fine.
Regards,
ORION
Before the release of 2.2 I want to add something: I tried to use Bicopter with the MultiWii_dev_r1311 version but it doesn't work properly: The two servos do not work on pin 2 and 6 (mega board). However, if I plug in a servo on pin 12 it works but only one and the correct one should be 2 or 6 right?
Does anyone know, where I can change that: I looked into the def.h file but I don't really see where to change what to remove the error!?
I tried to change the numbers under:
Code: Select all
#elif defined(BI)
#define NUMBER_MOTOR 2
#define PRI_SERVO_FROM 4 // use servo from 5 to 6
#define PRI_SERVO_TO 6
but it had no effect?
Or has this been corrected in the lastest dev? (there's nothing written in the change.txt file).
BTW: In MW 2.1 the BiCopter configuration works fine.
Regards,
ORION
Re: Release 2.2 is coming
Hi
I think there is a bug in Serial.ino.
In newest version MSP_WP doesn't work correctly. That is why there is no Home position or Hold position on the map in EZ-GUI
I think I have found what is wrong but I can't test it right now.
Could you verify it for me please ?
In Serial.ino there is now/
headSerialReply(12); -> should be changed to headSerialReply(18);
Bart
I think there is a bug in Serial.ino.
In newest version MSP_WP doesn't work correctly. That is why there is no Home position or Hold position on the map in EZ-GUI
I think I have found what is wrong but I can't test it right now.
Could you verify it for me please ?
In Serial.ino there is now/
Code: Select all
case MSP_WP:
{
int32_t lat = 0,lon = 0;
uint8_t wp_no = read8(); //get the wp number
headSerialReply(12);
if (wp_no == 0) {
lat = GPS_home[LAT];
lon = GPS_home[LON];
} else if (wp_no == 16) {
lat = GPS_hold[LAT];
lon = GPS_hold[LON];
}
serialize8(wp_no);
serialize32(lat);
serialize32(lon);
serialize32(AltHold); //altitude (cm) will come here -- temporary implementation to test feature with apps
serialize16(0); //heading will come here (deg)
serialize16(0); //time to stay (ms) will come here
serialize8(0); //nav flag will come here
}
break;
headSerialReply(12); -> should be changed to headSerialReply(18);
Bart
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
Wayne wrote:The release notes do not include AP_MODE, how it works and how to disable it.
r_1356 does not compile for me with AP_MODE commented out.
Thank you for all your hard work.
Hi,
The release note will be updated with AP_MODE
how to disable it: instead of 40, set 500. If your sticks are inside this range the POS HOLD position won't be changed.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
arduifriki wrote:Hi All ,
Thank you to all the people of this community for the hard work you do.
I would like to know if it is possible to have something like a FAILSAFE_RTH option. I think it is the safest caracteristic we can have inside the FC of our copters.
I guess it would be easy to set GPSHOME mode ON just checking the failsafeCnt variable.
I have hacked the cheap Turnigy RF9X-V2 module getting a wire from the led indicator, in order to have a DIY failsafe option. The wire is connected to an analog input of my Crius card, so I can trigger the failsafe just swithcing off my radio emitter. I define in config.h a RSSIPIN as A6 input and then I trigger the failsafe in the mail loop if that value is less than 0.6V. It works fine and is a cheap solution if you have a cheap radio w/o failsafe, but this "only" lands the copter.
But independently of this I think It would be fine to get an automatic RTH if we lost radio contact with the copter.
in the next release
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
Peter wrote:Peter wrote:Alexinparis wrote:I don't think it's a known problem. I don't remember having such a problem with my setups. I will try to reproduce this arm issue.
I upgraded my quad to r1349 and I haven't seen the problem again. Will test further, trying endpoint adjustment and my plane.
I upgraded my plane to 1356 and I kept the same problem. I even swapped the board to a Crius SE. Same problem.
When I try to arm, the cycle times get to high to be usable. Yesterday morning there were no problems, yesterday evening the problems were back. Nothing changed in that time.
My quad does not have these problems. Seems related to airplane mode.
Are there others that test the airplane mode of 2.2?
Ok, so there is maybe a remaining bug with AIRPLANE model. (to check with PatrikE)
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
AndrejLV wrote:On horizon and on acro modes for faster small loop we have to drop throttle but if we drop throttle to zero the copter just drop in upside down position without steering possibility. This absence of steering also is a source of unstable descend at zero throttle, but people often use fast descend method.
Is it possible to allow steering and stabilisation at all flight phases and at any throttle stick positions but not at the ground ?
I don't think it's a bug. It's the normal behavior since the very beginning of MultiWii.
You have to consider MultiWii for multirotor as a fixed pitch heli: you should never use the lowest throttle position in the air.
The absence of steering in the lowest throttle position is also a security feature in case of a bad reading IMU.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
ezio wrote:Hi
I think there is a bug in Serial.ino.
In newest version MSP_WP doesn't work correctly. That is why there is no Home position or Hold position on the map in EZ-GUI
I think I have found what is wrong but I can't test it right now.
Could you verify it for me please ?
In Serial.ino there is now/Code: Select all
case MSP_WP:
{
int32_t lat = 0,lon = 0;
uint8_t wp_no = read8(); //get the wp number
headSerialReply(12);
if (wp_no == 0) {
lat = GPS_home[LAT];
lon = GPS_home[LON];
} else if (wp_no == 16) {
lat = GPS_hold[LAT];
lon = GPS_hold[LON];
}
serialize8(wp_no);
serialize32(lat);
serialize32(lon);
serialize32(AltHold); //altitude (cm) will come here -- temporary implementation to test feature with apps
serialize16(0); //heading will come here (deg)
serialize16(0); //time to stay (ms) will come here
serialize8(0); //nav flag will come here
}
break;
headSerialReply(12); -> should be changed to headSerialReply(18);
Bart
I'm so sorry Bart for this bug.
I imagine you spend some time to localize it before finding it was inside MW
It's now corrected.
Re: Release 2.2 is coming
Alexinparis wrote:ezio wrote:Hi
I think there is a bug in Serial.ino.
In newest version MSP_WP doesn't work correctly. That is why there is no Home position or Hold position on the map in EZ-GUI
I think I have found what is wrong but I can't test it right now.
Could you verify it for me please ?
In Serial.ino there is now/Code: Select all
case MSP_WP:
{
int32_t lat = 0,lon = 0;
uint8_t wp_no = read8(); //get the wp number
headSerialReply(12);
if (wp_no == 0) {
lat = GPS_home[LAT];
lon = GPS_home[LON];
} else if (wp_no == 16) {
lat = GPS_hold[LAT];
lon = GPS_hold[LON];
}
serialize8(wp_no);
serialize32(lat);
serialize32(lon);
serialize32(AltHold); //altitude (cm) will come here -- temporary implementation to test feature with apps
serialize16(0); //heading will come here (deg)
serialize16(0); //time to stay (ms) will come here
serialize8(0); //nav flag will come here
}
break;
headSerialReply(12); -> should be changed to headSerialReply(18);
Bart
I'm so sorry Bart for this bug.
I imagine you spend some time to localize it before finding it was inside MW
It's now corrected.
yeah it took me a few hours but it is OK.
finally I know what the headSerialReply() is used for

Regards,
Bart
Last edited by ezio on Tue Mar 05, 2013 3:33 pm, edited 1 time in total.
-
- Posts: 4
- Joined: Mon Mar 04, 2013 10:47 am
Re: Release 2.2 is coming
Alexinparis wrote:arduifriki wrote:
But independently of this I think It would be fine to get an automatic RTH if we lost radio contact with the copter.
in the next release
Thank you Alex, I`ll wait.

Re: Release 2.2 is coming
Hi back,
I got an arming issue with last version(s), including 2.2pre on Crius AIOPv1.
Motors spins very slowly, and only if i put many throtthle on them to make them start.
Playing with MIN_* settings hasn't help.
Going back to old post-2.1 version solved my problem, while last one before 2.2-pre doesn't.
I used same config.h parameters with same mincommand/minthrottle settings in both configs.
My setup: Wii-Esc firmware (latest) , Crius AIOPv1, Arduino 1.0.3
Anybody experiencing same issues ?
Hope that will help.
I got an arming issue with last version(s), including 2.2pre on Crius AIOPv1.
Motors spins very slowly, and only if i put many throtthle on them to make them start.
Playing with MIN_* settings hasn't help.
Going back to old post-2.1 version solved my problem, while last one before 2.2-pre doesn't.
I used same config.h parameters with same mincommand/minthrottle settings in both configs.
My setup: Wii-Esc firmware (latest) , Crius AIOPv1, Arduino 1.0.3
Anybody experiencing same issues ?
Hope that will help.
Re: Release 2.2 is coming
I have two wishes:
1.
Can we set the default value for #define MINCHECK from 1100 to 1030?
The Deadband from 100 is very big. So we have many users they lost the Copter by flying, when the Throttlestick is near down!
I fly since 1.8 with #define MINCHECK 1030 and it is very good to fly.
2. Can anyone bring the Lipoalarm Value 1-3 to the GUI?
So we can change the Lipo (3S/4S) by using other Setup via Stick.
Greetings, Marc
1.
Can we set the default value for #define MINCHECK from 1100 to 1030?
The Deadband from 100 is very big. So we have many users they lost the Copter by flying, when the Throttlestick is near down!
I fly since 1.8 with #define MINCHECK 1030 and it is very good to fly.
2. Can anyone bring the Lipoalarm Value 1-3 to the GUI?
So we can change the Lipo (3S/4S) by using other Setup via Stick.
Greetings, Marc
Re: Release 2.2 is coming
mikob2d wrote:Hi back,
I got an arming issue with last version(s), including 2.2pre on Crius AIOPv1.
Motors spins very slowly, and only if i put many throtthle on them to make them start.
Playing with MIN_* settings hasn't help.
Going back to old post-2.1 version solved my problem, while last one before 2.2-pre doesn't.
I used same config.h parameters with same mincommand/minthrottle settings in both configs.
My setup: Wii-Esc firmware (latest) , Crius AIOPv1, Arduino 1.0.3
Anybody experiencing same issues ?
Hope that will help.
A friend of mine just reported me that he got the same problem with same card and same motors (NTM2830) , but with HK ESC's stock firmware so it doesn't seems to be Wii-ESC related.
Re: Release 2.2 is coming
Ok, short update regarding BiCopter,
I tested the BiCopter configration in the latest Multiwii Dev (pre 2.2) and problem remains!? The BiCopter does not fly with Multiwii pre2.2! I someone could tell where I have to look to correct the problem I would do, but I don't know where to start (def.h, output.ino,...?)
It is better now, because one servo (on D2 works fine, but none of the other outputs (except the D3 &D5 for ESCs)) have a signal on my crius v2 pro (atmega2560) board.
PS: What is dualcopter in multiwii? I couldn't find any documentation regarding this?
Regards,
ORION
I tested the BiCopter configration in the latest Multiwii Dev (pre 2.2) and problem remains!? The BiCopter does not fly with Multiwii pre2.2! I someone could tell where I have to look to correct the problem I would do, but I don't know where to start (def.h, output.ino,...?)
It is better now, because one servo (on D2 works fine, but none of the other outputs (except the D3 &D5 for ESCs)) have a signal on my crius v2 pro (atmega2560) board.
PS: What is dualcopter in multiwii? I couldn't find any documentation regarding this?
Regards,
ORION
Re: Release 2.2 is coming
I activate the GPS on quadricopter starts to oscillate as fast as ever on what value I have to fix? pid?
Re: Release 2.2 is coming
ORION wrote:
PS: What is dualcopter in multiwii? I couldn't find any documentation regarding this?
Regards,
ORION
DualCopter
http://www.youtube.com/watch?v=-MdvXknHYt8
SingleCopter
http://www.multiwii.com/forum/viewtopic.php?f=8&t=1882&p=17300&hilit=singlecopter#p17300
http://www.youtube.com/watch?NR=1&v=qeZEAznBAJc&feature=endscreen
http://www.youtube.com/watch?v=-MdvXknHYt8
Re: Release 2.2 is coming
PatrikE wrote:ORION wrote:
PS: What is dualcopter in multiwii? I couldn't find any documentation regarding this?
Regards,
ORION
DualCopter
http://www.youtube.com/watch?v=-MdvXknHYt8
SingleCopter
http://www.multiwii.com/forum/viewtopic.php?f=8&t=1882&p=17300&hilit=singlecopter#p17300
http://www.youtube.com/watch?NR=1&v=qeZEAznBAJc&feature=endscreen
http://www.youtube.com/watch?v=-MdvXknHYt8
Hi
thanks for the tip, singleCopter I was already aware of but not dualcopter. Dualcopter seems really interesting.. Have to build one....
Anyway, have to go back to find the bug in the latest pre2.2 release regarding BiCopter...
Regards,
David
Re: Release 2.2 is coming
everybody could join and write some documentation for all the new stuff in the wiki.
Now is a convenient time to do it. Who knows, it may even help reduce lots of questions after release
Now is a convenient time to do it. Who knows, it may even help reduce lots of questions after release

-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
Stars112 wrote:I have two wishes:
1.
Can we set the default value for #define MINCHECK from 1100 to 1030?
The Deadband from 100 is very big. So we have many users they lost the Copter by flying, when the Throttlestick is near down!
I fly since 1.8 with #define MINCHECK 1030 and it is very good to fly.
2. Can anyone bring the Lipoalarm Value 1-3 to the GUI?
So we can change the Lipo (3S/4S) by using other Setup via Stick.
Greetings, Marc
it's not the wish thread

but anyway:
1) If the default 1150 is enough to make the copter fly, there is a serious problem about the motor/propeller choice. config.h is here to let you change what you want.
2) yes, probably in the version after
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
ORION wrote:Hey guys
Before the release of 2.2 I want to add something: I tried to use Bicopter with the MultiWii_dev_r1311 version but it doesn't work properly: The two servos do not work on pin 2 and 6 (mega board). However, if I plug in a servo on pin 12 it works but only one and the correct one should be 2 or 6 right?
Does anyone know, where I can change that: I looked into the def.h file but I don't really see where to change what to remove the error!?
I tried to change the numbers under:Code: Select all
#elif defined(BI)
#define NUMBER_MOTOR 2
#define PRI_SERVO_FROM 4 // use servo from 5 to 6
#define PRI_SERVO_TO 6
but it had no effect?
Or has this been corrected in the lastest dev? (there's nothing written in the change.txt file).
BTW: In MW 2.1 the BiCopter configuration works fine.
Regards,
ORION
I think it works fine for copterrichie.
Are you sure you did not activate something like MEGA_HW_PWM_SERVOS ?
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
crono wrote:I activate the GPS on quadricopter starts to oscillate as fast as ever on what value I have to fix? pid?
default PIDs ?
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
I've just uploaded a new pre2.2
and updated/merged the release note according to the last posts. (in the first post also)
and updated/merged the release note according to the last posts. (in the first post also)
Re: Release 2.2 is coming
BTW, I think one change that should be made for owners of UBlox GPS's that don't reside in Europe is to enable SBAS support for all locations and not just the EGNOS system.
The PRN sat bit fields should all be set to zero's (all SBAS satellites) instead of the EGNOS only satellites in the UBLOX binary init section.
This should help the GPS precision.
edit: I'm not sure how the SBAS test bit should be handled... (EGNOS is currently in test and WAAS for the USA is not)
edit 2:
Here's the fix for USA:
The PRN sat bit fields should all be set to zero's (all SBAS satellites) instead of the EGNOS only satellites in the UBLOX binary init section.
This should help the GPS precision.
edit: I'm not sure how the SBAS test bit should be handled... (EGNOS is currently in test and WAAS for the USA is not)
edit 2:
Here's the fix for USA:
Mark_K wrote:EOSBandi -
On your above recommendation, I upgraded my multiwii software from 2.1 to the current development version. I noticed that the gps.ino file is configured for Europe and EGNOS. I updated the U-BLOX config code to support US and WAAS. I basically commented out the EGNOS line and added the equivalent WAAS line.Code: Select all
// 0xB5,0x62,0x06,0x16,0x08,0x00,0x03,0x07,0x03,0x00,0x51,0x08,0x00,0x00,0x8A,0x41, //set SBAS to EGNOS
0xB5,0x62,0x06,0x16,0x08,0x00,0x01,0x07,0x03,0x00,0x00,0xA0,0x04,0x00,0xD3,0xBD, //set SBAS to WAAS (PRN 138,135,133)
Re: Release 2.2 is coming
Alexinparis wrote:and updated/merged the release note according to the last posts. (in the first post also)
may I suggest you move the 'documentation' section to the top of the README, please?
Re: Release 2.2 is coming
Alexinparis wrote:it's not the wish thread
Sorry

Alexinparis wrote:but anyway:
2) yes, probably in the version after
Many thanks in advance!
Alexinparis wrote:1) If the default 1150 is enough to make the copter fly, there is a serious problem about the motor/propeller choice. config.h is here to let you change what you want.
I am referring not the #define MINTHROTTLE 1150 command!
I am referring to the #define MINCHECK 1100 command. Here is a Deadband from Stickvalue 1000-1100. And that is very big.
Many Users trim the Deadband with the Radio. (Also Warthox! i spoke with him since Landkamp3.12)
Re: Release 2.2 is coming
Alexinparis wrote:crono wrote:I activate the GPS on quadricopter starts to oscillate as fast as ever on what value I have to fix? pid?
default PIDs ?
yes default pid
-
- Posts: 44
- Joined: Wed Apr 25, 2012 11:21 pm
Re: Release 2.2 is coming: MINCHECK change?
Hello-
I had no time to test the new version- anyways- thank you for all the great work!
From my point of view Stars 112 is perfectly correct with his #define MINCHECK 1100 command hint.
Almost had a few crashes before I knew this, so it really might be a good idea to change this number to a lower value a priori?
Due to the need to change just one value I guess it will be pretty easy to put it in the release?
Kind regards
Roman
I had no time to test the new version- anyways- thank you for all the great work!
From my point of view Stars 112 is perfectly correct with his #define MINCHECK 1100 command hint.
Almost had a few crashes before I knew this, so it really might be a good idea to change this number to a lower value a priori?
Due to the need to change just one value I guess it will be pretty easy to put it in the release?
Kind regards
Roman
gui: RECONNECT does not work for me
on macosx 10.5.8 it does not work.
- wire everything up,
-start gui,
- select port manually,
- start button & see graphs
- stop
- exit gui
- start gui again
- reconnect -> nothing
The serialport.txt file contains: /dev/tty.usbserial-A101ABDG;115200
but the gui string for the port is truncated; maybe that causes the non-function?
- wire everything up,
-start gui,
- select port manually,
- start button & see graphs
- stop
- exit gui
- start gui again
- reconnect -> nothing
The serialport.txt file contains: /dev/tty.usbserial-A101ABDG;115200
but the gui string for the port is truncated; maybe that causes the non-function?
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Release 2.2 is coming
I just confirmed on my macosx 10.7.5, the newest gui does work.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
Hamburger wrote:Alexinparis wrote:and updated/merged the release note according to the last posts. (in the first post also)
may I suggest you move the 'documentation' section to the top of the README, please?
yes, of course
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming: MINCHECK change?
Stars112 wrote:I am referring not the #define MINTHROTTLE 1150 command!
I am referring to the #define MINCHECK 1100 command. Here is a Deadband from Stickvalue 1000-1100. And that is very big.
Many Users trim the Deadband with the Radio. (Also Warthox! i spoke with him since Landkamp3.12)
Quad FRITZ wrote:Hello-
I had no time to test the new version- anyways- thank you for all the great work!
From my point of view Stars 112 is perfectly correct with his #define MINCHECK 1100 command hint.
Almost had a few crashes before I knew this, so it really might be a good idea to change this number to a lower value a priori?
Due to the need to change just one value I guess it will be pretty easy to put it in the release?
ok, I understand your view.
#define MINCHECK 1100
#define MAXCHECK 1900
will be moved in config.h if you want to adjust it for the release after
about the fact "So we have many users they lost the Copter by flying"
I suppose you mean you can disarm the copter in flight with min throttle+yaw left or min throttle+roll left, and the 100 deadband seems high.
It was already debated a long time ago, and it was the reason why ARM BOX was introduced: when a white box of this function is checked, it is impossible to ARM/DISARM just via the sticks (only one option is possible, not both)
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Release 2.2 is coming
copterrichie wrote:I just confirmed on my macosx 10.7.5, the newest gui does work.
I think Hamburger only mentions a problem about the RECONNECT button on macosx.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Release 2.2 is coming
Alexinparis wrote:copterrichie wrote:I just confirmed on my macosx 10.7.5, the newest gui does work.
I think Hamburger only mentions a problem about the RECONNECT button on macosx.
Oh, that has not worked for sometime now when clicking the Disconnect, I get a MultiWiiConf quit unexpectedly message. I figured it has more to do with JAVA verse the GUI.
Re: Release 2.2 is coming
Same here btw ... the GUI does crash half the time (not responding) when disconnecting. Windows 7 64bit using the 32bit version of the GUI. Killing the Java process lets me reconnect and while the process is still alive the com port is blocked for other applications. RXTX bug?