Alexinparis MultiWii multirotor platform additional info.

It seems that Alex his MultiWiiCopter is booming!
Rumors go that the MultiWii Multicopters are the most widely known & spread multi copters in the world.
I don't know if it's true but fore sure Alex his project evolved tremendously in the past year!

Main links & info:

The main website of the owner of the MultiWii project is www.multiwii.com.
The (huge) main RC groups thread where all discussions are held can be found here.
Kinderkram & Blue Angel have made excellent build logs! They are available here and here.
Another very good post for initial set-up and basic questions from Shikra can be found here.

The source code can be found on the Google code repository here.

I strongly encourage to read Alex his website & Kinderkram's or Blue Angel's build logs, they contain normally all information needed to build the MultiWii.



The blog is divided into 4 parts

1: MultiWii connection diagrams
The first post mainly covers all connection drawings and is updated till version 1.9. However not necessary it's advised to use the latest version of the software.

2: MultiWii additional FAQ's
In the second post I collected some useful questions & answers gathered from the main thread.

3: MultiWii early adapter boards
In the third post several first shields and adapter boards from the MultiWii are shown together.

Please note that this part is not up to date any more. In the mean time the available hardware has grown very fast.
It's not possible to maintain all the available adapter boards made by so many different users.
The post itself will stay available as a reference & may refer to the early pioneers of the MultiWii platform.
Some of the current boards are still based on these early shields.

4: MultiWii Release descriptions
In the fourth post, the latest release descriptions can be found, note they are also available in the readme file on the code repository.





1: MultiWii connection diagrams

The connection diagrams are updated & valid for the latest MultiWii version 1.9. Please find the connection diagrams for the previous version 1.7 & 1.8 in .pdf format at the bottom of this page.

The purpose of this page is to keep the latest & different versions of the connection drawings together. Note that it's possible to ad more components but most MultiWii's are flying perfectly with these layouts.
The drawings are available in .jpg & MultiWii pdf diagrams.


It's better not to connect the BESC output voltages in parallel as they can "fight" against each other & damage the ESC's. Furthermore it's best to connect only one ground wire to the FC in order to avoid ground loops. In below drawings, only one BESC output must be connected in the quad config, the other connection is for the servo supply of the tricopter.

All current diagrams are compatible with the latest version 1.9 of the MultiWii.

1. Basic MultiWii Tri or Quadcopter
The most basic diagram of the MultiWii is shown below, it uses only 4 channels from the receiver & the Wii Motion plus gyro.
This is ideal for starters & gives a very nice flying quad or tricopter.




2. Full MultiWii Tri or Quadcopter with NK ACC
This version of the MultiWii uses the Nunchuck accelerometers to enable a stable mode.
Optional, there is also a battery voltage monitor with alarm, an external status led and a LCD interface for PID tuning.
Note that the RX1 pin from the Arduino is used to transmit the serial data to the LCD. The LCD can be connected using a simple servo lead this way.




3. Full MultiWii Y6 & Hexa with NK ACC
This is the Y6 & Hexa version of the MultiWii, it can also use the Nunchuck accelerometers to enable a stable mode but this is not required.
Optional, there is also a battery voltage monitor with alarm, an external status led and a LCD interface for PID tuning.
Note that the RX1 pin from the Arduino is used to transmit the serial data to the LCD. The LCD can be connected using a simple servo lead this way.



3B. Full MultiWii Y6 & Hexa with NK ACC
This is the Y6 & Hexa version of the MultiWii, since version 1.9 it's possible to drive an Y6 or hexa with a regular receiver on an Arduino Pro Mini.
Use the option #define A0_A1_PIN_HEX in the software for this setup.




4. MultiWii Gimbal connection
The MultiWii gimbal connection only uses the receiver roll & pitch input & 2 servo outputs for a PITCH and ROLL camera/gimbal stabilization.
No ESC's are controlled.
The servo outputs are driven for each axis by a superposition of the calculated angle + the position of the RC input channel.




5. Full MultiWii with ADXL345 & BMP085 - Option 1
This version has the same options as in diagram 2 but uses a different ACC & optional pressure sensor.
It's however not possible to power all the different I2C sensors with 5V, the ADXL & BMP require a 3.3V supply.
In order to combine different sensors on the same I2C bus a logic level converter has been used in this diagram.



6. Full MultiWii with ADXL345 & BMP085 - Option 2
Identical to diagram 5 but a different approach.




6B. MultiWii with standard WM+, NK & BMP085
As requested, an update to the standard set-up.
This connection diagram shows the standard WM+ & NK set-up extended with a BMP085 pressure sensor through a LLC.



7. MultiWii Flying wing with WM+ & NK
This version of the MultiWii controls a flying wing, the throttle channel is not connected to the MultiWii but directly to the ESC.
The Roll & pitch from the aircraft are controlled by the MultiWii.




8. MultiWii Seeeduino Mega connection diagram with BMA020
This version of the MultiWii uses the Seeeduino Mega controller & the BMA-020 as ACC together with the WM+



9. MultiWii Seeeduino Mega connection diagram with FFIMU
This version of the MultiWii uses the Seeeduino Mega controller & the FFIMU from JussiH (420RCPilot) together with a LLC.




10. MultiWii Arduino Pro Mini connection diagram with FFIMU
This version of the MultiWii uses the Arduino Pro Mini with one of the currently available IMU boards. Please note that other IMU boards can be used.

Note that the internal pullups should be deactivated for a direct connection to some IMU's without a LLC.
There is a #define INTERNAL_I2C_PULLUPS to activate the pullups but this shout not be done if you connect some IMU's without LLC to the Arduino. Please refer to manufacturer of your IMU board.



Note that it's possible to have different connection methods between the Arduino & I2C sensors.
Diagram 5 & 6 are mainly based on Point65, Opie11 & Pinball's comments & suggestions.
Although the drawings mention an ADXL345 & BMP085, the connection is basically the same for other 3.3V I2C sensors.


11. MultiWii individual sensor connection diagram
Since the MultiWii supports more & more sensors, below diagram shows the individual sensors & how they should be
connected to use with the standard MultiWii software.




12. MultiWii Flyduino connection diagram
A connection diagram for Paul Bake's his Flyduino, the MultiWii v1.9 is fully compatible with the Flyduino. See this link for more information.

• You can connect a positive feed from your power setup (the lipo) to the IN pin, that gives a regulated power supply to the board.
  This is what Paul Bake (the Flyduino designer) recommends. You don't need to worry about a negative or minus because that comes through your ESC's.
  
• If you want to use your BESC from the ESC on motor 2 instead of the built in regulator, then the "ESC 5V" bridge must be made. This will use the 5V from your ESC to power the board. Note that the other 5V pins from your ESC's are not interconnected on the board. You do not need to remove them from the servo plug.
  
• The gimbal power pin supplies power to the 3 gimbal servos.

MultiWii diagrams version 1.9 in .pdf format
You can download all diagrams in .pdf format. MultiWii diagrams.pdf.

