MultiWii 2.0 is coming

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

MultiWii 2.0 is coming

Post by Alexinparis »

Hi,

I think it’s time to think about the 2.0 release :)
Not everything is stabilized, but I think there are many stable improvements that worth a new release.
The purpose is now to remove every bug of the current dev version in order to make a 2.0 release.
I think it is already quite reliable for simple configs.
This post will be used to centralize last issues. (not new features)

As there are a lot of mods, here is a list of main mods.
Please help me to be exhaustive, as I probably forgot some mods.

Board and sensors:
New sensor:
ACC MMA7544 Accelerometer.

New boards:
CRIUS_SE
CRIUS_LIGHT
MONGOOSE

A new processor
Coded by ronco based on ATMega 32U4, which can be seen as an intermediate proc between 328 and 2560, allowing many improvements over the 328 with nearly the same size.
viewtopic.php?f=8&t=1145

STM32 port
A nice initiative from dongs to port multiwii to a 32bit processor.
This code allows also to reuse some cheap FC boards and replace the their firmware by a multiwii one. (boards like FreeFlight and Rabbit FC that can be found on goodluckbuy site, or specific boards designed by dongs)
viewtopic.php?f=8&t=1193
http://code.google.com/p/afrodevices/

Stable mode:
BMA180 and BMA020 settings are now set to 8G.
The settings were formerly 2G. We noticed vibrations could cause ACC saturation
viewtopic.php?f=8&t=849
, causing a wrong ACC measurement, and causing a wrong PITCH/ROLL angle deduction.
This problem was probably the main cause of the “level drift” problem.
=> level mode should be much better now with those sensors.
One consequence: TRUSTED ACC is now enabled by default and will probably be removed in future versions.

The term D of the PID LEVEL settings is now used to limit the effect of the level correction thanks to the suggestion of Shikra (see viewtopic.php?f=7&t=905 ).
By default (D=100), the behaviour of the stable mode is unchanged.
With a lower D, effects are:
- a smoothing level change
- should prevent some wobbles of death

Altitude hold mode:
There was a lot of hit and miss about this functionality.
viewtopic.php?f=8&t=562
viewtopic.php?f=7&t=363

Things are not perfect, but thanks to Marcin we can see a huge improvement and a working alt hold with default settings *on most setups*
There are still some oddities to solve.

Velocity PID is not currently used in the code.


GPS mode:
http://www.multiwii.com/forum/viewtopic.php?f=8&t=649

There are now 2 GPS devices supported:
Serial GPS
which should be connected on a free Serial port of the FC (MEGA boards needed)
Must be defined in config.h
#define GPS_SERIAL 2 < - a free serial port
#define GPS_BAUD 115200

GPS POSITION HOLD and GPS RETURN to HOME are both implemented with the Serial GPS option.

I2C Serial boards
EOSBandi did some code to add “a specific arduino + a Serial GPS” which communicates with multiwii via I2C.
http://code.google.com/p/i2c-gps-nav/
Must be defined in config.h
#define I2C_GPS

Position of the Home is defined once the GPS receives at least 4 satellites.
Then there are 2 GPS mode:
-ReturnToHome: when activated, the multi will go back to the GPS Home GPS coordinates.
-PositionHold: when activated, the multi will stay at its position.

The GPS mode needs:
-a very well calibrated MAG which is not disturbed by running motors. (no current of magnetic fields influence on the MAG, otherwise, the GPS won’t work fine)
-an ACC correctly tuned for level stabilization

The principle is very simple for the moment: multiwii tries to lean the multi in the direction of the target point, with an angle which is proportional to the distance.
A PID setting was added in the GUI:
P = angle inclination proportional to target distance
with P=5.0 in the GUI , 1 meter = 0.5deg inclination
I is currently not used
D = max angle inclination due to the GPS correction (15 is fine to begin)

Nice vids with first working GPS here:
EOSBandi:
http://www.youtube.com/watch?v=pJJKG6uWqv4
nhadrian:
http://www.youtube.com/watch?v=YcLJfC4h90M



More motors/more servos/better output accuracy:
Thanks to ronco, the output.pde part was nearly rewritten from scratch.
We have now new possible combinations that were impossible before.

Better efficiency for hardware pwm: digitalWrite arduino function was removed in order to address directly the output ports.
One consequence: motor order is no more easily configurable.

On MEGA boards: the first 6 motors are now driven by timers configured in a 16 bit mode.
The difference is noticeable in flight for a quad. It's a really nice improvement for MEGA boards running a quad for instance.

Extended motor range option (for use with wii-ESC; resolution 250 steps vs. 125 steps std.)
see viewtopic.php?f=13&t=516 for more info

On 328p based board (promini): we can now have the following configurations:
- HEX (FLAT X, FLAT +, or Y6)
- - with a standard receiver: in this case the 2 last motors are on PIN A0/A1 instead of D5&D6
- - or still with a PPM SUM receiver
- - with 2 servos for a GIMBAL mode + 1 servo for CAM TRIG:
- - - with a PPM sum receiver: in this case, the 2 last motors are on PIN D5&D6 and the servos are on PIN A0/A1/A2
- - - with a standard receiver: in this case, the 2 last motors are on PIN A0/A1 and the servos are on PIN A2/D12 (no CAM trig here)

