try to release 2.1: based on r976

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

try to release 2.1: based on r976

Post by Alexinparis »

http://code.google.com/p/multiwii/downloads/list

I hope it will be the last one before 2.1 (probably this week end)

with a text revision project:

Code: Select all

Some things everyone should be aware before upgrading to this version.

  WMP and NUNCHUCK are no longer auto recognized.
  You must explicitly declare them (or just WMP) in config.h

  Pullups are now undefined by default
    (think about activating it if you use a WMP only conf)
  LCD is not activated by default

  Failsafe is not activated by default

  There is no more .pde files
  You must use Arduino 1.0 or greater to compile the sketch (and open Multiwii.ino)

  If the GUI does not work on your setup,
    try to deactivate hardware acceleration for your display board
    or use an alternative GUI like WinGUI

  MultiWii is not a product, nor a plug and play solution.
  Don't expect to buy a compatible board and run it without a minimum knowledge.


Receiver part
  OpenLRS Multi board support done
    This is a board including an OpenLRS receiver where the atmel
    is used also to run multiwii code.
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1438


Multiwii Serial Protocol
  It's a new protocol to communicate with the FC
  It was introduced by me and tuned by Tommie
  It's a huge change, but it should ensure a generic way to communicate with the FC,
  which is less dependant to version evolutions.
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1516
 
  Now, there is no mod to the multiwii if we want to add a GUI/OSD/conf tool/...

  Compatible GUI:
    open source code, compatible with the new serial protocol
    WinGUI from EOSBandi, which is fully equivalent with the original one,
     with a better look
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1229
    mwGui from kos
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1791
    Android ones via serial bluetooth:
     - adding a bluetooth module to multiwii
       more info here: http://www.multiwii.com/forum/viewtopic.php?f=6&t=133
     compatible apps:
      https://play.google.com/store/apps/details?id=net.xrotor.andmultiwiiconf
      https://play.google.com/store/apps/details?id=net.loide.games.bicopter
      https://play.google.com/store/apps/details?id=com.naze32.configurator

  Compatible OSD:
    open source code, compatible with the new serial protocol
    Rushduino:
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=922
    mobiDrone:
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1498

LCD config
  OLED display
    thanks to contributions of howardhb and Hamburger
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=7&t=1350

  VT100 terminal type addition
    thanks to contribution of Hamburger
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=7&t=1096

  A multiline option is added to allow the configuration on more than 2 lines
    useful for displays like OLED or VT100

  We have now a lot of possibilities regarding LCD:
    SERIAL3W : original 2x16 line from Sparkfun
    TEXTSTAR : Cat's Whisker LCD_TEXTSTAR Module CW-LCD-02
    VT100 : vt100 compatible terminal
    ETPP : Eagle Tree Power Panel LCD
    LCD03 : an i2c LCD
    OLED_I2C_128x64

New proc: ATmega32U4
  Thanks to the work from ronco.
  This proc can be found in the Arduino pro micro board, or Teensy 2.0
  The Pro Micro is similar to the Pro Mini except with an ATmega32U4 on board.
  The USB transceiver inside the 32U4 allows us to add USB connectivity on-board.
  ronco also designed a custom board named nanowii.
  One of the smallest 6DOF Multiwii board with usb, which can be now purchased.
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1337

Servo:
  Higher refresh rate:
    Some servo (mostly digital ones) can work with a higher frequency than 50Hz.
    The consequence is a sharper response.
    ronco adapted the code to make this frequency configurable
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1644
  Hardware PWM output:
    On MEGA boards, it's now possible to drive the gimbal servos with
    a 11-bit PWM servo resolution. Thanks to ronco.
    The hardware PWM output ensures a jitter free response.

LED flasher
  A way to set a flash LED sequence from Tommie
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1505

Throttle expo
  There is now another curve in the GUI to configure the Throttle expo.
  It's a way to smooth the throttle stick response around the hover point.
  In order to help the setting, there is a small cursor in the graph to show
  where is the current throttle input.

ACC LEVEL improvement
  The LEVE mode is improved since 2.0 thanks to new choice of
  new complementary filter coefficients and a floating point low pass filter

Headfree checkbox:
  It's possible to reset the headfree direction while flying via a checkbox.
  thanks to Tommie

Sensor:
  MPU6050: there was a bug which prevents using the gyro LPF. correted now.
  SONAR: I2C sonar SRF0x code was added but is not currently used.
  many new boards was also added in config.h file