MultiWii diagrams version 1.8 in .pdf format
There were several changes since release 1.8.
All diagrams can be downloaded for the MultiWii version 1.8 in pdf format. MultiWii diagrams.pdf.

MultiWii diagrams version 1.7 in .pdf format
There were several pins changed on the Mega version since release 1.7.
All diagrams can be downloaded for the MultiWii version 1.7 in pdf format. MultiWii diagrams.pdf.

Enjoy.
Best regards.
B.

Please PM any faults or remarks so I can update the pages!

2: MultiWii additional FAQ's

By following the main thread on a regular basis, I saw a lot of useful information contributed by several people. Unfortunately they are lost & the same Questions are sometimes asked all over again.
Below are some Questions & answers which are extracted from the main thread. Where available, the answers are linked to the original post.

The latest version 1.6 of the source code can be found in the Google project hosting here. Look in the change.txt document to check for the changes between the versions.

Used abbreviations:

ACC: Accelerator (this could be either the Nunchuck or the Sparkfun ADXL345)
NK: Nunchuk
WMP or WM+ or MP: Wii Motion Plus
CG: Centre of gravity
I2C: Inter IC, It's actually the communication bus which is used by all the MultiWiiCopter sensors. (More detailed info here or here.)
SCL: I2C communication bus wire.SCL is the clock line. It is used to synchronize all data transfers over the I2C bus.
SDA: I2C communication bus wire. SDA is the data line
LLC: Logic Level Converter (example)

1: Servo's on the MultiWii.

a. Question:What are the possibilities to control servo's on a MultiWii based on an Arduino Pro Mini
Answer: (link)
To summarize what will be possible to do with servos.
- tricopter + only one more servo (pitch OR roll)
- quadcopter + 2 servos (pitch AND roll)
- Y6 & Hexa: no servo

Note that on a Seeeduino Mega or Flyduino board more servos can be used in different configurations.

2: LED behaviour on the MultiWii.

a. Question:What is the LED behaviour on version 1.4
Answer: (link)
- at initialization, during gyro calibration: blink
- at the end of the initialization: LED stays off
- when arming motors: LED stays ON

From version 1.6:
- If the calibration is not done or if the MultiWii is too much inclinated, the status LED will slowly blink every 1s. It's not possible to arm the motors in this case.

- It's possible to ad a led to PIN 13 to indicate a status change. See this post from dynai & this post for his schematic.

3: Starting, running & stopping the MultiWii.

a. Question:The motors do not start
Answer: (link)
Move the rudder full right with throttle all the way down to start the motors, full left to turn off the motors.

b. Question:The motors still do not start or start but do not stop any more
You have to adjust the travel of your channels so it has a range from 1000 to 2000 on the GUI. Most likely you need to extend your channel endpoints on your transmitter so the minimum & maximum request is changing from 1000 to 2000.
On most radios, the endpoints or travel adjusts must be increased to approximately 120% till140%. to get a 1000 to 2000 range in the GUI.

c. Question:The motors still do not start, what about the minimum throttle signal send to the ESC's
Answer: (link)
In some cases the ESC's do not start with the supplied standard minimum throttle value.
It's possible to lower this value in order to start the ESC's. One can try to lower the MINCOMMAND value with steps of 50 to 950 or 900.


d. Question: The motors start & stop but after trimming the yaw it's no longer possible to start or stop the motors.
Answer:
By setting the trim, the complete range moves up or down so the endpoint does not reach the desired 1000 or 2000 any more. One transmitter suffering from this is e.g. the very basic Planet T5 2.4Ghz transmitter.

e. Question: It seems that the motor output on the GUI is not equal on both sides after the copter is moved & placed back?
Answer: (link) & (link)
This is the normal PID loop behaviour, the I-term is actually cumulating the error over time & tries to compensate for that but the copter is hand-held or fixed on the table. When the I-term is zeroed, the this will not happen. A flying multicopter will actually use the I-term in the PID to correct itself again to the same level as before the disturbance.

f. Question: How should we calibrate the Autolevel/Stable mode in version 1.7.
Answer: (Link)
1. Fly with acro mode on and see the drift direction.
2. Adjust the roll/pitch trims on the TX to compensate in the correct direction
3. If the trim is not ok repeat step 2
4. Calibrate ACC, activate level mode and fly
5. Land and adjust the roll/pitch software ACC trims via the TX to compensate in the correct direction
6. Fly again ang go to step 5 if the trim is not ok
Keep doing this until it is basically stable in roll/pitch for drift. Expect to do it at least 3 times.

BlueAngel explained it in this post.


g. Question: What are the RC stick commands to start, stop or perform other operations?
Answer:
Hamburger made a nice overview card with all commands,(see here.)

4: MultiWii components & resistors.

a. Question:How can one open a WM+
Answer:
Most clones & original WM+ are fitted with trigram screws. They can be opened with a 2x75 flat screwdriver (Facom AC.2x75). The 2mm flat tip just fits into the screw. (link)
A small drill bit could also work well, apply pressure and turn slowly.on a 1/16 drill held with a pair of vice grips (link)
Another option is to file a regular screw into the right shape & use a normal screwdiver. (link)

b. Question:What about the diodes, 3.3V voltage regulators & pin 12?
Answer:
The best solution until now is to just connect the WM+ & NK vcc to pin 12 from the Arduino. Pin 12 is supplying 5VDC to the WM+ & optionally the NK. This way the software can actually reset the WM+ if the I2C bus freezes. The freeze is detected & the WM+ is reset very fast (in the region of 33ms: link) . (see this post from Alex for more details).
Note that this option has saved already several quads & tricopters from hard crashes!
The WM+ has an on board voltage regulator on board and works perfectly with a 5VDC supply.

Alternatively, the WM+ can be powered from 5VDC or from 3.3VDC continuously. Note that the software cannot reset the WM+ if the I2C communication bus freezes.

The optional Barometer sensor or different ACC works only if powered with 3.3VDC. The 5VDC from pin 12 must thus be reduced to this 3.3VDC. This can be done by placing 2 diodes in series with the sensors (link) or by connecting an 3.3V voltage regulator (LM1117). Of course other options are possible. E.g. powering it from the 3.3V from the Arduino Nano.

c. Question:What about the pull-up resistors? Enable or disable them[/I]
Answer: (link)
The internal pull-up resistors in the arduino are disabled by default in v1.6 This is done by Alex to prevent damage to certain sensors which do not support 5V. Note that in version 1.7 the pull-ups are enabled again for the normal WM+ setup. Advanced 9DOF boards may need to have disabled pull-ups.They can be enabled in the software by this line: #define INTERNAL_I2C_PULLUPS
- If you use a WMP alone: enable it in the software.
- If you use a WMP + NK : enable it in the software.
- If you use a WMP + BMP020 (5V friendly thanks to its internal LLC): enable it in the software.
- If you use a WMP + (LLC + I2C devices): enable it in the software. (For an example see also diagram 6. Full MultiWii with ADXL345 & BMP085 - Option 2 )
- If you use a WMP + direct I2C bus connection I2C devices (not 5V friendly): disable it in soft and use external pull-ups on 3.3V. Note that most breakout boards have built-in pull-ups already.


