Page 3 of 4

Re: Release 2.2 is coming

PostPosted: Sat Mar 02, 2013 2:21 am
by Wayne
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.

Re: Release 2.2 is coming

PostPosted: Sat Mar 02, 2013 8:37 am
by alll
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


:P thanks!
manu

Re: Release 2.2 is coming

PostPosted: Sat Mar 02, 2013 12:01 pm
by Hamburger
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 (?)

Re: Release 2.2 is coming

PostPosted: Sat Mar 02, 2013 9:47 pm
by Sebbi
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 ;-)

Re: Release 2.2 is coming

PostPosted: Sat Mar 02, 2013 10:57 pm
by alexia
thanks everybody for all you hard working!it s a great step for multiwii

Re: Release 2.2 is coming

PostPosted: Sun Mar 03, 2013 11:57 am
by Hamburger
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

Re: Release 2.2 is coming

PostPosted: Sun Mar 03, 2013 8:50 pm
by mikob2d
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 =)

Re: Release 2.2 is coming

PostPosted: Mon Mar 04, 2013 4:45 am
by ecohawk
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

Re: Release 2.2 is coming

PostPosted: Mon Mar 04, 2013 11:06 am
by arduifriki
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.

Re: Release 2.2 is coming

PostPosted: Mon Mar 04, 2013 12:41 pm
by NikTheGreek
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

PostPosted: Mon Mar 04, 2013 12:57 pm
by mikob2d
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 ;)

Re: Release 2.2 is coming

PostPosted: Mon Mar 04, 2013 1:10 pm
by arduifriki
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

PostPosted: Mon Mar 04, 2013 1:36 pm
by Peter
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

PostPosted: Mon Mar 04, 2013 6:55 pm
by AndrejLV
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 ?

Re: Release 2.2 is coming

PostPosted: Mon Mar 04, 2013 7:03 pm
by copterrichie
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

PostPosted: Mon Mar 04, 2013 7:46 pm
by dramida
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.

Re: Release 2.2 is coming

PostPosted: Mon Mar 04, 2013 7:54 pm
by copterrichie
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

PostPosted: Mon Mar 04, 2013 8:32 pm
by ORION
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

Re: Release 2.2 is coming

PostPosted: Mon Mar 04, 2013 11:00 pm
by ezio
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

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 1:02 am
by Alexinparis
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.

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 1:03 am
by Alexinparis
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

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 1:06 am
by Alexinparis
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)

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 1:09 am
by Alexinparis
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.

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 1:12 am
by Alexinparis
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

PostPosted: Tue Mar 05, 2013 2:45 am
by ezio
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 :D

Regards,
Bart

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 8:29 am
by arduifriki
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. :D

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 10:06 am
by mikob2d
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.

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 12:49 pm
by Stars112
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

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 1:00 pm
by mikob2d
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

PostPosted: Tue Mar 05, 2013 1:27 pm
by ORION
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

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 2:55 pm
by crono
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

PostPosted: Tue Mar 05, 2013 6:00 pm
by PatrikE

Re: Release 2.2 is coming

PostPosted: Tue Mar 05, 2013 6:36 pm
by ORION


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

PostPosted: Tue Mar 05, 2013 10:37 pm
by Hamburger
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 :)

Re: Release 2.2 is coming

PostPosted: Wed Mar 06, 2013 12:00 am
by Alexinparis
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

Re: Release 2.2 is coming

PostPosted: Wed Mar 06, 2013 12:11 am
by Alexinparis
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 ?

Re: Release 2.2 is coming

PostPosted: Wed Mar 06, 2013 12:13 am
by Alexinparis
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 ?

Re: Release 2.2 is coming

PostPosted: Wed Mar 06, 2013 12:54 am
by Alexinparis
I've just uploaded a new pre2.2
and updated/merged the release note according to the last posts. (in the first post also)

Re: Release 2.2 is coming

PostPosted: Wed Mar 06, 2013 4:11 am
by Mark_K
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:
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

PostPosted: Wed Mar 06, 2013 9:37 am
by Hamburger
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

PostPosted: Wed Mar 06, 2013 12:27 pm
by Stars112
Alexinparis wrote:it's not the wish thread ;)

Sorry :oops:
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

PostPosted: Wed Mar 06, 2013 10:11 pm
by crono
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

Re: Release 2.2 is coming: MINCHECK change?

PostPosted: Thu Mar 07, 2013 9:42 pm
by Quad FRITZ
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

gui: RECONNECT does not work for me

PostPosted: Thu Mar 07, 2013 11:29 pm
by Hamburger
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?

Re: Release 2.2 is coming

PostPosted: Thu Mar 07, 2013 11:43 pm
by copterrichie
I just confirmed on my macosx 10.7.5, the newest gui does work.

Re: Release 2.2 is coming

PostPosted: Thu Mar 07, 2013 11:54 pm
by Alexinparis
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

Re: Release 2.2 is coming: MINCHECK change?

PostPosted: Fri Mar 08, 2013 12:08 am
by Alexinparis
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)

Re: Release 2.2 is coming

PostPosted: Fri Mar 08, 2013 12:11 am
by Alexinparis
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.

Re: Release 2.2 is coming

PostPosted: Fri Mar 08, 2013 12:16 am
by copterrichie
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

PostPosted: Fri Mar 08, 2013 12:40 am
by Sebbi
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?