- OCTO config (FLAT X, FLAT +, X8):
- - with or without a standard receiver: on PINs 3,9,10,11,A0,A1,A2,12
- - no servos

Config schemes are already documented here:
http://www.multiwii.com/connecting-elements



New config:
- Flying wing was introduced as beta, and is now successfully tested:
viewtopic.php?f=8&t=594

- VTAIL

LCD:
The current supported LCD are now:
- LCD_SERIAL_3W: Alex' initial variant with 3 wires serial LCD from Sparkfun, using rx-pin for transmission @9600 baud fixed
- LCD_TEXTSTAR: Cat's Whisker LCD_TEXTSTAR Module CW-LCD-02 (Which has 4 input keys for selecting menus)
- LCD_VT100: vt100 compatible terminal emulation (blueterm, putty, etc.)
alternate GUI to any (vt-100 aware) terminal program (optionally over BT), works for most tablets, smartphones, etc.
viewtopic.php?f=7&t=1096
- LCD_ETPP: Eagle Tree Power Panel LCD, which is a i2c device (not serial)
- LCD_LCD03: LCD03, which is a i2c device
viewtopic.php?f=8&t=1094

- servo midpoints (default 1500) user configurable via LCD (like subtrim on computer TX) for Flying Wing and TRI


LED:
An I2C LED Ring device with 12 RBG LEDs is integrated as an option in multiwii to give more feedback about sensor states.
viewtopic.php?f=8&t=902
http://www.dailymotion.com/video/xmdqa9 ... tiwii_tech

HeadFree mode:
Something similar to MK Carefree mode was added.
Firstly introduced by mahowik as a “simple mode”
viewtopic.php?f=7&t=925
A specific check box was added in the GUI to activate this mode via a switch.
You need to have a magnetometer and accelerometer on the board
Principle: The head/front will be remembered when you turn on the engines. So it means that you can turn on/off the mode during the flight.

Pass-through mode:
It’s a checkbox in the GUI.
The purpose is to bypass the IMU for some configs like flying wings.

Beeper mode:
It’s a checkbox in the GUI.
The purpose is to activate a beeper in case you have a buzzer installed and you lost your multi in high grass for instance.


New stick combo:
for magneto calibration (throttle=up yaw=right pitch=down)


Better magnetometer calibration:
The calibration of the magnetometer is now more precise, because it takes into account the relative strength of the magnitude projection on each axis.
Based on a code suggested by EOSBandi:
viewtopic.php?f=8&t=1068

It should improve the GPS return to target point accuracy.

gyro smoothing
There are 2 options to smooth the gyros: (mainly useful for fixed wings configs)
- per axis based on a LPF: #define GYRO_SMOOTHING {20, 20, 3} // separate averaging ranges for roll, pitch, yaw
- for all axis, based on a moving average (from Magnetron)
- #define MMGYRO
- #define MMGYROVECTORLENGHT 10

Servo gimbal smoothing is also an option based on the same principle:
- #define MMSERVOGIMBAL
- #define MMSERVOGIMBALVECTORLENGHT 32

Inflight ACC-calibration:
It’s a way to calibrate the level via on flight tests.
Must be defined in config.h
#define InflightAccCalibration

Suggested by jevermeister
viewtopic.php?f=7&t=893

Coding specific improvements:
- Less RAM memory usage via the use of PROGMEM statement

- No more Arduino Serial function => the new serial communication is more efficient and this version is compatible with either Arduino 023 IDE or the new Arduino 1.0 IDE (no more _vector error message)

- Board and sensors orientation:
This was something that was not well coded at the beginning.
viewtopic.php?f=8&t=1259

This mod should not affect board definition (a remapping of axis was done), but some errors could remain.
About individual sensor orientation: is not the same and it’s normal, there is no bug to correct here.


- task state in the main loop to reduce the jitter time loop

GUI:
- I2C errors status display in the GUI

- New AUX3/AUX4 checkboxes.
We can now have many more possibilities to activate/deactivate a specific function (4 switch with 3 states assuming you have a 8 channels RC system)
The previous CAM1/CAM2 rc channels (that are now AUX3/AUX4) are still usable for an assisted PITCH/ROLL gimbal system if the AUX3/AUX4 checkboxes are not used.

- visual feedback on state of all of the auxN options

- GUI reports the full MWC firmware version number

And of course, there is the nice version of WinGUI from EOSBandi already compatible with v2.0
It is definitively more friendly than the java one, allowing more features like load/write configs.
viewtopic.php?f=8&t=1229


OSD:
- rushduino is basically an arduino board, with OSD capabilities.
It's a very flexible solution, as it is open source, and it plugs on the multiwii serial port to retrieve sensors info.
viewtopic.php?f=8&t=922
Last edited by Alexinparis on Sat Mar 03, 2012 6:59 pm, edited 4 times in total.

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

Re: MultiWii 2.0 is coming