d. Question:What are the values for the voltage dividing resistors
Answer: (link)
For 3S, resistors 33K and 51K, although different values can be used, the measured levels can be adjusted in the code. See this post from Ilmar for more test data.
As a reference one can take the following values.
VBATLEVEL1_3S 960
VBATLEVEL2_3S 880
VBATLEVEL3_3S 800

For 2S using resistors of 47k and 68k (link)
8.4v = 1009 7.4v = 887 6.0v = 725
8.0v = 960 7.0v = 840
7.5v = 900 6.6v = 800
7.4v = 887 6.5v = 780

e. Question:What is the value for the resistor in series with the status led
Answer: (link)
The resistor is a current reducer for LED. Possible values from 220 Ohm to 1 kOhm.


f. Question:How & where should the ACC be mounted on the board/model
Answer: (link) and link
The gyro position is not so important, but the ACC position should be as close as possible to the CG.


g. Question:Is a PPM converter necessary?
Answer: (link)
In short, the PPM sum signal is only needed for the Y6 or Hexa, not for the Tri or quad copter.

The Arduino Pro Mini is limited in I/O's, therefore in order to save some I/O's we need to compress all receiver channels into one signal.
This signal is called the PPM Sum signal & is fed onto pin D2 of the Arduino. Currently, 5 channels in the PPM stream are interpreted by the softwared.
It's also possible but not obliged to use the PPM sum signal for a quad or tricopter config. The remaining input pins on the Arduino are then not used.
Some receivers have a direct ppm output stream, others can be modified or a converter must be used.
See this link & search under Converters and tools and mods for composite PPM signal for available options.
Note, the Spektrum satellite receiver does not output an usable ppm stream for the MultiWii, a different protocol is used in the Spektrum satellite.


h. Question:Should the ESC's been set for LIPO or NIMH?
Answer: (link)
If an ESC is programmed with a LIPO setting, most probably the ESC will power down when it's cell value goes typically below 3V. This means that on a multicopter this almost certainly leads to a crash. If one programs the ESC's with the NIMH option, the ESC will not shut down but the overall power will start to decrease allowing the pilot to land the multi copter.
Note that draining the LIPO too far will decrease the performance of the battery very fast.

5: Wii Motion plus update rate: 100kHz vs 400kHz.

a. Question:What & when should 400kHz be used.
Answer: (link)
An original motion plus generally runs only at 100kHz, some clones work perfectly on 400kHz but this is not the case for all clone versions.
Some experience more WM+ freezes when the WM+ is running at 400kHz. It's certainly no problem to run at 100kHz most people will not notice any difference.
In general it's better to start with the I2C communication at 100Khz excluding possible errors.

Note, this has nothing to do with the ESC update rate. For the MultiWii we need a fast update rate & ESC's which can handle that. There are a number of standard ESCs than can handle update rates of about 490 Hz, namely Turnigy Plush, Mystery Blue, HK SS and a few others. the 490Hz basically means that the ESC gets 490 times per second an update. A standard servo for example works at 50hz or is updated 50 times per second.

Alex made a diagram with the different frequencies used in the MultiWii project

6: GUI related issues.

a. Question:The values in the GUI do not seem to work or update.
Answer: (link)
The ACC & gyro values are only displayed in the GUI if everything is connected & running.
To quote JimnAz:
"Without sensors or radio connected to the Arduino,,,,There is no input to the controller so therefore, there is no output.....

If you connect the receiver to the arduino and have the corresponding transmitter on, then when you move the sticks you will see the data on the GUI. If you connect the MP to the Arduino, then you will see the Gyro data even without the receiver attached to the board."

Furthermore, as from version 1.4 the ACC first needs to be calibrated before the output can be seen on the GUI
Manual calibration: full yaw left + full pitch down + min throttle.
Make sure the throttle channel is going below 1100 in the GUI otherwise the calibration will not be triggered.
The values are typically around 400, -400, -400 before & should be 0, 0, 200 after calibration.

b. Question: The GUI seems to lock up or freezes during connection.
Answer: (link)
Make sure you are not going to fast, in general it seems better to wait a few seconds between & before the start command on the GUI is given.
To quote vic20owner:
I usually have to start it a few times.
1) Boot arduino
2) Start Configurator
3) wait a few seconds
4) click "start"
5) wait
6) if WMP data, click read
7) wait... move quad a little
8) ACC data shows up...

If 4 fails (locks up), exit the configurator and try again. Also, on the mac, if I do not choose the correct serial port (USBSERIAL) or did not install the drivers, it locks up when I select the serial port.

It does work though, it just takes a few tries to make the connection.

c. Question: The GUI itself doesn't start or seems to give some errors..
Answer:
Make sure you have the correct JAVA runtime installed, the latest version can be downloaded here. If you encounter problems with JAVA, I recommend uninstalling your current JAVA version en installing the latest version again.
If possible, try to run the software from another computer.

d. Question:I noticed there is a new " Scale " function just beside the cycle time in the GUI, whar is it use for ?
Answer: (link)
It scales only the display of the sensor data. So you can better see small movements or vibrations from the gyros & ACC.

e. Question: Did the throttle rate inverse from 1.4 to 1.5?
Answer: (link)
Yes, the default setpoint is 0 for pitch, roll and throttle rate. It's kept at 0 if one doesn't need it.

f. Question:How should the gyro values change in the GUI when the WM+ is correctly mounted?
Answer: (link)or this linkAvoiding flip overs
When the gyro is mounted correctly:
tilt left => negative values
pitch back => negative values
yaw left => negative values

7: Arduino software errors

a. Question: A "sketch too large error" when compiling is generated
Answer:(link)
The software is written for an ATmega328, if the ATmega168 is chosen in the Arduino program via the Tools Menu --> Board then this error is generated.
It's possible to disable some parts of the code so it will fit on an ATmega 168 however, the LCD interface cannot be used then.

b. Question: A "'MINTHROTTLE' was not declared in this scope
" when compiling is generated
In the configurable parameters you need to uncomment one of these 2 lines

//#define MINTHROTTLE 1300 // for Turnigy Plush ESCs 10A
//#define MINTHROTTLE 1120 // for Super Simple ESCs 10A

8: What about the PID settings?

a. Question:How do the default PID settings perform, how much should they be changed?
Answer: (link)
A complete explanation about PID tuning goes beyond the scope of this FAQ.

In short: the default PID values should get almost all normal sized multi copters up & flying pretty good.

P: 4
I: 0.035
D: -15

Further tuning is mostly done by just lowering / raising the P value.
In order to fine tune, Alex suggest to increment/decrement the values with the following steps: P:0.2 ; I:0.005 ; D:1

