MultiWii

Hi,

I think it's time to think about the 2.1 release.

things to do:
- we have to summarize the changes with the right credits. will be done in the next try
- we have to update the documentation

the first try is here:
http://code.google.com/p/multiwii/downloads/list

please post here every bug you are aware of on this version (only bugs)

Edit:
- mahowik: HEX mix code to change -> waiting for analysis
- mahowik: GUI cursor to add for better readability of throttle expo function -> done in the next release
- flyman777: GUI displaying problem / GUI is too slow => alternative is to use other GUIs (EOS or kos), or tune the pc display options
- PatrikE: GPS distance to home problem (-32000) , with SERIAL GPS -> seems to be corrected by EOS, in the next release
- gjerbic: typo correction #define MMA7455 -> corrected in the next release
- bill516 and vesparun: problem when activating inflight calibration without buzzer -> corrected in the next release
- VTAIL implementation has to be documented
- polo_fly2: impossible to arm the multi with a gyro only setup: -> corrected in the next release

Nice to hear Alex!

I found 2 bugs:
1) incorrect mixes for HEX6 and HEX6X. We have found out that it has not proportional weight/power for roll and pitch, e.g. for HEX6X:

roll = cos(60)*1/2 + cos(60)*1/2 + 1 = 1.5
pitch = cos(30)*1/2 + cos(30)*1/2 ~= 0.87

As result you need to take it into account during PIDs tuning...

So I propose to change this to:

And you will get proportional weight/power:
roll = cos(60)*4/5 + cos(60)*4/5 + 4/5 = 1.6
pitch = cos(30)*9/10 + cos(30)*9/10 ~= 1.56

For HEX6 the same accordingly...

2) Second one is related to new throttle expo feature.
Here is two issues comparing to alexmos implementation (viewtopic.php?f=7&t=623 I used that before and was so happy ):
1. it's never achieve MAXTHROTTLE. E.g. if MAXTHROTTLE=1900 you will get ~1820 (don't remember exactly)
2. It's hard to find throttle hover point (Throttle value just before copter start flying where should be expo zero point). E.g in alexmos implementation you can just take this value from GUI and put to define. But in current implementation you see some kind of abstract MID value which is not pointed directly to real throttle value.
So in my point of view much better to have real MID/hover value in GUI instead of abstract percentage...

thx-
Alex

tinygps.h: naming convention conflict
it is not a header file; as it includes a fair amount of implementation code, it either should be renamed to Tinygps.ino or the code should be moved into GPS.ino.

Hamburger wrote:tinygps.h: naming convention conflict
it is not a header file; as it includes a fair amount of implementation code, it either should be renamed to Tinygps.ino or the code should be moved into GPS.ino.

Can you elaborate on this? I cannot find any implementation code in there. Moving the content to GPS.ino has been discussed already; the struct definitions are needed both in Sensors.ino (sonar, optical) as well as in GPS.ino, so the code had to be copied to both places. Leaving the header file alone also makes updating to a new tinygps firmware easy (since the structs have to be identical on both sides and tinygps.h is taken right from the tinygps repository).

my error - I was sure to have seen implementation in that file. So it is fine as it is now. I do not understand why this could not be moved to def.h then but the GPS devs would have to clarify that.

SerialGps.
Distance home show -32000 in gui.

Hi Alex,

unfortunatly, the gui is not working well for me.
The AUX checkboxes and RC data bargraphes doesn't display on the screen on my PCs under XP 32 bits ( the same with Ubuntu), always black boxes.
Is there a solution ?
All MWConfs till dev20120605 worked well. What is the matter ?

Sans rancune
Cheers
Claude

PatrikE wrote:SerialGps.
Distance home show -32000 in gui.

during flight or on the desk without home position set (arming) ?

Gusting 30mph winds.... no testing for me today

Tommie wrote:

Hamburger wrote:tinygps.h: naming convention conflict
it is not a header file; as it includes a fair amount of implementation code, it either should be renamed to Tinygps.ino or the code should be moved into GPS.ino.

Can you elaborate on this? I cannot find any implementation code in there. Moving the content to GPS.ino has been discussed already; the struct definitions are needed both in Sensors.ino (sonar, optical) as well as in GPS.ino, so the code had to be copied to both places. Leaving the header file alone also makes updating to a new tinygps firmware easy (since the structs have to be identical on both sides and tinygps.h is taken right from the tinygps repository).