Post by copterrichie »

Just outright Awesome!

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 2.0 is coming

Post by timecop »

You forgot the STM32 port :) jk

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: MultiWii 2.0 is coming

Post by nhadrian »

Hi,

please don't forget the ultrasonic range finder implementation!
It looks like coding for SRF08 is done, calculations should be tested.

BR
Adrian

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

Could you consider my mod: moving average on gyro and acc freely configurable via config.h?

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: MultiWii 2.0 is coming

Post by ronco »

Alexinparis wrote:...
On MEGA boards: the first 4 motors are now driven by timers configured in a 16 bit mode.
The difference is noticeable in flight for a quad. It's a really nice improvement for MEGA boards running a quad for instance.
...


Hi Alex,

a small correction ;) the first 6 motors are with 16bit PWM on MEGA boards.

regards

felix

User avatar
UndCon
Posts: 293
Joined: Mon Feb 21, 2011 2:10 pm

Re: MultiWii 2.0 is coming

Post by UndCon »

I see an interesting summer coming closer and closer ;)

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

Re: MultiWii 2.0 is coming

Post by Bledi »

One more think : the state machine in the main loop to reduce the time loop. The GPS is not in this "case" list

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

Re: MultiWii 2.0 is coming

Post by Hamburger »

We achieved even more. Have a look at the wishlist thread first pozt. viewtopic.php?f=7&t=882&p=5366#p5366
Quote:

integrated in Alex' dev version

LED code
Simple mode like the Pirates or Carefree from Microcopter
turn passthrough mode into a checkboxes item
add checkboxes option to gui and multiwii to unconditionally turn on the buzzer via aux1/aux2 as a model-lost-and-found
preset the debug variables for GUI with more helpful info
have stick combo for magneto calibration
have servo midpoints (default 1500) user configurable via LCD (like subtrim on computer TX) for Flying Wing and TRI
flying wing code is stable, feature complete
Automatic inflight ACC calibration
GUI: visual feedback on state of all of the auxN options
alternate GUI to any (vt-100 aware) terminal program (optionally over BT), works for most tablets, smartphones, etc.
Extended motor range (for use with wii-ESC; resolution 250 steps vs. 125 steps std.)


implementation submitted to *_shared

cleanup internal misleading use of characters to address telemetry pages.
build multiwii with full cpp and compiler warnings and cleanup code (partially done only)
GUI so it reports the full MWC firmware version number, INCLUDING the patch level
Last edited by Hamburger on Thu Mar 01, 2012 3:45 pm, edited 1 time in total.

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: MultiWii 2.0 is coming

Post by ronco »

Hi,

found one bug (dev 20120225) .. tri yaw servo dont moves in GUI.
the output signal of it works well.


regards felix

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: MultiWii 2.0 is coming

Post by shikra »

Wow - it's incredible how many changes / improvements when you add them all up.
Your baby has grown Alex!!

And approaching 2.5 million thread views on RCG.....!!!

:D

jyrcorp
Posts: 1
Joined: Mon Aug 08, 2011 10:27 am

Re: MultiWii 2.0 is coming

Post by jyrcorp »

Hello,

I found a bug in dev 20120219 for my octo with arduino mini.
I'm using pins A0, A1, A2 and 12 to connect the 4 last motors.
I defined #define A0_A1_PIN_HEX and #define OCTOFLATX but motors 5 and 6 are not initialized.
I copied/paste some code in output.ino so that with 8 motors the motors 5 and 6 and now initialized:

Code: Select all

...
    #elif (NUMBER_MOTOR == 8) // PIN A2 & 12
      initializeSoftPWM();
// modif start    
      #if defined(A0_A1_PIN_HEX) || (NUMBER_MOTOR > 6)
        pinMode(5,INPUT);pinMode(6,INPUT);     // we reactivate the INPUT affectation for these two PINs
        pinMode(A0,OUTPUT);pinMode(A1,OUTPUT);
      #endif
// modif end    
    #endif
  #endif
...
 

User avatar
captaingeek
Posts: 228
Joined: Fri Jan 28, 2011 6:42 pm

Re: MultiWii 2.0 is coming

Post by captaingeek »

3 cheers to Alex and the developers or this project!!

just in time for a new quad im working on!

KeesvR
Posts: 194
Joined: Fri May 27, 2011 6:51 pm
Location: The Netherlands

Re: MultiWii 2.0 is coming

Post by KeesvR »

Thanks to all who made all these improvements possible, MultiWii is getting better and better.

@Alex: I think it's a good idea to give a extra warning about the changes of the sensor axis.

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

Re: MultiWii 2.0 is coming

Post by EOSBandi »

Hi !
Error found in output.pde. in line 617

Code: Select all

 servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

should be

Code: Select all