Description from Centurian

"P" fights all motion... increase until you get a feedback wobble, reduce by ~20%

"I" is heading hold.... increase until you get a bounce back when you release a big stick input.

"D" the bigger the better from what I can tell this tries to smooth out any rotation. The higher you run "D" it appears you can further increase "P"
"D" the bigger the better from what I can tell this tries to smooth out any rotation. The farther from zero you run "D" it appears you can further increase "P"

You can find Centurian's full description of the PID parameters directly related to the MultiWii firmware here & here.

You may find another PID description from JollyJoker here.

To be continued

3: MultiWii additional adapter boards

Please note that this part is not up to date anymore. In the mean time the available hardware has grown very fast. It's not possible to maintain all the available adapter boards made by so many different users. The post itself will stay available as a reference.

In this part I'll try to combine several shields & adapter boards which are available for the MultiWiiCopter.

Note that some shields are provided with all details & original files while others have very limited information.
Nevertheless they can provide a good source of information.

Important note about Arduino Nano's.
It seems that the pin-out on some versions of the Nano boards is different!
See this post from Frank where he points out the differences on an Arduino Nano board from Gravitech (Link)
Be carefull & take this into account when making or using a shield!

1: Round adapter board by Warthox:

A proven board originally designed by Warthox ((Link)
The board can be used for a Tri- and Quadcopter.

2: Warthox's board commercialized by AlouetteIII:

This "commercial" available pcb is an upgraded version of Warthox his round adapter board.
Announced here in the thread.

It's available at http://www.multiwiicopter.com/.
The board can be used for a Tri- ,Quad-, Hexa, & Y6-copter together with all the features of the MultiWii1.6 version. It has an on board 3.3V regulator.

3: Round adapter board adapted by Ilmar:

Another version based on Warthox's board is the Round MultiWiiCopter Shield2 by Ilmar,
The board can be used for a Tri- and Quadcopter.
Optionally, connections for battery voltage monitoring with a buzzer and camera pitch & roll stabilization pins are available.

Several versions of this board updated by Ilmar are available on his blog. (Link Ilmar blog)

4: Square board by JussiH (420RcPilot):

This version is available from JussiH (420RcPilot).

For now, this is the only board which supports all current functions of MultiWiiCopter.
This board can be used for a Tricopter, Quadcopter, Y6, Hexacopter & Gimbal function.

It is also possible to use a separate option for a 3.3V power supply to the sensors. More information can be found on his blog. (Link JussiH (420RcPilot) blog)
A complete step by step assembly guide is provided with detailed pictures on the blog.

The shield is regularly updated, the latest version is shown below.

5: Kuki83's Arduino Nano adapter board with integrated ppm sum converter:

Below board is designed by Kuki83 (Link.)
It has an embedded PPM sum converter. It's possible to add a 3.3V voltage regulator.
The board can be used for a Tri- and Quadcopter.

See his blog for more & other boards.

6: Kuba_em small MultiWii board:

Below version is based on an ATmega 328 PCB only, it's not using the typical Arduino Pro Mini but is probably the smallest adapter board of all current versions.
More info can be found here.

Note that the ATmega328 processor in this pcb cannot be programmed the same way the Arduino Pro Mini is programmed. For options see this post by Kuba.

7: Kuba_em Arduino Duemilanove board::

Another adapter board by Kuba_em is designed for the Arduino Duemilanove instead of the Arduino Pro Mini.
See this link for more details.
& this link for the brd files.
The board can be used for a Tri- and Quadcopter.

8: Yorbid's Arduino Nano interface board:

An interface board for the Nano has been made by Yorbid, see this post for details. (limited info available)
The board can be used for a Tri- and Quadcopter with optional camera roll & pitch stabilization.
It uses the 3.3VDC output from the Nano as a power source for the sensors. No automatic WM+ reset is available if the I2C bus freezes with this option.

9: S3NS3 adapter board:

Another version for the Arduino Pro Mini made by S3NS3 is available in a Sprintlayout-File
The board can be used for a Tri- and Quadcopter.
Optionally, connections for battery voltage monitoring with a buzzer are available.
See this post for details.

10: Universal Arduino Nano adapter board:

This is a universal adapter board for Arduino Nano's.
They can be found e.g. on EBAY.


Note: Double check your connections on this board.
As reverendrichie mentiones in this post it's easy to blow your Nano due to the different labeling.

11: Nano adapter board by Pepetone:

This is an adapter board based on Ilmar's (& original Warthox's) round adapter board. See this (Link) for Pepetone's source files.
The board can be used for a Tri- and Quadcopter with optional camera roll & pitch stabilization.
Connections for battery voltage monitoring with a buzzer are available. The board can be powered with a separate BEC and has a power available + status LED.
Note:
The board is for the Arduino Nano v2. The Arduino Nano v3 pinout seems different for some boards (link).
When the board is powered from the ESC 5V then all ESC 5V supplies are in parallel. Take care to connect only one ESC supply.

12: Pro Mini & Nano adapter board by Rurek & Kuba_em: (PENDING)

2 universal boards supporting all the features of the MultiWii v1.5(Link)
The boards have the option to use diodes, pull-up resistors & independent voltage regulator. Shield mounting holes are 45mm x 45mm. Additional holes are foreseen to mount the WM+ onto the shield.
For more information see www.arduwii-copter.eu. According the site, more info will be available later.

Arduino Pro Mini


Arduino Nano

13: Pro Mini, ADXL345, BMP085 by Markussp:

A nice board consisting of 2 boards stacked on top of eachother.
One board contains the Pro mini & a LLC while the other hold the WM+, ACC & Barometer sensors.(Link to latest & updated version)
The board layout is available in a SprintLayout file.

14: A small board based on an ATmega 328 PU DIP

A commercial board made by Fabien Fpv4ever team. (Link)
It's available in different packages & the only thing extra needed is a WMP, nothing else.

Of course, one can make his own shields with regular prototype boards or just solder everything directly onto the Arduino.

To be continued & updated.

4: MultiWii release descriptions

This post just combines the release descriptions of the last revisions.



Release version 1.9
1.8 -> 1.9

- some factorizations between PPM sum receiver code & standard receiver code

EXPERIMENTAL: integration of direct SBUS receiver thanks to the contribution of Captain IxI & Zaggo

For this, you must use:
- a MEGA board
- the RX1 of the Serial 1 port
- have a way to invert the input signal.
more info here: http://www.multiwii.com/forum/viewtopic.php?f=7&t=289

EXPERIMENTAL: integration of SPEKTRUM satellite receiver thanks to the contribution of Danal Estes

For this, you must use:
- a MEGA board
- the RX1 of the Serial 1 port
It could be used also on ProMini board with some restrictions (exclusive GUI or Spektrum use)
more info here: http://www.rcgroups.com/forums/showthread.php?t=1504116