Internal code:
  - the Serial part uses now less RAM (thanks to Tommie first mod)
    RX/TX buffers are smaller than before.
  - EEPROM parameters are stored in a struct, and are written in the
    EEPROM in a single step.
  - MAG declination was added by EOSBandi, to have more accurate orientation.
    In some countries, it's really mandatory to set this variable right,
     otherwise it's impossible to use GPS.
  - Flag var was introduced for global boolean type variables.
  - Hamburger introduced some "copter exemple" in order to check
    if compilation is ok. (should be a way to remove some trivial bugs)
  - code style (indentation, variable naming convention etc.) started
  - GUI requires new ControlP5 library to compile
  - new config.h structure

GUI:
  - thanks to Danal, there is now the PIN number and the propeller direction
  drawed in the graph representation
  - thanks to kos, we can now load and save parameters into a file
  - there is now a reset button to set all parameters to default
  - there is now a GUI visual feedback on all states (checkbox items)

GPS code:
  Thanks to the work of EOSBandi, we have now a working GPS code !
  The navigational routines are based on the works of Jason Short
  and the Arducopter team (another great open source project).
  EOSBandi adapted it to multiwii.
  basically, there are 2 main options for GPS: SERIAL option and I2C option.

    - If you have a spare serial port AND an AtMega1280 or 2560 microcontroller
    based FC, you can connect your GPS to that port and enable the serial GPS
    code in the code.
    Patrick introduced a way to switch automaticly because GUI message parsing
    or NMEA message parsing on the same Serial port
    (useful for promini because you can use the same port for GUI and GPS
    in an exclusive mode)
   
    - You can use an I2C_GPS board, which contains a secondary AtMega328 processor
    with a serial GPS and runs the GPS parsing and navigational computations.
    This board communicates with the FC via the I2C bus.

  more info here: http://code.google.com/p/i2c-gps-nav/downloads/list
  and here in this huge post: http://www.multiwii.com/forum/viewtopic.php?f=8&t=649

  There is also a specific GPS_FROM_OSD option:
    it's a way to use the GPS device of OSD to feed Multiwii with GPS data
    MIS OSD uses this functionality

ESC calibration
  experimental
  It's a special #define which allows to calibrate all ESCs with exaclty
   the same signal.
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=13&t=1517

Telemetry
  new telemetry manual stepping mode

Arming option
  configurable TX stick combos for arm/disarm
  this way, it's possible to arm/disarm the multi via:
    - one AUX switch like before
    - YAW stick and/or ROLL stick

AIRPLANE mode
  experimental, more info here:
  http://www.multiwii.com/forum/viewtopic.php?f=8&t=364
  https://code.google.com/p/multiwii/wiki/MWiiAirplane

HELICOPTER mode
  experimental
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1562

Dual & Single copter
  experimental
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1882

An attempt to improve the documentation via wiki
  wiki from googlecode:
  https://code.google.com/p/multiwii/w/list
  wiki from multiwii.com
  http://www.multiwii.com/wiki/index.php?title=Main_Page
  We all know the overall documentation is still to improve.

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: try to release 2.1: based on r976

Post by alexia »

salut alex
pourrait tu ajouter dans la liste des configues la nouvelle cirius
http://fpvcentral.net/2012/07/crius-all ... ii-part-1/

ça serait vraiment génial
un grand merci a toi

Deet
Posts: 129
Joined: Sun Jul 08, 2012 1:54 am

Re: try to release 2.1: based on r976

Post by Deet »

The GUI is no longer full screen on Mac OS X and works well, config saved and reloaded

Quick test fly on QuadX with Paris/Sirius, no issues

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

Re: try to release 2.1: based on r976

Post by jevermeister »

Hi,
I had a reset issue with the newest buzzer.ino.

I will revert the changes.