servo[5] = constrain(TRI_YAW_MIDDLE + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR


On the other hand, it's amazing how much it developed during the past 12 months....

User avatar
mgros
Posts: 90
Joined: Thu Jan 20, 2011 12:32 am

Re: MultiWii 2.0 is coming

Post by mgros »

IT'S NOT A BUG
A help for people with individual sensor BMA180 oriented as usual in 1.9.
It is necessary modify in config.h

Code: Select all

//if you want to change to orientation of individual sensor
#define ACC_ORIENTATION(X, Y, Z)  {accADC[ROLL]  =  -X; accADC[PITCH]  = -Y; accADC[YAW]  = Z;}
//#define ACC_ORIENTATION(X, Y, Z)  {accADC[ROLL]  =  Y; accADC[PITCH]  = -X; accADC[YAW]  = Z;} original
//#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;}
Last edited by mgros on Fri Mar 02, 2012 10:28 am, edited 1 time in total.

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

Re: MultiWii 2.0 is coming

Post by jevermeister »

Amazing work Alex!

I applaud to you and especcially to all who contributed!
You guys are amazing - it is an honor to work with you - the team at my company has much to learn from our teamwork here.

Nils

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

dongs wrote:You forgot the STM32 port :) jk

ok, I've modified the post ;)

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

nhadrian wrote:Hi,

please don't forget the ultrasonic range finder implementation!
It looks like coding for SRF08 is done, calculations should be tested.

BR
Adrian

Hi,
We have to freeze the dev at one step and make a pause to document, otherwise this will be a perpetual dev...
I'm sure this feature works well, and sonar will be included after

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

Magnetron wrote:Could you consider my mod: moving average on gyro and acc freely configurable via config.h?

Hi,
I'm not totally convinced by the interest of this mod:
- for gyro, I would really like to see a video which shows an improvement on a multi before->after. From my tuning experience, any delay after 2 or 3 cycles on gyro makes the situation worse.
I think it's however important for flying wing or servo heli configs, but we have something for this per axis in the shared rep based on LPF. So convince me and I will adopt it ;)
- for ACC, a smoothing a naturally done via LPF filter.
- for Baro, the algo uses already a moving average of 20 samples spaced each by 25ms

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

ronco wrote:
Alexinparis wrote:...
On MEGA boards: the first 4 motors are now driven by timers configured in a 16 bit mode.
The difference is noticeable in flight for a quad. It's a really nice improvement for MEGA boards running a quad for instance.
...


Hi Alex,

a small correction ;) the first 6 motors are with 16bit PWM on MEGA boards.

regards

felix


right, corrected

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

Bledi wrote:One more think : the state machine in the main loop to reduce the time loop. The GPS is not in this "case" list

right, it's something that was in the stack. I will modify it

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

Hamburger wrote:We achieved even more. Have a look at the wishlist thread first pozt. viewtopic.php?f=7&t=882&p=5366#p5366

I've completed the first post

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

ronco wrote:Hi,

found one bug (dev 20120225) .. tri yaw servo dont moves in GUI.
the output signal of it works well.


regards felix

right,
I found the bug in the GUI. it was a swap between servo 5&6.

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

jyrcorp wrote:Hello,

I found a bug in dev 20120219 for my octo with arduino mini.
I'm using pins A0, A1, A2 and 12 to connect the 4 last motors.
I defined #define A0_A1_PIN_HEX and #define OCTOFLATX but motors 5 and 6 are not initialized.
I copied/paste some code in output.ino so that with 8 motors the motors 5 and 6 and now initialized:

Code: Select all

...
    #elif (NUMBER_MOTOR == 8) // PIN A2 & 12
      initializeSoftPWM();
// modif start    
      #if defined(A0_A1_PIN_HEX) || (NUMBER_MOTOR > 6)
        pinMode(5,INPUT);pinMode(6,INPUT);     // we reactivate the INPUT affectation for these two PINs
        pinMode(A0,OUTPUT);pinMode(A1,OUTPUT);
      #endif
// modif end    
    #endif
  #endif
...
 

thanks, I will modify it

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

EOSBandi wrote:Hi !
Error found in output.pde. in line 617

Code: Select all

 servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

should be

Code: Select all