EXPERIMENTAL: integration of direct Serial RX, to command the multi from a Bluetooth+phone Signal for instance.
thanks to Luis

- many optimizations to reduce loop cycle

- GPS main function integration

The code to connect and recognize a GPS with NMEA sentences is here.
currently calculated:
- number of sat
- distance to home
- direction to home
The is currently to control code except a nice working GUI
=> there is no code behind GPS HOME and GPS HOLD, in progress

- PIN A0 and A1 instead of PIN D5 & D6 for 6 motors config and promini config
This mod allow the use of a standard receiver on a pro mini
(no need to use a PPM sum receiver)
#define A0_A1_PIN_HEX

- possibility to use PIN8 or PIN12 as the AUX2 RC input
it deactivates in this case the POWER PIN (pin 12) or the BUZZER PIN (pin 8)
#define RCAUXPIN8 or #define RCAUXPIN12

- thanks to Danal, integration of the Eagle Tree Power Panel LCD for configuration
it's an I2C LCD that should be very convenient for the ProMini because it doesn't require the unique Serial Port

- all in one FC:

QUADRINO_ZOOM board integration
MINIWII : Jussi's MiniWii Flight Controller

- sensor boards:

SIRIUS600 // Sirius Navigator IMU using the WMP for the gyro
CITRUSv1_0 // CITRUSv1 from qcrc.ca
DROTEK_IMU10DOF