Sorry for the extra work :-(

Shame on me!

Nils

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: try to release 2.1: based on r976

Post by Sebbi »

config.h says:

Code: Select all

    /* Set the Low Pass Filter factor for ACC
       Increasing this value would reduce ACC noise (visible in GUI), but would increase ACC lag time
       Comment this if  you do not want filter at all.*/
    //#define ACC_LPF_FACTOR 100


IMU.ino says:

Code: Select all

//******  advanced users settings *******************
/* Set the Low Pass Filter factor for ACC */
/* Increasing this value would reduce ACC noise (visible in GUI), but would increase ACC lag time*/
/* Comment this if  you do not want filter at all.*/
#ifndef ACC_LPF_FACTOR
  #define ACC_LPF_FACTOR 100
#endif


Accelerometer data will be filtered when ACC_LPF_FACTOR is commented out, instead of what the comment text says.

Also:

Code: Select all

  // Attitude of the estimated vector
  angle[ROLL]  =  _atan2(EstG.V.X , EstG.V.Z) ;
  angle[PITCH] =  _atan2(EstG.V.Y , EstG.V.Z) ;


Should be (see viewtopic.php?f=8&t=2037):

Code: Select all

  // Attitude of the estimated vector
  angle[ROLL]  =  _atan2(EstG.V.X , sqrt(EstG.V.Y*EstG.V.Y + EstG.V.Z*EstG.V.Z)) ;
  angle[PITCH] =  _atan2(EstG.V.Y , sqrt(EstG.V.X*EstG.V.X + EstG.V.Z*EstG.V.Z)) ;

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: try to release 2.1: based on r976

Post by LenzGr »

Wow, the list of changes looks quite impressive. Kudos! I'll try to test the latest code drop in the coming days, but the weather is currently quite miserable for flying outside. Where's the summer this year?

charbot
Posts: 34
Joined: Wed May 23, 2012 8:37 pm

Re: try to release 2.1: based on r976

Post by charbot »

Dude, ALL the summer has been here in the US! (pant)

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: try to release 2.1: based on r976

Post by Bledi »

Big warning for VTAIL :
in the old version (2.0) the mix of VTAIL is for the most comun version : 2 differents moteurs or the same moteurs but smaller props rear.
in the old version (2.0) they were a bug on the order of rear motors so we had to put YAW @ -1

In the 2.1 RC2 the mix is ONLY for a VTAIL with same motors and same props so if actual users select VTAIL in the next release we will have a lot of problems.

I think there is 2 solutions :
- Let the VTAIL mix as before but with a correction on rear motors order :

Code: Select all

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


- Add 2 configurations on VTAIL :

Code: Select all

#define VTAIL4 //MIX for 4 same motors and same props
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

#define VTAIL2x2 //MIX for 2 differents motors or differents props REAR and FRONT
motor[0] = PIDMIX(+0,+1, +1); //REAR_R
motor[1] = PIDMIX(-1, -1, +0); //FRONT_R
motor[2] = PIDMIX(+0,+1, -1); //REAR_L
motor[3] = PIDMIX(+1, -1, -0); //FRONT_L


Thanks

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: try to release 2.1: based on r976

Post by copterrichie »

I use Y4 for my VTail copters, it works great. ;)

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: try to release 2.1: based on r976

Post by Bledi »

copterrichie wrote:I use Y4 for my VTail copters, it works great. ;)

yes but you have set YAW @ -1 or did you invert your Rear motors ? The solution 1 is just to correct this little error and to have the same order for motors as a QuadX
The solution 1 is a Y4 with inverted YAW

Mac9
Posts: 45
Joined: Thu Oct 20, 2011 2:47 pm
Contact:

Re: try to release 2.1: based on r976

Post by Mac9 »

Hi All,
I am posting on a thread that is not particularly the correct one, however I have a problem and would like some advice or even approbation. I am flying a Quad X using a Quadrino board. It fly's OK on Dev 2012200622 in all modes other than "Headfree" I can use any combination of Mag/Level/Alt and it flies OK. With Headfree added to any or all of the modes it is un flyable. It seems, though I haven't tried to get the frame very far off the ground, that pitch and roll are partially reversed. I have calibrated the Mag and Acel using the GUI and when I do not select Headfree the frame flies OK. Any ideas would be much appreciated.

Regards

John

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: try to release 2.1: based on r976

Post by copterrichie »

Bledi wrote:
copterrichie wrote:I use Y4 for my VTail copters, it works great. ;)

yes but you have set YAW @ -1 or did you invert your Rear motors ? The solution 1 is just to correct this little error and to have the same order for motors as a QuadX
The solution 1 is a Y4 with inverted YAW


It works and always have worked. :)

P.S. if there was a little unity and not so much trying to outdo one another, some of these problems would be non-existing. Y4 works period.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: try to release 2.1: based on r976

Post by copterrichie »