tommie, could you check that the gps pos decoding works correclty in tinygps parser code? add a known coord in bcd and test the output on google maps, i've seen reports of approx 2km error (was there in serial parser too, but was fixed)

in config.h:
for mma 7455[code]
/* I2C accelerometer */

//#define MMA745

should be:
//#define MMA7455

same error in multiwii 2.0

Compile error in sensor tab, toggle beep not defined in this scope, unless you uncomment define buzzer in config.h

My version of the L3G4200D gyro requires address to be 0X68 in sensors.

Cant test fly I've no props and too much wind, thats atmospheric wind not the other.

EOSBandi wrote:

PatrikE wrote:SerialGps.
Distance home show -32000 in gui.

during flight or on the desk without home position set (arming) ?

On the desk with home set.
Unarmed.

EOSBandi wrote:tommie, could you check that the gps pos decoding works correclty in tinygps parser code? add a known coord in bcd and test the output on google maps, i've seen reports of approx 2km error (was there in serial parser too, but was fixed)

I just checked with my copter near the window, using GoogleMaps, it's around 500m off (but stable, distance to home == 1).
I'll try it outside this evening.

Hi,

mahowik wrote:So I propose to change this to:

Code: Select all

#ifdef HEX6X 
motor[0] = PIDMIX(-4/5,+9/10,+1); //REAR_R 
motor[1] = PIDMIX(-4/5,-9/10,+1); //FRONT_R 
motor[2] = PIDMIX(+4/5,+9/10,-1); //REAR_L 
motor[3] = PIDMIX(+4/5,-9/10,-1); //FRONT_L 
motor[4] = PIDMIX(-4/5 ,+0 ,-1); //RIGHT 
motor[5] = PIDMIX(+4/5 ,+0 ,+1); //LEFT
 #endif 

I understand the coeff are not correct in the original version,
but something seems wrong here because the weight of ROLL factor for 4&5 motors shouldn't be the same as the others.


About the THR expo functions:
If I set MAXTRHOTTLE to 1900,
When RC throttle channel reaches 2000, we have the right value: rcCommand[THROTTLE] = 1900
(checked with debug[0]) whatever the value of MID or EXPO.
please check again your conf.

mid value is in the range:
from the stick point of view: [MINCHECK;2000]
from the throttle command point of view: [MINTHROTLE ; MAXTHROTTLE]

I will add a small cursor in the GUI so that you can see where the throttle is in the graph, and correlate easier the hover point.
The logic is a little bit different from alexmos code because the expo curve is apply only on the useful part of the range.

flyman777 wrote:Hi Alex,

unfortunatly, the gui is not working well for me.
The AUX checkboxes and RC data bargraphes doesn't display on the screen on my PCs under XP 32 bits ( the same with Ubuntu), always black boxes.
Is there a solution ?
All MWConfs till dev20120605 worked well. What is the matter ?

Sans rancune
Cheers
Claude

The matter is a multitude of java environments...
I use also win XP 32 bits without any problem.
It is not tied directly with the code of the GUI, and I see no solutions this kind of problem.
One hint is maybe to deactivate hardware acceleration in display settings.

Hopefully we have also another alternative GUIs like EOS one (fully equivalent) or kos one.

gjerbic wrote:in config.h:
for mma 7455[code]
/* I2C accelerometer */

//#define MMA745

should be:
//#define MMA7455

same error in multiwii 2.0

ok, noted

bill516 wrote:Compile error in sensor tab, toggle beep not defined in this scope, unless you uncomment define buzzer in config.h

My version of the L3G4200D gyro requires address to be 0X68 in sensors.

Cant test fly I've no props and too much wind, thats atmospheric wind not the other.

if you select vbat, you must also select buzzer option.
it's written in the config.h file, and Hamburger added an error check.
Is it the situation you encountered ?