- ATAVRSBIN1 mag direction correction (http://www.multiwii.com/forum/viewto...start=60#p4950)

- no need to define anymore PROMINI or MEGA in the sketch:
this information is grabed form the board selection in Arduino IDE

- LEVEL drift problem:
the root of this problem was identify (at least partly).
Several options to try to solve it:

- adding a #define TRUSTED_ACCZ for those who have huge ACC Z variations when some throttle is applied
(it's a test you should do before tructing ACCZ)
//#define TRUSTED_ACCZ -> ACCZ is not taken into account in calculation for small angles
#define TRUSTED_ACCZ -> ACCZ is taken into account in calculation for small angles

- BMA180 init changes to another mode: should help to filter noisy setups

- adding a #define STAB_OLD_17 for those who still encounter problem with the stable code, as the old 1.7 LEVEL code (less elaborated) doesn't seem to cause drift.

- some flying wing code upgrade (thanks to the suggestion of Hamburger)

- ACC added: LSM303DLx_ACC

Release version 1.8
MAIN SOFT: code modularization.

There are now multiple .pde files
The configuration should be changed only in config.h
The files are opened with the Arduino IDE (open one file and the remaining files will follow)
This change should ease more easily the extension of MultiWii project in the future

MAIN SOFT: due to the multiplication of multiwii hardware compatible boards

a first try to manage automatically in config.h the definition of
- sensors
- orientation
- I2C address
for the moment:
FFIMUv1 // first 9DOF+baro board from Jussi, with HMC5843 <- tested by Alex
FFIMUv2 // second version of 9DOF+baro board from Jussi, with HMC5883 <- tested by Alex
FREEIMUv1 // v0.1 & v0.2 & v0.3 version of 9DOF board from Fabio
FREEIMUv035 // FreeIMU v0.3.5 no baro
FREEIMUv035_MS // FreeIMU v0.3.5_MS
FREEIMUv035_BMP // FreeIMU v0.3.5_MS
PIPO // 9DOF board from erazz
QUADRINO // full FC board 9DOF+baro board from witespy <- tested by Alex
ALLINONE // full FC board or standalone 9DOF+baro board from CSG_EU
AEROQUADSHIELDv2 // the 9DOF version of aeroquad shield v2
ATAVRSBIN1 // Atmel 9DOF (Contribution by EOSBandi). The board requires 3.3V power.
It's still however possible to declare individual sensors for a different configuration
If everything is commented (default conf), MultiWii assumes there is only a WMP or a WMP+NK connected.

MAIN SOFT: introduction of a deadband around the stick center
via a #define DEADBAND. (commented by default)
it might help to get some accuracy from RC TX with not accurate potentiometers
however, as it introduces a central deadband, the TX trims are not efficient as before.

MAIN SOFT: new altitude hold
there is now a working implementation
thanks to ziss_dm, the estimation of the altitude is more precise.
the Z ACC is integrated in the alt hold estimation and helps a lot to estimate short term variation
how-to:
the multi must be nearly altitude stable before the activation of altitude hold.
a dead band is then created around the throttle value.
at every moment, it's possible to still control the trhottle power when the throttle goes out of the deadband
this is not the best implemetation as the multi needs to be quite static before the activation, but it's a good start.

There are 2 PIDS which are separated ans which can be used separatly.
ALT PID: better results are obtained with a P only term (P=4.7 I=0 D=0 is the default value)
VEL PID: it stands for velocity PID, more info here: (P=I=D=0 is the default value)
it should help to smooth every altitude varation
http://www.multiwii.com/forum/viewtopic.php?f=7&t=363

GUI: altitude representation
there is an autoscale feature in the GUI to see better the altitude variation.
So, don't be surprised about the huge amplitude of altitude curve in the GUI.
The altitude is displayed in meter in the GUI.
A normal variation when the multi is not Z moving should be around 0.5m

ALL: thank to Hamburger, integration of a power meter estimator
voltage reading (now available in GUI) and alarm set up.
(see full description and manual in config.h file)
more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=167

MAIN SOFT: thank to Hamburger, integration of a LCD telemetry
very convenient with the TEXT STAR LCD and it's 4 buttons
for other LCDs with no button, implementation of a Telemetry autoswitching
(see full description and manual in config.h file)

MAIN SOFT: thanks to ziss_dm hint, gyro are calculated with more software internal resolution.
This should smooth the overall alttitude.
might not be so good with very noisy WMP copies

MAIN SOFT: more settings are avalaible for the ITG3200 gyro
there was also a bug regarding the ITG3200 initialisation which is corrected => 2000deg/s setting is now used.

thanks to EOSBandi: ITG3200 & ITG3205 Low pass filter setting. (see the according #define in the config.h file)
In case you cannot eliminate all vibrations to the Gyro, you can try
to decrease the LPF frequency, only one step per try. As soon as twitching gone, stick with that setting.
It will not help on feedback wobbles, so change only when copter is randomly twiching and all dampening and
balancing options ran out. Uncomment only one option!
IMPORTANT! Change low pass filter setting changes PID behaviour, so retune your PID's after changing LPF.
see config.h for the related #define

MAIN SOFT: New angle calculation by ziss_dm
it's a completly new approach wich gives a constant cycle time
and a representation in all attitude.
there are some singularity when an angle reaches 90deg. It's normal.

MAIN SOFT: thanks to ziss_dm, there is another way to use the level mode.
no overshoot is possible, but the reaction time is longer
more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=503

MAIN SOFT: code rework: RX rate/expo is now interpolated via a lookup table without any float.

GUI: thanks to shama, disparition of warning messages

MAIN SOFT: thanks to C2po , some more tuning on BMA180 I2C initialization.

ALL: 3 octo configs are now supported on mega boards: OCTOX8 (dual coax quadX), OCTOFLAT+, OCTOFLATX
motor order: PIN 3,5,6,2,7,8,9,10
OCTOX8:
REAR_R , FRONT_R , REAR_L , FRONT_L , UNDER_REAR_R , UNDER_FRONT_R , UNDER_REAR_L , UNDER_FRONT_L
OCTOFLATP:
FRONT_L , FRONT_R , REAR_R , REAR_L , FRONT , RIGHT , REAR , LEFT
OCTOFLATX:
MIDFRONT_L , FRONT_R , MIDREAR_R , REAR_L , FRONT_L , MIDFRONT_R , REAR_R , MIDREAR_L
one detail: the GUI is not yet adapted to display the 8 motors & the according 3D representation on the right

MAIN SOFT: PITCH&TILT camera compenstation with channel 7 & 8 is now working
- must be used with SERVO_TILT option
- TILT/ROLL inclination compensation is still trigged by CAMSTAB GUI checkbox option

GUI: improvment by Hamburger
improvement to the devices list in the gui and that got me to tuning it a bit more.
- list is still too short for my amount of known devices - some vertical space is unused,
so longer box is possible
- on mac, for each bt-device I get two device files:
cu.name and tty.name. using the tty.name is recommended by arduino documentation,
so do not add the cu.name devices to list
- remove leading tty. from names to use limited space for readability.

LCD: improvment by Hamburger: exit without save from EEPROM menu
You can use the LCD quite extensively for viewing values - especially with development versions.
Therefore there is a need to exit the LCD config loop without doing a complete write to eeprom.
The eeprom is limited to only 100.000 write cycles.

ALL: thanks to Cass3825, new optional arming procedure via an AUX switch
this option is activated only if at least one checkbox is checked on the line "ARM"
the motors won't arm if the copter is plugged while the tx switch is in the armed position.
you must use the switch to disarm position then back to arm position in order to arm the motors.

Another 'feature' worth mentioning is that changes in the switch position are only
acknowledged when the throttle stick is all the way down.
This prevents accidentally arming the motors at mid or full throttle.
One downside is that the motors will not disarm unless the throttle stick is all the way down.

ALL: it's now possible to calibrate the MAG from the GUI (and mandatory for the first time)
once activated, the LED will flash very fast for 30s
you have exactly 30s to move the multi in all possible direction
(one full turn on each axis is sufficient)
There is no order to respect, but it is important to cover every directions.

GUI: introduction of MAG 3 axis raw values

MAIN SOFT: BI-COPTER PIN 6 servo correction

MAIN SOFT: thanks to jevermeister,
the failsafe function of the PPM sum receiver was a little mofified and can handle better
unusual signal patterns with short pulses.

Release version 1.7

Originally Posted by Alexinparis

So the 1.7 is finally here

MAIN SOFT: gyro sensitivity corrected on L3G4200D

MAIN SOFT: thanks to ziss_dm, nunchuk alone integration (incompatible with WMP and seen as a standalone I2C ACC)

MAIN SOFT: bug correction with tricopter for MEGA boards #define DIGITAL_SERVO_TRI_HIGH -> 1<<4

MAIN SOFT: bug correction the mag indication was reversed

MAIN SOFT: small bug correction in angle calculation (conversion rad->1/10 deg)

GUI: thanks to Eberhard, better display of serial ports on Mac OS X and Linux

MAIN SOFT: added a small delay after ITG3200 init to have a better calibration

MAIN SOFT: possible fail-safe deactivation via #define

MAIN SOFT: thanks to zara,
vbat code simplification + low pass filter.
vbat activation via #define.
coupling alarm with status LED

MAIN SOFT: reduce the PPM sum recognition delay between 2 sequences (5ms->3ms). (might be the source of frsky PPM sum
problem)


And to summarize, all differences between 1.6 and 1.7:
there was really a huge work on this evolution

ALL: BARO is more precise, but still not perfect (1m to 2m amplitude). Note it's a code issue, not a baro component issue.

ALL: RC channels AUX2, CAM1 CAM2 added. only relevant for PPM SUM stream or MEGA boards.

On the 328p with a standard receiver, only the first 5 channels are recognized.
CAM1 and CAM2 controls are not yet implemented.

ALL: AUX1 and AUX2 switches are fully customizable via a 3 state position.

We can activate/deactivate individually level mode (ACC), baro or compass (mag).
It's a generic approach which lets other possibilities to control things in the future.
With this principle, it's possible to activate permanently the options you want even if you have only 4 channels
(replace the FORCE LEVEL option)

ALL: CAM triger option:

a servo can be connected on digital pin A2 (pro mini) to activate the trigger of a camera
the option can be activated or deactivated via the button configuration panel AUX1/AUX2
#define CAM_SERVO_HIGH 2000 // the position of HIGH state servo
#define CAM_SERVO_LOW 1020 // the position of LOW state servo
#define CAM_TIME_HIGH 1000 // the duration of HIGH state servo expressed in ms
#define CAM_TIME_LOW 1000 // the duration of LOW state servo expressed in ms
the PIN on arduino mega is also A2, but this is not the final PIN mapping

ALL CAM stab (servo tilt) button option:

the servo tilt option can be activated or deactivated via the button configuration panel AUX1/AUX2

ALL: BI COPTER is now a avatar style implementation.

on a pro mini: 9 motor left, 10 motor right, 11 servo left, 3 servo right
on mega: 3 motor left, 5 motor right, 6 servo left, 2 servo right

ALL: addition of Y4 (not tested)

on a pro mini: motors 9,10,11,3
on mega: motors 3,5,6,2
REAR1 , FRONT R , REAR2 , FRONT L

ALL: addition of HEX6X (not tested)

on a pro mini: motors 9,10,11,3,6,5
on mega: motors 3,5,6,2,7,8
REAR_R , FRONT_R , REAR_L , FRONT_L , RIGHT , LEFT

ALL: new level mode

The level mode is completely redesigned with a coherent independent trim
There a now a PI control loop for level mode based on angle estimation.
The old auto level strength value was a sort of P only control loop.
With the new code, the I term allows to refine the remaining angular error for a better angle positioning accuracy.
With an RC rate = 1, the angle at full stick is around 45deg => a flip should never happen in this mode.

MAIN SOFT: software trim for stable mode

It is now possible to adjust the trim of the level mode to match the same TX trim used for the acro mode.
1) disarm the motors
2) full throttle (must be >1900)
3) full PITCH forward/backward and full ROLL left/right (2 axis possibilities) will trim the level mode according to
the neutral angle you want to change. The status LED will blink to confirm each ticks.

MAIN SOFT: new calibration procedure

The ACC calibration differs now from the gyro calibration.
gyro calibration: it's still done at each power on. It's also possible manually as before: min throttle+full pitch
backward+full yaw left.
acc calibration: motor disarmed, full throttle up, full pitch backward+full yaw left.