Look, I am going to help you out there, MIXING can only do a very SMALL part of the job because most ESCs only have a 200 Step Resolution. So you don't want to mess with the mixing too much other than to make fine tuning adjustments. You have to adjust the motor's KV and Prop size to achieve the right Center of thrust to match the CG. As for the YAW direction, you have your thrust pointed outwards, so the EASIEST way to fix this is to switch the servo leads on the rear two motors.

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

Re: try to release 2.1: based on r976

Post by kipkool »

Hi Alex

Here is a patch to configure different type of VTail config easily. I'm not developper so there's probably better ways to write this.
This allows averybody to set it up depending on their config & taste.


Here is the patch:

http://xmltv.free.fr/multiwii/vtail4patch.diff

and a prepatched version here:

http://xmltv.free.fr/multiwii/MultiWii_release_candidate_2_1_r976-vtailpatched.zip

What has been modified:

config.h

Code: Select all

  /****************************    VTAIL QUAD configuration ****************************/
  /* set rear motors angle */
  #define VTAIL4ANGLE 40
  /* this  will compensate yaw/nick/roll in motor mixer to have perfect YAW/NICK/ROLL rotation on one axis at a time.
  /* If you have different motor/props configuration DO NOT activate any of the compensation below
  /* It's not possible to calculate the perfect motor mixer in this case because of too many motor/props combination*/
  #define VTAIL4YAWCOMP
  #define VTAIL4NICKCOMP
  #define VTAIL4ROLLCOMP



Output.pde:

Code: Select all

  /*************** VTAIL4 Mix table *********************************/
  //calculate correct front motors thrust depending of rear motor angle

  #ifdef VTAIL4
    double vtail4Thrust;
    vtail4Thrust = sin(VTAIL4ANGLE);
   #if !defined(VTAIL4YAWCOMP) && !defined(VTAIL4NICKCOMP) && !defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(+0,+1, +1); //REAR_R
      motor[1] = PIDMIX(-1, -1, +0); //FRONT_R
      motor[2] = PIDMIX(+0,+1, -1); //REAR_L
      motor[3] = PIDMIX(+1, -1, -0); //FRONT_L
    #endif
   #if defined(VTAIL4YAWCOMP) && !defined(VTAIL4NICKCOMP) && !defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(+0,+1, +1); //REAR_R
      motor[1] = PIDMIX(-1, -1, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+0,+1, -1); //REAR_L
      motor[3] = PIDMIX(+1, -1, +vtail4Thrust); //FRONT_L
   #endif
   #if defined(VTAIL4YAWCOMP) && !defined(VTAIL4NICKCOMP) && defined(VTAIL4ROLLCOMP)
       motor[0] = PIDMIX(+0,+1, +1); //REAR_R
      motor[1] = PIDMIX(-1, -vtail4Thrust, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+0,+1, -1); //REAR_L
      motor[3] = PIDMIX(+1, -vtail4Thrust, +vtail4Thrust); //FRONT_L
   #endif
   #if defined(VTAIL4YAWCOMP) && defined(VTAIL4NICKCOMP) && !defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(-1,+1, +1); //REAR_R
      motor[1] = PIDMIX(-vtail4Thrust, -1, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+1,+1, -1); //REAR_L
      motor[3] = PIDMIX(+vtail4Thrust, -1, +vtail4Thrust); //FRONT_L
   #endif
   #if !defined(VTAIL4YAWCOMP) && defined(VTAIL4NICKCOMP) && defined(VTAIL4ROLLCOMP)     
      motor[0] = PIDMIX(-1,+1, +1); //REAR_R
      motor[1] = PIDMIX(-vtail4Thrust, -vtail4Thrust, -0); //FRONT_R
      motor[2] = PIDMIX(+1,+1, -1); //REAR_L
      motor[3] = PIDMIX(+vtail4Thrust, -vtail4Thrust, +0); //FRONT_L
   #endif
   #if defined(VTAIL4YAWCOMP) && defined(VTAIL4NICKCOMP) && defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(-1,+1, +1); //REAR_R
      motor[1] = PIDMIX(-vtail4Thrust, -vtail4Thrust, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+1,+1, -1); //REAR_L
      motor[3] = PIDMIX(+vtail4Thrust, -vtail4Thrust, +vtail4Thrust); //FRONT_L
   #endif
  #endif