@Alex, EOSbandi
to get a working setup similar to COPTERTEST #3 I had to reduce memory footprint. So I inserted #if GPS two times around fragments of the Serial case code fragments specific for GPS handling. Sorry, I had announced this earlier and I would have waited for you guys dealing with it but I needed it now.. It is in r952 in _shared.
Could you please check for side effects
- with GPS (should be none, because all the code is active #if GPS),
and
- without GPS (does it disturb the GUI-MWC communications, if MWC has a message not implemented?

flyman777 wrote:Hi Alex,

unfortunatly, the gui is not working well for me.
The AUX checkboxes and RC data bargraphes doesn't display on the screen on my PCs under XP 32 bits ( the same with Ubuntu), always black boxes.
Is there a solution ?
All MWConfs till dev20120605 worked well. What is the matter ?

I am having the same issue on XP (32bit). The only way to solve it so far is to turn off all video acceleration.

-K

Try to compile the gui in processing as fullscreen application. Worked for me.

Alexinparis wrote:

bill516 wrote:Compile error in sensor tab, toggle beep not defined in this scope, unless you uncomment define buzzer in config.h

My version of the L3G4200D gyro requires address to be 0X68 in sensors.

Cant test fly I've no props and too much wind, thats atmospheric wind not the other.

if you select vbat, you must also select buzzer option.
it's written in the config.h file, and Hamburger added an error check.
Is it the situation you encountered ?

Hi Alex situation is no vbat selected I havnt got that sorted yet so it is left in the commented condition.

Basically my setup is (what I have altered from intial open of sketch):

Copter type Tri
define max throttle 2000
I2C speed to 400kHz
define GY_80
define Yaw-1
define arm via Yaw
define RCAUX2 pin 12
define failsafe
define inflight calibration

With the above settings requires uncomment of buzzer to compile

could we add a lock into define vbat? so buzzer is defined too?

jevermeister wrote:could we add a lock into define vbat? so buzzer is defined too?

Hello
I think a comment behind #define vbat had to suffice.

I do not use the GUI too often, but on my macosx 10.5 it does not look good. The I-values are hardly readable. It's all default values, the last digit is almost completely outside the box and hidden.

Hi

Mixer for Quad Vtail is not optimal here because it doesn't take in count the 40° motor angle and torque yaw force is in opposition to 40° motor thrust.

Motor rotation should be inversed in comparison to a normal quad:



at least Yaw mix should compensate with front motors to avoid inducted roll effect:

#ifdef VTAIL4
motor[0] = PIDMIX(+0,+1, +1); //REAR_R
motor[1] = PIDMIX(-1, -1, -0.64); //FRONT_R
motor[2] = PIDMIX(+0,+1, -1); //REAR_L
motor[3] = PIDMIX(+1, -1, +0.64); //FRONT_L
#endif

And for a perfect rotation in all axis and good CoG Nick, this should be:

#ifdef VTAIL4
motor[0] = PIDMIX(-1,+1, +1); //REAR_R
motor[1] = PIDMIX(-0.64, -0.64, -0.64); //FRONT_R
motor[2] = PIDMIX(+1,+1, -1); //REAR_L
motor[3] = PIDMIX(+0.64, -0.64, +0.64); //FRONT_L
#endif

No need to Yaw_direction = -1 and invert rear motor servos cables anymore.

Hamburger wrote:I do not use the GUI too often, but on my macosx 10.5 it does not look good. The I-values are hardly readable. It's all default values, the last digit is almost completely outside the box and hidden.

The attachment screenshot.jpeg is no longer available

Same on OsX 10.7.x (it is actually release 0622, but it is same for a long time).

crashlander wrote:

Hamburger wrote:I do not use the GUI too often, but on my macosx 10.5 it does not look good. The I-values are hardly readable. It's all default values, the last digit is almost completely outside the box and hidden.

screenshot.jpeg

Same on OsX 10.7.x (it is actually release 0622, but it is same for a long time).

just compile the gui with a new smaler font!
works perfect to me.

if the digits would be left aligned, the numbers would fit. There is space unused on the left of the fields.
Smaller fonts make the GUI less readable.

Hamburger wrote:if the digits would be left aligned, the numbers would fit. There is space unused on the left of the fields.
Smaller fonts make the GUI less readable.

you are right

did this with r840. no problem!

p.s. just test the rc2.1 gui. on my system (win7pro 32) the gui looks fine. digits are left aligned! the font is a bit to big.

mbrak wrote:

crashlander wrote:

Hamburger wrote:I do not use the GUI too often, but on my macosx 10.5 it does not look good. The I-values are hardly readable. It's all default values, the last digit is almost completely outside the box and hidden.

screenshot.jpeg

Same on OsX 10.7.x (it is actually release 0622, but it is same for a long time).

just compile the gui with a new smaler font!
works perfect to me.

???
Mac 10.7.4 13" no problems with any GUI, only the 4th digit of NavR and PosR is a little out of the box.

Hello,

I installed the r949 on my tri yestreday for testing, but did not be able to arm anymore. Tha last ( and a very good running version) before was the dev_20120504.

This tri is very simple config with only the orig. WMP , no ACC and the i2c Oled connected to a Flyduino Mini-Pro 328, Adresses and parameters are not changed in any way.

The r949 is running. The GUI shows everything is fine , but the status LED is blinking at about 1Hz after the initialisation and arming is not possible.

I saw that the WMP has to be defined now in the config.h now . Is there anything else what is neccesarry to do to get the copter armed, or is it a bug ?


thank you
Georg

Hi all,

Finally i got work the last gui, no more blackboxes !

Thanks to the tip given by Alex and Kad, I reduced the hardware acceleration to one before zero, reboot the PC and it is.
I noticed that I must plug the FC board to USB and ARM the copter so that the AUX boxes and RCdatas appears finally.

cheers
Claude

Hello, nice work.. my copter flies very well with the 2.1er release.

But before I had to fix an compile error in Sensors.h at line 335:




--> 'toggleBeep' was not declared in this scope

I think this would fix the error:



Best regards,
vesparun

It will also works if you uncomment "define buzzer" when you uncomment "define inflight calibration"

Hamburger wrote:- without GPS (does it disturb the GUI-MWC communications, if MWC has a message not implemented?

There is a side effect in the GUI, but I've just corrected it.
so ok for me

Hi,
I confirm, there this should be the only thing to do to activate inflight calibration without buzzer enabled.

vesparun wrote:Hello, nice work.. my copter flies very well with the 2.1er release.

But before I had to fix an compile error in Sensors.h at line 335:

Code: Select all

            toggleBeep = 2;      //buzzer for indicatiing the end of calibration

--> 'toggleBeep' was not declared in this scope

I think this would fix the error:

Code: Select all

          #if defined(BUZZER)
            toggleBeep = 2;      //buzzer for indicatiing the end of calibration
          #endif

Best regards,
vesparun

Alexinparis wrote:Hi,
I confirm, there this should be the only thing to do to activate inflight calibration without buzzer enabled.

vesparun wrote:Hello, nice work.. my copter flies very well with the 2.1er release.

But before I had to fix an compile error in Sensors.h at line 335:

Code: Select all

            toggleBeep = 2;      //buzzer for indicatiing the end of calibration

--> 'toggleBeep' was not declared in this scope

I think this would fix the error:

Code: Select all

          #if defined(BUZZER)
            toggleBeep = 2;      //buzzer for indicatiing the end of calibration
          #endif

Best regards,
vesparun

This is due to the fact that Tommie put a define into buzzer.ino, so if you undefine buzzer, all the declarations are gone.

This is a good idea to save ram etc but the function is not programmed that way - as you see now. So someone should overthink this BEFORE building 2.1.

Nils

Hi,
I think there is not only one possible VTAIL config.
For instance 40deg inclination is one possible setup, but we can found other inclinations and other arm distances.
So the best we could do is to document more the current implementation, and give some hints to modify the code to cope with other VTAIL setups.

kipkool wrote:Hi

Mixer for Quad Vtail is not optimal here because it doesn't take in count the 40° motor angle and torque yaw force is in opposition to 40° motor thrust.

Motor rotation should be inversed in comparison to a normal quad:



at least Yaw mix should compensate with front motors to avoid inducted roll effect:

#ifdef VTAIL4
motor[0] = PIDMIX(+0,+1, +1); //REAR_R
motor[1] = PIDMIX(-1, -1, -0.64); //FRONT_R
motor[2] = PIDMIX(+0,+1, -1); //REAR_L
motor[3] = PIDMIX(+1, -1, +0.64); //FRONT_L
#endif

And for a perfect rotation in all axis and good CoG Nick, this should be:

#ifdef VTAIL4
motor[0] = PIDMIX(-1,+1, +1); //REAR_R
motor[1] = PIDMIX(-0.64, -0.64, -0.64); //FRONT_R
motor[2] = PIDMIX(+1,+1, -1); //REAR_L
motor[3] = PIDMIX(+0.64, -0.64, +0.64); //FRONT_L
#endif

No need to Yaw_direction = -1 and invert rear motor servos cables anymore.

I confirm also this bug was introduced by Tommie

jevermeister wrote:

Alexinparis wrote:Hi,
I confirm, there this should be the only thing to do to activate inflight calibration without buzzer enabled.

vesparun wrote:Hello, nice work.. my copter flies very well with the 2.1er release.

But before I had to fix an compile error in Sensors.h at line 335:

Code: Select all

            toggleBeep = 2;      //buzzer for indicatiing the end of calibration

--> 'toggleBeep' was not declared in this scope

I think this would fix the error:

Code: Select all

          #if defined(BUZZER)
            toggleBeep = 2;      //buzzer for indicatiing the end of calibration
          #endif

Best regards,
vesparun

This is due to the fact that Tommie put a define into buzzer.ino, so if you undefine buzzer, all the declarations are gone.

This is a good idea to save ram etc but the function is not programmed that way - as you see now. So someone should overthink this BEFORE building 2.1.

Nils

Hamburger wrote:I do not use the GUI too often, but on my macosx 10.5 it does not look good. The I-values are hardly readable. It's all default values, the last digit is almost completely outside the box and hidden.

screenshot.jpeg

This problem was solved thanks to kos:
viewtopic.php?f=8&t=1782

The version I compile in the releases include now this patch.
If you compile yourself the GUI without this patch, you will still have those "annoying triangles"

polo_fly2 wrote:Hello,

I installed the r949 on my tri yestreday for testing, but did not be able to arm anymore. Tha last ( and a very good running version) before was the dev_20120504.

This tri is very simple config with only the orig. WMP , no ACC and the i2c Oled connected to a Flyduino Mini-Pro 328, Adresses and parameters are not changed in any way.

The r949 is running. The GUI shows everything is fine , but the status LED is blinking at about 1Hz after the initialisation and arming is not possible.

I saw that the WMP has to be defined now in the config.h now . Is there anything else what is neccesarry to do to get the copter armed, or is it a bug ?


thank you
Georg

Hi,
Yes it is a bug. Thank you for pointing it.

@Alex:

If you change this:


to this:



in multiwii.ino

problems reguarding buzzer should be fixed.

I don't see any harm done by a single var.

Nils

Alexinparis wrote:The version I compile in the releases include now this patch.
If you compile yourself the GUI without this patch, you will still have those "annoying triangles"

ok, thanks. I missed that completely.
Since introduction of copter graphics (GL) I have to compile the GUI as fullscreen application, otherwise it will not run.

This is just another solution.
maybe less clean (some compilers will probably warn there is an unused variable in this case)

jevermeister wrote:@Alex:

If you change this:

Code: Select all

#if defined(BUZZER)
  static uint8_t  toggleBeep = 0;
#endif

to this:

Code: Select all

  static uint8_t  toggleBeep = 0;

in multiwii.ino

problems reguarding buzzer should be fixed.

I don't see any harm done by a single var.

Nils

Hey Alex,
when do you expect 2.1 to be released?

If I have one or two days left I could try to code a more elegant way to fix this situation.

Have you kept track of alle the changes since 2.0?

I think we should release a complete changelog WITH a guide to the changed behavior ( you have to uncomment wmp etc..)



Nils

Alexinparis said:

Hi,
I think there is not only one possible VTAIL config.
For instance 40deg inclination is one possible setup, but we can found other inclinations and other arm distances.
So the best we could do is to document more the current implementation, and give some hints to modify the code to cope with other VTAIL setups.

I'm agree with you, the Sin(MotorAngle)x100 as angle is a variable, this could be written in comments, but current implementation is wrong anyway.
Torque Yaw is in opposition to the yaw inducted by push force of the 40° motor angle.

That's why I reversed quad like motor rotation, like they did in OpenPilot for Vtail. Now Front Left is CCW and Front Right is CW

Hi,
@Alex: I just took the time to browse the code and found you already fixed the buzzer defines for toggle beep - no wrok for me

I just did the setup for my configuration and stumbled upon something that bugged me for a long time:

Why is

situated in mutliwii.ino?
Wouldn't it be better if we place it in config.h? I have to adjust these variables because my TX has a more narrow band. It is ahrd to find and easy to miss.


Nils

ps.: I will test _shared tomorrow: Looking forward

Hi,
I just did my first test and I am unable to arm my copter.
I can't arm it with Aux1/Aux2 but with TX_yaw if I disabeke the aux1 arming.

Anyone had similar problems?
I use latest revision.

Nils

Edit:
Okay this was my fault: I introduced a fix to prevent the system from arming while the failsafe counter != 0.
But the Failsafe counter is incrementeds a few lines before that so it is minimum==1.

I applied a fix.

And another one:

in buzzer.ino:

will not work, because f.GPS_HOME_MODE and f.GPS_HOLD_MODE are never set if f.GPS_FIX is 0.

I don't get these f.**** variables at all..

I will revert to this:



It is only to indicate if I want to use GPS and have no fix yet.

Nils

ps.: Tommie....