MAIN SOFT: it was in 1.6 but not mentioned. it's possible to arm/disarm motors

either via min throttle + full yaw stick or full roll stick.

MAIN SOFT: anti yaw jump modification for multi with 4 motors or more

MAIN SOFT: servo range for tricopter

#define TRI_YAW_CONSTRAINT_MIN 1020
#define TRI_YAW_CONSTRAINT_MAX 2000

MAIN SOFT: thanks to Ciskje, integration of L3G4200D gyro (this Gyro is present in PIPO ISU)

MAIN SOFT: HMC5883 compass integration

MAIN SOFT: compass lock now works

the option can be activated or deactivated via the button configuration panel AUX1/AUX2
the lock is activated 1s after the stick release
the lock is maintained only if the YAW stick in centred +/- 50
In some case, especially with the 5883, the mag must be calibrated otherwise, the direction is not good.
The calibration procedure is not yet implemented.

MAIN SOFT: there was a bug on servo tilt (it came back to zero at around 45deg due to a variable overflow)

MAIN SOFT: thanks to Syberian, a bug was corrected to prevent ACC correction just before hovering.

It could explain some odd flips when using autolevel at the beginning

MAIN SOFT: thanks to ziss_dm, a bug was corrected about the ITG3200: there was a variable

overflow which occured only for high PITCH variation.

MAIN SOFT: thanks to mis_b (MIS), integration of failsafe code.

Failsafe detect absence of RC pulse on THROTTLE channel (standard PPM receiver)
If the pulse is OFF the failsafe procedure is initiated.

After configurable FAILSAVE_DELAY time of pulse absence,
the level mode is switched to ON (if ACC or nunchuk is available),
PITCH, ROLL and YAW is centered and THROTTLE is set to FAILSAVE_THROTTLE value.
This value is dependent from your configuration, AUW and some other params.

Next, afrer configurable FAILSAVE_OFF_DELAY time,
the copter is disarmed, and motors are stopped.
If RC pulse coming back before reached FAILSAVE_OFF_DELAY time,
after the small quard time the RC control is returned to normal.

The fail-safe can be deactivated via #define

MAIN SOFT: thanks to ziss_dm, nunchuk alone integration (incompatible with WMP and seen as a standalone I2C ACC)

MAIN SOFT: bug correction the mag indication was reversed

MAIN SOFT: small bug correction in angle calculation (conversion rad->1/10 deg)

MAIN SOFT: added a small delay after ITG3200 init to have a better calibration

MAIN SOFT: thanks to zara,

vbat code simplification + low pass filter.
vbat activation via #define.
coupling alarm with status LED

MAIN SOFT: reduce the PPM sum recognition delay between 2 sequences (5ms->3ms).

might be the source of frsky PPM sum problem

GUI: 3D copter attitude visualization

GUI: ACC calibration. there is now a calibrate button to calibrate the ACC directly from the GUI

(it resets the soft trim)

GUI: thanks to Eberhard, better display of serial ports on Mac OS X and Linux

GUI: the memory leak bug GUI is corrected

GUI and LCD: D is now positive (to avoid confusion in explanations)

LCD: all parameters are now customizable via the LCD thanks to the work initiated by Shirka.

This first one is still P for both ROLL&PITCH as it is the most used.

LCD: implementation of TextStar LCD tanks to Hamburger & gtrick90 code

OSD: implementation of MIS code thanks to Rurek

thanks to Rurek and mis_b, optimisation of OSD code Serial write is driven by a switchable interrupt,
minimising delay to transmit data

SITE: www.multiwii.com was updated accordingly.

SPECIAL NOTE ABOUT THE PULL-UPS:
- they are now enable by default
- WARNING if you use I2C devices that don't support 5V.

- If you use a WMP alone: enable it in soft
- If you use a WMP + NK : enable it in soft
- If you use a WMP + BMP020 (5V friendly thanks to its LLC): enable it in soft
- If you use a WMP + (LLC + I2C devices): enable it in soft
- If you use a WMP + direct I2C bus connection I2C devices (not 5V friendly): disable it in soft and use external
pull-ups on 3.3V. note that most breakout boards are built with pullups already available.



Release version 1.6

Originally Posted by Alexinparis

I think it's time to release the version 1.6

list of differences with the 1.5

- MIDRC in a #define configuration : allow to choose another stick center position for specific TX

- Free Flight IMU integrated, designed by Jussi (see specific rcgroups topic). Front orientation = Y arrow

- Gyro ITG3200 integration : note this version uses a different I2C address of the sparkfun breakout ITG3200 board
the ITG3200 replaces the WMP once the #define line is uncommented. Can be used as a single sensor if needed.

- Acc BMP180: thanks to the code of Opie, but I changed the orientation to match FFIMU
it works fine and is activated with mode selection.

- Magnetometer HMC5843: for the moment integrated for visualization purpose only in the GUI. works only for inclination<25deg

- Baro BMP085: it acts as a celling and is activated with mode selection.
Not well implemented for the moment, big jump. To deactivate it, it's possible to comment the #define line

- pullups are now de activated by default, there is a #define INTERNAL_I2C_PULLUPS to activate them.
the de activation of pullups is mandatory for a FFIMU direct connection with no LLC

- support of the following ACCs: BMA180, BMA020, ADXL345. Thanks to the contribution of mgros, opie11 and Point65

- GUI: new buttons to indicate the presence of sensors.

- bug corrected (thanks to Bo): in some case with a WMP + annex ACC,
WMP data was interpreted as NK data yaw jump correction modification (less present)

- remove old way to init motor and calibrate. No more full throttle fear.

- corrected: PIN5&6 switch bug for HEX6 and Y6

- Arduino MEGA integration

thanks to the work initiated by Mariano,
I completed it to be be fully compatible with Arduino MEGA boards (all configs and options).
With MEGA boards like seeeduino,
it's possible to have some config impossible to have with a pro mini: Y6+standard receiver+tilt servos

it's just a #define to switch
#define PROMINI or #define MEGA //Arduino type

The PIN assignment for RC&motors is compatible with Aeroquad shield mega 2.x

PIN for MEGA board, not definitive, Jussi is preparing a shield with a different PIN mapping

PPM_SUM 19 (now separated from RC_THROTTLE assignment)
RC_THROTTLE 62 (=A8)
RC_ROLL 63 (=A9)
RC_PITCH 64 (=A10)
RC_YAW 65 (=A11)
RC_MODE 66 (=A12)
RC_AUX(not used) 67 (=A13)
RC_7(not used) 68 (=A14)
RC_8(not used) 69 (=A15)
I2C SDA 20
I2C SCL 21
FRONTMOTORPIN 2 (on 328p was 3) = servo for tricopter
REARMOTORPIN 3 (on 328p was 9)
RIGHTMOTORPIN 5 (on 328p was 10)
LEFTMOTORPIN 6 (on 328p was 11)
Y6RIGHT(HEXFRONT) 7 (on 328p was 6)
Y6LEFT(HEXREAR) 8 (on 328p was 5)
V_BAT_MONITOR A3
TILT&GIMBAL&WING A0/A1
POWERPIN 12