Last edited by kipkool on Fri Jul 13, 2012 2:30 pm, edited 1 time in total.

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

Re: try to release 2.1: based on r976

Post by Alexinparis »

Sebbi wrote:config.h says:

Code: Select all

    /* Set the Low Pass Filter factor for ACC
       Increasing this value would reduce ACC noise (visible in GUI), but would increase ACC lag time
       Comment this if  you do not want filter at all.*/
    //#define ACC_LPF_FACTOR 100


IMU.ino says:

Code: Select all

//******  advanced users settings *******************
/* Set the Low Pass Filter factor for ACC */
/* Increasing this value would reduce ACC noise (visible in GUI), but would increase ACC lag time*/
/* Comment this if  you do not want filter at all.*/
#ifndef ACC_LPF_FACTOR
  #define ACC_LPF_FACTOR 100
#endif


Accelerometer data will be filtered when ACC_LPF_FACTOR is commented out, instead of what the comment text says.

Right, the description should be updated.
something like this.
=> "Comment this out if you want to set a specific filter"

Code: Select all

  // Attitude of the estimated vector
  angle[ROLL]  =  _atan2(EstG.V.X , EstG.V.Z) ;
  angle[PITCH] =  _atan2(EstG.V.Y , EstG.V.Z) ;


Should be (see viewtopic.php?f=8&t=2037):

Code: Select all

  // Attitude of the estimated vector
  angle[ROLL]  =  _atan2(EstG.V.X , sqrt(EstG.V.Y*EstG.V.Y + EstG.V.Z*EstG.V.Z)) ;
  angle[PITCH] =  _atan2(EstG.V.Y , sqrt(EstG.V.X*EstG.V.X + EstG.V.Z*EstG.V.Z)) ;

You're probably right.
some schemes in this site might help:
http://www.starlino.com/imu_guide.html

However, this adds something like 100 microseconds more per loop, and it seems it's not crucial for level mode.
I will keep it it was in 2.1, and I'm sure we could optimize a little the loop time with the right formula later.

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

Re: try to release 2.1: based on r976

Post by Alexinparis »

Hi,
Thanks for this, but some checks must obviously be done to be sure of this mod.
So too late for 2.1, but ok for after.

kipkool wrote:Hi Alex

Here is a patch to configure different type of VTail config easily. I'm not developper so there's probably better ways to write this.
This allows averybody to set it up depending on their config & taste.


Here is the patch:

http://xmltv.free.fr/multiwii/vtail4patch.diff

and a prepatched version here:

http://xmltv.free.fr/multiwii/MultiWii_release_candidate_2_1_r976-vtailpatched.zip

What has been modified:

config.h

Code: Select all

  /****************************    VTAIL QUAD configuration ****************************/
  /* set rear motors angle */
  #define VTAIL4ANGLE 40
  /* this  will compensate yaw/nick/roll in motor mixer to have perfect YAW/NICK/ROLL rotation on one axis at a time.
  /* If you have different motor/props configuration DO NOT activate any of the compensation below
  /* It's not possible to calculate the perfect motor mixer in this case because of too many motor/props combination*/
  #define VTAIL4YAWCOMP
  #define VTAIL4NICKCOMP
  #define VTAIL4ROLLCOMP



Output.pde:

