Let's try to release 2.1: first try based on r949

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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
Last edited by Alexinparis on Tue Jul 03, 2012 11:37 pm, edited 3 times in total.

mahowik
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Let's try to release 2.1: first try based on r949

Post by mahowik »

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:

Code: Select all

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

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:

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

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

User avatar
Hamburger
Posts: 2559
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by Hamburger »

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.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Let's try to release 2.1: first try based on r949

Post by Tommie »

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).

User avatar
Hamburger
Posts: 2559
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by Hamburger »

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.

PatrikE
Posts: 1963
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by PatrikE »

SerialGps.
Distance home show -32000 in gui.

flyman777
Posts: 55
Joined: Mon Sep 19, 2011 1:44 pm

Re: Let's try to release 2.1: first try based on r949

Post by flyman777 »

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

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by EOSBandi »

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

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

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: Let's try to release 2.1: first try based on r949

Post by Katch »

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

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by EOSBandi »

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)

gjerbic
Posts: 5
Joined: Mon Oct 17, 2011 3:17 pm

Re: Let's try to release 2.1: first try based on r949

Post by gjerbic »

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

//#define MMA745

should be:
//#define MMA7455

same error in multiwii 2.0

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: Let's try to release 2.1: first try based on r949

Post by bill516 »

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.

PatrikE
Posts: 1963
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by PatrikE »

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.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Let's try to release 2.1: first try based on r949

Post by Tommie »

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.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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.
Last edited by Alexinparis on Sun Jul 01, 2012 7:46 pm, edited 1 time in total.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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 ;)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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 ?

User avatar
Hamburger
Posts: 2559
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by Hamburger »

@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?

kad
Posts: 18
Joined: Sat Jun 09, 2012 1:33 am

Re: Let's try to release 2.1: first try based on r949

Post by kad »

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
Last edited by kad on Mon Jul 02, 2012 3:06 pm, edited 1 time in total.

User avatar
Hamburger
Posts: 2559
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by Hamburger »

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

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: Let's try to release 2.1: first try based on r949

Post by bill516 »

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

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by jevermeister »

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

TomW
Posts: 4
Joined: Sat Apr 14, 2012 5:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by TomW »

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.

User avatar
Hamburger
Posts: 2559
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by Hamburger »

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
macosx 10.5 display problem
(42.81 KiB) Not downloaded yet

kipkool
Posts: 30
Joined: Mon Jun 25, 2012 9:21 am

Re: Let's try to release 2.1: first try based on r949

Post by kipkool »

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:

Image

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.

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Let's try to release 2.1: first try based on r949

Post by crashlander »

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).
Attachments
Foto_mali.png

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: Let's try to release 2.1: first try based on r949

Post by mbrak »

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.

User avatar
Hamburger
Posts: 2559
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by Hamburger »

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.

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: Let's try to release 2.1: first try based on r949

Post by mbrak »

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.

TomW
Posts: 4
Joined: Sat Apr 14, 2012 5:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by TomW »

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.

User avatar
polo_fly2
Posts: 34
Joined: Fri Aug 05, 2011 1:12 pm
Location: Munich - Bavaria

Re: Let's try to release 2.1: first try based on r949

Post by polo_fly2 »

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

flyman777
Posts: 55
Joined: Mon Sep 19, 2011 1:44 pm

Re: Let's try to release 2.1: first try based on r949

Post by flyman777 »

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

vesparun
Posts: 2
Joined: Tue Jul 03, 2012 8:57 pm

Re: Let's try to release 2.1: first try based on r949

Post by vesparun »

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

User avatar
fr3d
Posts: 97
Joined: Sun Feb 06, 2011 11:21 am
Location: Cappelle la grande near the ch'ti village
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by fr3d »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by jevermeister »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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:

Image

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.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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"

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by jevermeister »

@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

User avatar
Hamburger
Posts: 2559
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by Hamburger »

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.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: first try based on r949

Post by Alexinparis »

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

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by jevermeister »

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

kipkool
Posts: 30
Joined: Mon Jun 25, 2012 9:21 am

Re: Let's try to release 2.1: first try based on r949

Post by kipkool »

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

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by jevermeister »

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

Code: Select all

// ******************
// rc functions
// ******************
#define MINCHECK 1160
#define MAXCHECK 1850

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

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by jevermeister »

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.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Let's try to release 2.1: first try based on r949

Post by jevermeister »

And another one:

in buzzer.ino:

Code: Select all

  //===================== GPS fix notification handling =====================
  #if GPS
  if ((f.GPS_HOME_MODE || f.GPS_HOLD_MODE) && !f.GPS_FIX){    //if no fix and gps funtion is activated: do warning beeps.
    warn_noGPSfix = 1;   
  }else{
    warn_noGPSfix = 0;
  }
  #endif

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:

Code: Select all

  //===================== GPS fix notification handling =====================
  #if GPS
  if ((rcOptions[BOXGPSHOME] || rcOptions[BOXGPSHOLD]) && !f.GPS_FIX){    //if no fix and gps funtion is activated: do warning beeps.
    warn_noGPSfix = 1;   
  }else{
    warn_noGPSfix = 0;
  }
  #endif


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

Nils

ps.: Tommie....

Post Reply