servo[5] = constrain(TRI_YAW_MIDDLE + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR


On the other hand, it's amazing how much it developed during the past 12 months....


Hi,
in fact, it's not a bug,
tri_yaw_middle is an eeprom variable that can be tuned via LCD => midpoint is customizable via software via LCD (but currently not from GUI)

Tifani
Posts: 63
Joined: Sun Nov 06, 2011 5:15 pm

Re: MultiWii 2.0 is coming

Post by Tifani »

Thanks Alex and all !!!
Just little sad than You abandoned Ultrasonic Range Finder - Maxbotix LV-EZ1
Regards
Tom

tovrin
Posts: 705
Joined: Tue Sep 20, 2011 4:08 pm

Re: MultiWii 2.0 is coming

Post by tovrin »

Wow Alex, you are amazing!

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

Re: MultiWii 2.0 is coming

Post by Hamburger »

Alexinparis wrote:I've completed the first post

wow, really impressive! Even though I was involved in the development and followed the progress since day 1 of the 1.9 release, seeing the compiled list of what we achieved took me by surprise. It seems we are doing not too bad at all.

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

Alexinparis wrote:
Magnetron wrote:Could you consider my mod: moving average on gyro and acc freely configurable via config.h?

Hi,
I'm not totally convinced by the interest of this mod:
- for gyro, I would really like to see a video which shows an improvement on a multi before->after. From my tuning experience, any delay after 2 or 3 cycles on gyro makes the situation worse.
I think it's however important for flying wing or servo heli configs, but we have something for this per axis in the shared rep based on LPF. So convince me and I will adopt it ;)
- for ACC, a smoothing a naturally done via LPF filter.
- for Baro, the algo uses already a moving average of 20 samples spaced each by 25ms

Alex, moving average implemented by me was on gyro and acc on a 8-lenght vector. I tryed personally on my quad and other users had tryed it on italian forum (baronerosso) and the feedback were positive. The average is costumizable via config.h file so if user want a little average he could have or can be fully disabled. I have no video but you can try directly. I think that this mod can be usefull for all type of flying object. For baro I ipotize about 6 months ago the low/high moving average algorithm but I have no implemented due to other problem (I speak this idea on italian forum). Alex, I want only help development for multiwii, consider my mod.

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

Re: MultiWii 2.0 is coming

Post by mbrak »

hi

a change for setting new home position during flight with AUX4 (High). without the secound term in the if-structure you would not get the FIX LED pattern automaticly.

Line 736 in DEV 20120225

Code: Select all

 if (rcData[AUX4]>1800 || GPS_fix_home == 0) {

Danal
Posts: 137
Joined: Tue Oct 18, 2011 5:15 pm

Re: MultiWii 2.0 is coming

Post by Danal »

May we "segment" the serial data stream to from the GUI? The goal is to allow a higher degree of release to release compatibility between MultiWii and GUI versions. This becomes particularly important as more tools become available to use the GUI interface.

I'd suggest something like:

Segment 1:
  • starts with M as it does now.
  • 1 byte count of segments.
  • 1 byte version number, and IMPORTANT NOTE, this is the version of this data segment, not the code!
  • Length of this segment (1 byte?)
  • Binary data almost exactly like now, but segment 1 contains only "core" stuff. PID gains, RC values, whatever we decide is core.
  • Checksum byte.

Segment 2 follows, with same basic structure, except "2" instead of "M", then version (of segment 2), length (of segment 2), binary data, end with checksum. Segment 2 has anything who's layout (schema) is likely to change over time. Changing segment 2's layout/schema (and version #) doesn't 'break' segment 1.

We can have a segment 3 if we need it at any point. Maybe as we add new features, they are sent in seg 3 at first, and promoted to seg 2 later.


Again, the goal is maximum compatibility between GUI (or GUI like) things and the MultiWii code. Even if segment 2 or 3 is not recognized, the parameters in Segment 1 can always be recognized, processed, and display/adjusted via the GUI, because segment 1 almost never changes. Same idea is somewhat true for segment 2, but a little less true... and segment 3 is probably going to require an exact match in MW and GUI code.

Thoughts?

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

Re: MultiWii 2.0 is coming

Post by Hamburger »

it was already under discussion to split the current M data into two:
- new M for the sensor data etc. (only what is neccessary to update the GUI)
- new X for the static data like PID settings etc. - would be transmitted only upon request (the READ button)
Motivation was to reduce transmission time for the M stream - currently each transmission exceeds the 650us limit. This may be bad because people use this to tune their PIDs which they do with an exceptionally prolonged cycle time.

Whatever we want to do - probably too late for 2.0

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

Re: MultiWii 2.0 is coming

Post by EOSBandi »

Hamburger wrote:it was already under discussion to split the current M data into two:
- new M for the sensor data etc. (only what is neccessary to update the GUI)
- new X for the static data like PID settings etc. - would be transmitted only upon request (the READ button)
Motivation was to reduce transmission time for the M stream - currently each transmission exceeds the 650us limit. This may be bad because people use this to tune their PIDs which they do with an exceptionally prolonged cycle time.

Whatever we want to do - probably too late for 2.0

Agree twice :
1.Serial protocol revamping is necessary. The current version is rather a quick hack and lacking reliability and robustness. MavLink is unfortunately out of the question due memory constraints...
2.Current dev is feature freezed, we must concentrate on finding and fixing bugs...

JohnyGab
Posts: 144
Joined: Sat Oct 29, 2011 4:41 am

Re: MultiWii 2.0 is coming

Post by JohnyGab »

Strongly true, there sould be a data segment version tracking, that way, things like rushduino osd would no longer need a multiwii code modification

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 2.0 is coming

Post by timecop »

EOSBandi wrote:MavLink is unfortunately out of the question due memory constraints...


Time to move to a real platform, then and leave 8bit noise behind.

Stalk
Posts: 49
Joined: Tue Apr 05, 2011 12:39 pm

Re: MultiWii 2.0 is coming

Post by Stalk »

Altitude hold in dev_20120225 only works well at temperatures above 20 degrees.
In a room works well, but outside no.
In my workshop I have 18 degrees.
Sometimes I get this in the GUI:
Attachments
Baro is not working
Baro is not working
Baro works
Baro works

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 2.0 is coming

Post by timecop »

What do you mean "not working"? It's working in both cases.

Stalk
Posts: 49
Joined: Tue Apr 05, 2011 12:39 pm

Re: MultiWii 2.0 is coming

Post by Stalk »

dongs wrote:What do you mean "not working"? It's working in both cases.

No, windows ALT and debug1 should be nearly the same.
Quad is in this case almost unmanageable.
Both are in the same place, so the ALT should be approximately the same.
I can not speak English well, so I can better explain.
Stanley

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

Tifani wrote:Thanks Alex and all !!!
Just little sad than You abandoned Ultrasonic Range Finder - Maxbotix LV-EZ1
Regards
Tom

Hi,
it's just delayed, not abandoned ;)

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

Magnetron wrote:
Alexinparis wrote:
Magnetron wrote:Could you consider my mod: moving average on gyro and acc freely configurable via config.h?

Hi,
I'm not totally convinced by the interest of this mod:
- for gyro, I would really like to see a video which shows an improvement on a multi before->after. From my tuning experience, any delay after 2 or 3 cycles on gyro makes the situation worse.
I think it's however important for flying wing or servo heli configs, but we have something for this per axis in the shared rep based on LPF. So convince me and I will adopt it ;)
- for ACC, a smoothing a naturally done via LPF filter.
- for Baro, the algo uses already a moving average of 20 samples spaced each by 25ms

Alex, moving average implemented by me was on gyro and acc on a 8-lenght vector. I tryed personally on my quad and other users had tryed it on italian forum (baronerosso) and the feedback were positive. The average is costumizable via config.h file so if user want a little average he could have or can be fully disabled. I have no video but you can try directly. I think that this mod can be usefull for all type of flying object. For baro I ipotize about 6 months ago the low/high moving average algorithm but I have no implemented due to other problem (I speak this idea on italian forum). Alex, I want only help development for multiwii, consider my mod.


ok,
So I keep the moving average for gyro (to let more people to test it easier via a simple #define)
And I keep also the moving average for gimbal as I see here something really useful.

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

mbrak wrote:hi

a change for setting new home position during flight with AUX4 (High). without the secound term in the if-structure you would not get the FIX LED pattern automaticly.

Line 736 in DEV 20120225

Code: Select all

 if (rcData[AUX4]>1800 || GPS_fix_home == 0) {

Hi,
I've corrected it. I'm sure EOSBandi will enhanced anyway this part dealing with I2C GPS

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

EOSBandi wrote:
Hamburger wrote:it was already under discussion to split the current M data into two:
- new M for the sensor data etc. (only what is neccessary to update the GUI)
- new X for the static data like PID settings etc. - would be transmitted only upon request (the READ button)
Motivation was to reduce transmission time for the M stream - currently each transmission exceeds the 650us limit. This may be bad because people use this to tune their PIDs which they do with an exceptionally prolonged cycle time.

Whatever we want to do - probably too late for 2.0

Agree twice :
1.Serial protocol revamping is necessary. The current version is rather a quick hack and lacking reliability and robustness. MavLink is unfortunately out of the question due memory constraints...
2.Current dev is feature freezed, we must concentrate on finding and fixing bugs...


Hi,
The current serial protocol is a sort of quick hack, but it very efficient in term of simplicity ;)
It's not error proof and would require at least a checksum for config settings.

About Mavlink, I'm not no sure about the huge memory and code size requirement.
I know ziss_dm is working on a mavlink implementation, and it seems quite efficient.
I think it's probably the way to go, instead of tweaking the current protocol.

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

Stalk wrote:Altitude hold in dev_20120225 only works well at temperatures above 20 degrees.
In a room works well, but outside no.
In my workshop I have 18 degrees.
Sometimes I get this in the GUI:

Thank you for pointing this.
I suspected something wrong about the MS baro code, as I also had a baro alt issue outside.
There was a bug in the code which should be corrected now in the pre version 2.0

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

I've corrected several things today and a new release is available here:
http://code.google.com/p/multiwii/downloads/list

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: MultiWii 2.0 is coming

Post by nhadrian »

Please note that in preversion 2.0 in multiwii.ino the complete I2C_GPS code is missing from the end.
BTW, excellent job!!! Many thanks for your job in behalf of us!

Are you planning to put in the implementation of SRF08 range finder together with the modified alt code?

BR
Adrian

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

Re: MultiWii 2.0 is coming

Post by mbrak »

Alexinparis wrote:
mbrak wrote:hi

a change for setting new home position during flight with AUX4 (High). without the secound term in the if-structure you would not get the FIX LED pattern automaticly.

Line 736 in DEV 20120225

Code: Select all

 if (rcData[AUX4]>1800 || GPS_fix_home == 0) {

Hi,
I've corrected it. I'm sure EOSBandi will enhanced anyway this part dealing with I2C GPS



hi alex

you corrected it only in the i2c part of the code in r631. for my part i have a serial (flyduino) gps.
will both (i2c and serial) gps supported and have the same functionality?

best regards
michael

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

Alexinparis wrote:
Magnetron wrote:
Alexinparis wrote:Hi,
I'm not totally convinced by the interest of this mod:
- for gyro, I would really like to see a video which shows an improvement on a multi before->after. From my tuning experience, any delay after 2 or 3 cycles on gyro makes the situation worse.
I think it's however important for flying wing or servo heli configs, but we have something for this per axis in the shared rep based on LPF. So convince me and I will adopt it ;)
- for ACC, a smoothing a naturally done via LPF filter.
- for Baro, the algo uses already a moving average of 20 samples spaced each by 25ms

Alex, moving average implemented by me was on gyro and acc on a 8-lenght vector. I tryed personally on my quad and other users had tryed it on italian forum (baronerosso) and the feedback were positive. The average is costumizable via config.h file so if user want a little average he could have or can be fully disabled. I have no video but you can try directly. I think that this mod can be usefull for all type of flying object. For baro I ipotize about 6 months ago the low/high moving average algorithm but I have no implemented due to other problem (I speak this idea on italian forum). Alex, I want only help development for multiwii, consider my mod.


ok,
So I keep the moving average for gyro (to let more people to test it easier via a simple #define)
And I keep also the moving average for gimbal as I see here something really useful.


Ok Alex,
the moving average is implemented for gyros and for accs.
The user could decide to activate or not.
Multiwii v2.0 will be a very interesting software with more options, you could impement moving average setup also via gui... so the users have not to manupulate the code become a very simple software.

In the bottom of config.h
add this

Code: Select all

//#######################################################
// FUNCTIONS BY MAGNETRON1 (Michele Ardito)
// Moving Average Gyros by Magnetron1
#define MMGYRO                         // Active Moving Average Function for Gyros
#define MMGYROVECTORLENGHT 8           // Lenght of Moving Average Vector
// Moving Average Accelerometers by Magnetron1
#define MMACC                          // Active Moving Average Function for Accelerometers
#define MMACCVECTORLENGHT 8            // Lenght of Moving Average Vector
// Trusted AccZ with PIDVEL Enable
#define TRUSTED_ACCZ_PID               // Active function Trusted AccZ with PIDVEL


in Sesors.pde modify GYRO_Common and ACC_Common routines like this:

Code: Select all

// ****************
// GYRO common part
// ****************
void GYRO_Common() {
  static int16_t previousGyroADC[3] = {0,0,0};
  static int32_t g[3];
  uint8_t axis;
#if defined MMGYRO       
  // Moving Average Gyros by Magnetron1
  //---------------------------------------------------
  static int16_t mediaMobileGyroADC[3][MMGYROVECTORLENGHT];
  static int32_t mediaMobileGyroADCSum[3];
  static uint8_t mediaMobileGyroIDX;
  //---------------------------------------------------
#endif
  if (calibratingG>0) {
    for (axis = 0; axis < 3; axis++) {
      // Reset g[axis] at start of calibration
      if (calibratingG == 400) g[axis]=0;
      // Sum up 400 readings
      g[axis] +=gyroADC[axis];
      // Clear global variables for next reading
      gyroADC[axis]=0;
      gyroZero[axis]=0;
      if (calibratingG == 1) {
        gyroZero[axis]=g[axis]/400;
        blinkLED(10,15,1+3*nunchuk);
      }
    }
    calibratingG--;
  }
#ifdef MMGYRO       
  //Moving Average Gyros by Magnetron1
  mediaMobileGyroIDX = ++mediaMobileGyroIDX % MMGYROVECTORLENGHT;
  for (axis = 0; axis < 3; axis++) {
    gyroADC[axis]  -= gyroZero[axis];
   //new implementation of Moving Average for fast response
   mediaMobileGyroADCSum[axis] -= mediaMobileGyroADC[axis][mediaMobileGyroIDX];
    //anti gyro glitch, limit the variation between two consecutive readings
    mediaMobileGyroADC[axis][mediaMobileGyroIDX] = constrain(gyroADC[axis],previousGyroADC[axis]-800,previousGyroADC[axis]+800);
   mediaMobileGyroADCSum[axis] += mediaMobileGyroADC[axis][mediaMobileGyroIDX];
   gyroADC[axis] = mediaMobileGyroADCSum[axis] / MMGYROVECTORLENGHT;
#else
  for (axis = 0; axis < 3; axis++) {
    gyroADC[axis]  -= gyroZero[axis];
    //anti gyro glitch, limit the variation between two consecutive readings
    gyroADC[axis] = constrain(gyroADC[axis],previousGyroADC[axis]-800,previousGyroADC[axis]+800);
#endif   
    previousGyroADC[axis] = gyroADC[axis];
  }
}

// ****************
// ACC common part
// ****************
void ACC_Common() {
  static int32_t a[3];
  uint8_t axis;
#if defined MMACC       
  // Moving Average Accelerometers by Magnetron1
  //---------------------------------------------------
  static int16_t mediaMobileAccADC[3][MMACCVECTORLENGHT];
  static int32_t mediaMobileAccADCSum[3];
  static uint8_t mediaMobileAccIDX;
  //---------------------------------------------------
#endif
  if (calibratingA>0) {
    for (axis = 0; axis < 3; axis++) {
      // Reset a[axis] at start of calibration
      if (calibratingA == 400) a[axis]=0;
      // Sum up 400 readings
      a[axis] +=accADC[axis];
      // Clear global variables for next reading
      accADC[axis]=0;
      accZero[axis]=0;
    }
    // Calculate average, shift Z down by acc_1G and store values in EEPROM at end of calibration
    if (calibratingA == 1) {
      accZero[ROLL]  = a[ROLL]/400;
      accZero[PITCH] = a[PITCH]/400;
      accZero[YAW]   = a[YAW]/400-acc_1G; // for nunchuk 200=1G
      accTrim[ROLL]   = 0;
      accTrim[PITCH]  = 0;
      writeParams(); // write accZero in EEPROM
    }
    calibratingA--;
  }
  #if defined(InflightAccCalibration)
      static int32_t b[3];
      static int16_t accZero_saved[3]  = {0,0,0};
      static int16_t  accTrim_saved[2] = {0, 0};
      //Saving old zeropoints before measurement
      if (InflightcalibratingA==50) {
         accZero_saved[ROLL]  = accZero[ROLL] ;
         accZero_saved[PITCH] = accZero[PITCH];
         accZero_saved[YAW]   = accZero[YAW] ;
         accTrim_saved[ROLL] = accTrim[ROLL] ;
         accTrim_saved[PITCH] = accTrim[PITCH] ;
      }
      if (InflightcalibratingA>0) {
        for (axis = 0; axis < 3; axis++) {
          // Reset a[axis] at start of calibration
          if (InflightcalibratingA == 50) b[axis]=0;
          // Sum up 50 readings
          b[axis] +=accADC[axis];
          // Clear global variables for next reading
          accADC[axis]=0;
          accZero[axis]=0;
        }
        //all values are measured
        if (InflightcalibratingA == 1) {
          AccInflightCalibrationActive = 0;
          AccInflightCalibrationMeasurementDone = 1;
          blinkLED(10,10,2);      //buzzer for indicatiing the start inflight
        // recover saved values to maintain current flight behavior until new values are transferred
         accZero[ROLL]  = accZero_saved[ROLL] ;
         accZero[PITCH] = accZero_saved[PITCH];
         accZero[YAW]   = accZero_saved[YAW] ;
         accTrim[ROLL] = accTrim_saved[ROLL] ;
         accTrim[PITCH] = accTrim_saved[PITCH] ;
        }
        InflightcalibratingA--;
      }
      // Calculate average, shift Z down by acc_1G and store values in EEPROM at end of calibration
      if (AccInflightCalibrationSavetoEEProm == 1){  //the copter is landed, disarmed and the combo has been done again
        AccInflightCalibrationSavetoEEProm = 0;
        accZero[ROLL]  = b[ROLL]/50;
        accZero[PITCH] = b[PITCH]/50;
        accZero[YAW]   = b[YAW]/50-acc_1G; // for nunchuk 200=1G
        accTrim[ROLL]   = 0;
        accTrim[PITCH]  = 0;
        writeParams(); // write accZero in EEPROM
      }
  #endif
#ifdef MMACC
  //Moving Average Accelerometers by Magnetron1
  mediaMobileAccIDX = ++mediaMobileAccIDX % MMACCVECTORLENGHT;
  for (axis = 0; axis < 3; axis++) {
    accADC[axis]  -= accZero[axis];
   //new implementation of Moving Average for fast response
   mediaMobileAccADCSum[axis] -= mediaMobileAccADC[axis][mediaMobileAccIDX];
    mediaMobileAccADC[axis][mediaMobileAccIDX] = accADC[axis];
   mediaMobileAccADCSum[axis] += mediaMobileAccADC[axis][mediaMobileAccIDX];
   accADC[axis] = mediaMobileAccADCSum[axis] / MMACCVECTORLENGHT;
  }
#else
  accADC[ROLL]  -=  accZero[ROLL] ;
  accADC[PITCH] -=  accZero[PITCH];
  accADC[YAW]   -=  accZero[YAW] ;
#endif   
}

That's all.


Alex,
in the IMU.PDE I would to try something like this:

Code: Select all

  #if defined(TRUSTED_ACCZ_PID)
     temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / 400 + accADC[YAW]*D8[PIDVEL] / 30;
  #else
     temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / 400;
  #endif

activable via TRUSTED_ACCZ_PID in the config.h
what do you think about this?

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

Re: MultiWii 2.0 is coming

Post by EOSBandi »

nhadrian wrote:Please note that in preversion 2.0 in multiwii.ino the complete I2C_GPS code is missing from the end.
BTW, excellent job!!! Many thanks for your job in behalf of us!

Are you planning to put in the implementation of SRF08 range finder together with the modified alt code?

BR
Adrian

Because it's moved to the gps.ino where it needs to be :)

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: MultiWii 2.0 is coming

Post by nhadrian »

oh... many thanks!!!
I completely missed...... :oops:

Post Reply