Code: Select all

  /*************** VTAIL4 Mix table *********************************/
  //calculate correct front motors thrust depending of rear motor angle

  #ifdef VTAIL4
    int vtail4Thrust;
    vtail4Thrust = (int)(sin(VTAIL4ANGLE));
   #if !defined(VTAIL4YAWCOMP) && !defined(VTAIL4NICKCOMP) && !defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(+0,+1, +1); //REAR_R
      motor[1] = PIDMIX(-1, -1, +0); //FRONT_R
      motor[2] = PIDMIX(+0,+1, -1); //REAR_L
      motor[3] = PIDMIX(+1, -1, -0); //FRONT_L
    #endif
   #if defined(VTAIL4YAWCOMP) && !defined(VTAIL4NICKCOMP) && !defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(+0,+1, +1); //REAR_R
      motor[1] = PIDMIX(-1, -1, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+0,+1, -1); //REAR_L
      motor[3] = PIDMIX(+1, -1, +vtail4Thrust); //FRONT_L
   #endif
   #if defined(VTAIL4YAWCOMP) && !defined(VTAIL4NICKCOMP) && defined(VTAIL4ROLLCOMP)
       motor[0] = PIDMIX(+0,+1, +1); //REAR_R
      motor[1] = PIDMIX(-1, -vtail4Thrust, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+0,+1, -1); //REAR_L
      motor[3] = PIDMIX(+1, -vtail4Thrust, +vtail4Thrust); //FRONT_L
   #endif
   #if defined(VTAIL4YAWCOMP) && defined(VTAIL4NICKCOMP) && !defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(-1,+1, +1); //REAR_R
      motor[1] = PIDMIX(-vtail4Thrust, -1, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+1,+1, -1); //REAR_L
      motor[3] = PIDMIX(+vtail4Thrust, -1, +vtail4Thrust); //FRONT_L
   #endif
   #if !defined(VTAIL4YAWCOMP) && defined(VTAIL4NICKCOMP) && defined(VTAIL4ROLLCOMP)     
      motor[0] = PIDMIX(-1,+1, +1); //REAR_R
      motor[1] = PIDMIX(-vtail4Thrust, -vtail4Thrust, -0); //FRONT_R
      motor[2] = PIDMIX(+1,+1, -1); //REAR_L
      motor[3] = PIDMIX(+vtail4Thrust, -vtail4Thrust, +0); //FRONT_L
   #endif
   #if defined(VTAIL4YAWCOMP) && defined(VTAIL4NICKCOMP) && defined(VTAIL4ROLLCOMP)
      motor[0] = PIDMIX(-1,+1, +1); //REAR_R
      motor[1] = PIDMIX(-vtail4Thrust, -vtail4Thrust, -vtail4Thrust); //FRONT_R
      motor[2] = PIDMIX(+1,+1, -1); //REAR_L
      motor[3] = PIDMIX(+vtail4Thrust, -vtail4Thrust, +vtail4Thrust); //FRONT_L
   #endif
  #endif

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: try to release 2.1: based on r976

Post by Bledi »

Alexinparis wrote:Hi,
Thanks for this, but some checks must obviously be done to be sure of this mod.
So too late for 2.1, but ok for after.


If you don't integrate this mod, plz go back to the last mix or just replace it by Y4 with YAW correction because the actual mix on RC2 is not working on most actual VTAIL configurations

Code: Select all

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

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

Re: try to release 2.1: based on r976

Post by Alexinparis »

Bledi wrote:
Alexinparis wrote:Hi,
Thanks for this, but some checks must obviously be done to be sure of this mod.
So too late for 2.1, but ok for after.


If you don't integrate this mod, plz go back to the last mix or just replace it by Y4 with YAW correction because the actual mix on RC2 is not working on most actual VTAIL configurations

Code: Select all

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

ok, that's fine

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

Re: try to release 2.1: based on r976

Post by kipkool »

Yeah ,please just use this for Vtail for the 2.1 before integrating the patch.

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

cheers

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: try to release 2.1: based on r976

Post by Sebbi »

Alexinparis wrote:
Sebbi wrote:

Code: Select all

  // Attitude of the estimated vector
  angle[ROLL]  =  _atan2(EstG.V.X , sqrt(EstG.V.Y*EstG.V.Y + EstG.V.Z*EstG.V.Z)) ;
  angle[PITCH] =  _atan2(EstG.V.Y , sqrt(EstG.V.X*EstG.V.X + EstG.V.Z*EstG.V.Z)) ;

You're probably right.
some schemes in this site might help:
http://www.starlino.com/imu_guide.html

However, this adds something like 100 microseconds more per loop, and it seems it's not crucial for level mode.
I will keep it it was in 2.1, and I'm sure we could optimize a little the loop time with the right formula later.


It's probably not crucial, but it theoretically affects flying when both axis are tilted. It is a similar problem as with the rotateV() function using small angle approximation. It produces slightly off results when not flying level which get compensated fast enough by the accelerometer. Probably not a crucial problem, but still ...

Maybe version 2.2 could have some flags switching between different IMU implementations. The current, fast one and some super correct ones with different filters/algorithms (using more bytes and more cpu time) ;-)

sisco21
Posts: 4
Joined: Fri Jul 13, 2012 12:24 pm

Re: try to release 2.1: based on r976

Post by sisco21 »

Hi,

I'm new on this forum. Great Job!.

I upload 2.9 based on r976 and now i'm unable to show the motors status.
All motors are at MinCommand!