- a bug seen by Mariano in stable mode (sqrt on a negative number) is corrected

- TILT ROLL&PITCH is now compatible with TRICOPTER configuration

- anti gyro glitch : I re introduced a limitation between 2 reads as it seemed to be more stable. Info from Point65.

- RC rate can be extended to 5. With this option, we should see a more linear response on pitch/roll sticks for very acrobatic setups.

- on quadris we can notice some “yaw jumps” when the yaw is suddenly stopped.
There is now a function to smooth the stop.
If you don't like it just remove the line axisPID[YAW] = constrain(axisPID[YAW],-100-abs(rcCommand[YAW]),+100+abs(rcCommand[YAW]));

- sketch: I added an “advanced users settings” part with a description of some more tunning possibilities.

- If a ACC is present (Nunchuk or other I2C), you won't be able to arm the motors until you do a proper ACC calibration manually.
If the calibration is not done or if the multi is too much inclinated, the status LED will slowly blink every 1s.


The code is on the googlecode repository (see first post)

This code is as usual compatible with everything developed before
including the very low cost setup: WMP only + promini + standard 4ch receiver

Warthox: there is a #CAMSERVO option for you.
this one should work:

activated via AUX1
servo signal on A2

For others, it's a surprise



Release version 1.5

Originally Posted by Alexinparis

1.5

list of differences with the 1.4

• #define MOTOR_STOP
  this is an alternative method to stop immediately the motors when the throttle command is in low position
• HEX6 added
  motor pin :
  //REAR_R => PIN 9
  //FRONT_R => PIN 10
  //REAR_L => PIN 11
  //FRONT_L => PIN 3
  //FRONT => PIN 6
  //REAR => PIN 5
  
• anti gyro glitch : the time we neutralize data after a hard reset is increased. The impact of gyro glitches is greatly reduced. I can even fly safely with a bad WMP copy doing a hard reset every 5s.
• suppression of throttle rate pid curve: replaced by only one relevant value. PID can decrease proportionally between [1500-2000] throttle position (helps to prevent wobbling in fast translation).
• internal soft simplification: EEPROM, serial communication, motor naming.
• stable mode is greatly improved.
• support of ADXL345 I2C acc. Benefit: the loop time WMP+ADXL345 is reduced, allowing a better stability, comparable to a WMP only conf. Obviously, ADXL345 must not be connected with a with a NK setup.The integration of BMA020 I2C acc should be easy because the code frame is ready.
• when a NK is detected, the LED blink is much longer after the init step => it's a way to visualize the good detection of a nunchuk.
• support of BMP085 I2C barometer. But for visualization purpose only. It can't be activated yet for altitude stabilization.

Known issue:
the trim in acro mode is different of the trim in stable mode.

Note:

• if you use a NK or a ADXL345 acc. You must do a manual calibration to see good results in gui
  - stable mode with NK should indicate 0 / 0 / 200 acc values
  - stable mode with ADXL345 should indicate 0 / 0 / 250 acc values
  - If you have a constant +/- 400 values on the graph, the calibration is not done.
  
• for the WMP+ADXL345 setup: (+/-BMP085 for curious)
  - D12 +1 diode is used to poser the WMP
  - a 3.3V is used to power the ADXL345 (stabilized alim or multiple LED from a 5V source)
  - see picture for ADXL345 precise wiring
• to reset parameters to default: just upload an old version and the new again.
• this version is compatible with everything designed before (WMP only conf or WMP+NK)

Just want to say thank you for all of your efforts.
I really helps a beginner out.

Do you have any component numbers for the
lipo alarm and resistor? Or is just a basic micro scream
usable?

Thanks again

Bob K

Are there different versions of open source software for each of these configurations or are they all handled by MultiWiiV1_3?

Chuck

Originally Posted by Bob K

Just want to say thank you for all of your efforts.
I really helps a beginner out.

Do you have any component numbers for the
lipo alarm and resistor? Or is just a basic micro scream
usable?
Bob K

Well personally I use the Lipo alarms from ebay, they cost only a few euros and serve me well.


Alex implemented the lipo alarm, i can refer to the post of Joël here He did an nice write-up about it and specifies the resistor values used.
Keep in mind that the Arduino can only supply 45mA max. on an output pin!

Originally Posted by X-Ilmar

For 3S, resistors 33K and 51K.
-Ilmar-

Ilmar does suggest above resistors.

Of course the MicroScream: $5 Audible Lipo Alarm can also be used as alternative.

Originally Posted by EnigmaSoar

Are there different versions of open source software for each of these configurations or are they all handled by MultiWiiV1_3?

Chuck

All drawings (except the preliminary one of course) are compatible with the latest version of Alex his software MultiWii v1.4.
In the software you must choose the individual setup. (Tri, quad, Y6 etc)

That'll help to sort out the different wirings and connections.

Could you also please collect the different breakout boards that are already available? If it's not asked too much...

These boards would be really helpful for beginners since it makes the assembly and soldering of the components much easier.

Good afternoon all. I am having difficulty getting the GUI to run on my WinXP OS.

I downloaded the .zip and extracted the files into their respective directories. Attemps to run MultiWiiConf1_4.exe result in a « could not find the main class. Program will exit! » error from Java Virtual Machine Launcher.

I have confirmed the latest Java and JRE are installed on this machine and tried to run on another WinXP computer with same results.

At present I have completed the hardware build, created a shield board per the schematic drawings and am ready to begin testing.

I’m hoping someone might have an answer to this problem. Thanks and kind regards.

Thank you Berkley for compiling this information, very very useful.
With all of the help offered from people like yourself and orignal ideas from Alex how can I go wrong?
Thanks,
Tom

Berkley,
Nice MultiWiiCopter build info compilation! Much better than the MultiWiiCopter folder on my PC
Cheers,
Jim
Quadrocopter and Tricopter Mega Link Index

Thanks to Rurek here are links to the various revisions to the code:

http://www.rcgroups.com/forums/showp...postcount=5641

Originally Posted by Tahoe Ed

Thanks to Rurek here are links to the various revisions to the code:

http://www.rcgroups.com/forums/showp...postcount=5641

Here is the code repository & soon to be directory posted by Alex:

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

Personally, I would not recommend this board to anyone. I have one and because of the mislabeling and the abnormal power-pins layout, it is very EASY to destroy your Nano for which I did!!

10: Universal Arduino Nano adapter board:

This is a universal adapter board for Arduino Nano's. Simple & effective.
They can be found e.g. on EBAY.

for lm1117 shown in the schematic, you can use a http://www.sparkfun.com/products/526 and make note:

•LD1117V33 for ICs marked LD33V - 3.3V Regulator : 800mA Max