Any idea?

it was working with the Multiwii 2 version

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

Re: try to release 2.1: based on r976

Post by kipkool »

Hi

i've just modified the patch & archive posted below for Vtail. There was a stupid mistake in it.

Just tested all different vtail configurations in flight & everything is ok here.



Something elese, here is a new imu ( Crius AIO Pro , atmega 2560 based ) that can be added to 2.1:


Code: Select all

#if defined(CRIUS_AIO_PRO_V1)
 #define MPU6050
 #define HMC5883
 #define MS561101BA
 #define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = -X; accADC[PITCH] = -Y; accADC[YAW] = Z;}
 #define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = Y; gyroADC[PITCH] = -X; gyroADC[YAW] = -Z;}
 #define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = -Z;}
 #define MPU6050_EN_I2C_BYPASS // MAG connected to the AUX I2C bus of MPU6050
 #undef INTERNAL_I2C_PULLUPS
#endif



regards.
Last edited by kipkool on Sat Jul 14, 2012 12:37 am, edited 1 time in total.

sismeiro
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

Re: try to release 2.1: based on r976

Post by sismeiro »

Hi,

When I am using the vt100 interface to configure the aux switches, I have two lines for the same mode. I think only one line should be shown in the aux configuration. I posted a video on YouTube to show it: http://youtu.be/FnenW3fi7iw

Also with the configuration #define LCD_TELEMETRY_STEP "012345" nothing happens when I move the Ail/Roll stick to move the pages after I start the auto telemetry mode. Can someone also verify this?

Regards,
Luis Sismeiro

Chaosdestro0
Posts: 13
Joined: Wed Mar 21, 2012 9:37 pm

Re: try to release 2.1: based on r976

Post by Chaosdestro0 »

I have a suggestion, please include a useful description of the level mode trimming in the air function.
Here is a good link to some decent documentation
http://ncopters.blogspot.de/2012/04/howto-inflight-acc-calibration-in.html

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

Re: try to release 2.1: based on r976

Post by Hamburger »

sismeiro wrote:Hi,

When I am using the vt100 interface to configure the aux switches, I have two lines for the same mode. I think only one line should be shown in the aux configuration. I posted a video on YouTube to show it: http://youtu.be/FnenW3fi7iw

Also with the configuration #define LCD_TELEMETRY_STEP "012345" nothing happens when I move the Ail/Roll stick to move the pages after I start the auto telemetry mode. Can someone also verify this?

Regards,
Luis Sismeiro

Ffirst line is aux1
Second line is aux2

Tele.step has. Nothing to do with tele.auto.
Other stick combo too.

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: try to release 2.1: based on r976

Post by alexia »

hi hamburger
is it possible to add a #define file for the new multiwii cirus board?
all is on this pdf
http://www.rcgroups.com/forums/thumbgal ... eadgallery

it will be easier for beginners if it will be integrate on the source code

thanks for you work

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: try to release 2.1: based on r976

Post by copterrichie »

Alex, please this bug in the Bicopter Mixing has been here for a long time and with each update, I have just made the required changes. Can we include this fix in version 2.1?

Thank you.


Present

Code: Select all

#ifdef BI
       
    servo[4]  = constrain(1500 + YAW_DIRECTION * (axisPID[YAW] + axisPID[PITCH]), 1020, 2000); //LEFT
    servo[5]  = constrain(1500 + YAW_DIRECTION * (axisPID[YAW] - axisPID[PITCH]), 1020, 2000); //RIGHT
  #endif


Should be

Code: Select all

 #ifdef BI
       
    servo[4]  = constrain(1500 + (YAW_DIRECTION * axisPID[YAW]) + axisPID[PITCH], 1020, 2000); //LEFT
    servo[5]  = constrain(1500 + (YAW_DIRECTION * axisPID[YAW]) - axisPID[PITCH], 1020, 2000); //RIGHT
  #endif
Last edited by copterrichie on Sat Jul 14, 2012 4:35 pm, edited 1 time in total.

sismeiro
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

Re: try to release 2.1: based on r976

Post by sismeiro »

Hi,

Hamburger wrote:Ffirst line is aux1
Second line is aux2

Ok, so you didn't found any strange behaviour in the video but I don't understand how it should work for aux configuration.

Hamburger wrote:Tele.step has. Nothing to do with tele.auto.
Other stick combo too.

Ok, I didn't understand that from the config.h. What is the new stick combo since I didn't saw it in the stick configuration pdf? Thx.
Also for some reason the telemetry stop stick combination doesn't work for me after trying several times and after changing the trims to help.

Regards,
Luis Sismeiro

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

Re: try to release 2.1: based on r976

Post by Hamburger »

Tele.step is nick.fwd+roll.right.
For tele.auto the stop Combo is same as start.

mac.rcnet.com
Posts: 6
Joined: Tue Jun 19, 2012 5:34 pm

Re: try to release 2.1: based on r976

Post by mac.rcnet.com »

Hi all,

I have an issue with the RC's version, this one and the first version too.
The issue is that the quad x vibrate like a bad P setting but the setting is the same as before and the default one.
I have try to tune the pid but, i could have more vibration but not less, it seems to not come from PID.

I have done a clean install with the 2 RCs versions (clear eeprom), when i return to stock dev2206, the issue disappear and i have no problem, i've try to search the cause alone but i don't find it.

This is my quad config : 10DOF IMU from drotek (this one http://www.drotek.fr/shop/en/72-multiwii-mpu6050-gyro-accelerometer-ms5611-hmc5883.html) with 30A Rctimer's ESC not flashed and 930Kv RCtimer's motors.

Thanks in advance for all your help,

Mac

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

Re: try to release 2.1: based on r976

Post by Alexinparis »

copterrichie wrote:Alex, please this bug in the Bicopter Mixing has been here for a long time and with each update, I have just made the required changes. Can we include this fix in version 2.1?

Thank you.


Present

Code: Select all

#ifdef BI
       
    servo[4]  = constrain(1500 + YAW_DIRECTION * (axisPID[YAW] + axisPID[PITCH]), 1020, 2000); //LEFT
    servo[5]  = constrain(1500 + YAW_DIRECTION * (axisPID[YAW] - axisPID[PITCH]), 1020, 2000); //RIGHT
  #endif


Should be

Code: Select all

 #ifdef BI
       
    servo[4]  = constrain(1500 + (YAW_DIRECTION * axisPID[YAW]) + axisPID[PITCH], 1020, 2000); //LEFT
    servo[5]  = constrain(1500 + (YAW_DIRECTION * axisPID[YAW]) - axisPID[PITCH], 1020, 2000); //RIGHT
  #endif


ok, noted

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: try to release 2.1: based on r976

Post by gompf-2 »

Hi,
tested Promini+ITG3200+ADXL345 in a Vtail config 2xA20-28M, 2xa20-50S, atm all 8x4,5. As the first start with R976 PID mixers was awful with my setup (nonsense atm, planned to go to 9x4,5 on the front to compensate gimbal weight) I used the R964 mixer, P-yaw lowered to 4, others default. Due to heavy wind here just hovering+some drag starts to adjust COG to COT but felt OK.
Esc-calib worked fine. I just noticed that there is some mix up with v_bat/buzzer code. It may make sense to have only one option set but atm v_bat code needs #define buzzer anyway. Not critical.
Only problem was jumps of about 10 to 15 deg on yaw from time to time but I´m quite this was due to wind/not tuned PID-setup.

Thanks to all developers!

Lorphos
Posts: 8
Joined: Wed Jul 11, 2012 8:40 pm
Location: Dortmund, Germany

Re: try to release 2.1: based on r976

Post by Lorphos »

One minor thing that i noticed with 2.1 r976 is that MultiWiiConf shows "v0" in the top left corner below "multiwii.com".
Would be nice if it shows the exact version (for debugging, screenshots, etc).

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

Re: try to release 2.1: based on r976

Post by kipkool »

As the first start with R976 PID mixers was awful with my setup (nonsense atm..


Have you reverted motor rotation and put back YAW_DIRECTION=1 ( no -1 ) ?
This should be mentionned in config file I think:

Code: Select all

#define VTAIL4  //WARNING: motor rotation has changed: Front Left & Rear Right: CCW, Front Right & Rear Left: CW , YAW_DIRECTION=1 )

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: try to release 2.1: based on r976

Post by gompf-2 »

Aehhhemmm, ... no :oops: I just switched the PWM-outputs for rear L/R and reversed the yawdir to make it "feel quiet right when held in the hand", then went to full throttle and started ... the false direction of rotation could explain the wobble of death on roll I´ve seen :D

Post Reply