MultiWii

same old story:

well. v2.0 is out, some minor kinks are being addressed. So it is about time to rally up a list of features to come.
If you add an entry here, please mark whether you intend to implement it yourself or if it is a pure wish.

Summary of wishlist items and implementation status.
(including the carry overs from the old wishlist thread viewtopic.php?f=7&t=882&hilit=wishlist#p5366 )

integrated in Alex' dev version

• GUI visual feedback on all states (same way it is done for existent sensors now) and free up screen space next to sensors' list
• airplane mode
• LCDconfig and Telemetry: a multiline/fullscreen version of the config menu and telemetry pages for vt100 devices
• new serial protocol
• 8MHz support
• GUI: reset button
• throttle curve with tunable plateau for hovering
• LED flasher
• GUI: automatically turn graphs off if corresponding sensor is not present
• promicro support
• type airplane has more features (flaperons etc.)
• openLRS support
• more documentation in the wiki (never ending)
• code style (indentation, variable naming convention etc.) started
• GUI requires new ControlP5 library to compile - no backwards compatibility - binariy not affected

implementation submitted to *_shared

• Helicopter mode (experimental)
• cleanup and new layout of config.h
• configurable TX stick combos for arm/disarm
• OLED 1306 i2c support
• definition for nanowii board viewtopic.php?f=6&t=1337
• special copter type to calibrate the connected ESCs (experimental)
• configurable rate for servo signals
• servo middle's are just in eeprom if LCD is active (else the defines should work)
• convert GYRO_SMOOTHING into LCDmenu configurable items, store in eeprom

ideas MCU

• RC rate adjustment for stable mode
• Sport flying mode with stabilisation
• Tricopter servo; consider not moving the servo until after armed and control returned to center
• Dual EEprom settings
• Something to show the stable trim
• Repeat the Gyrocalibration if the copter is moved in the process of calibration
• perfected Acro & Level modes
• uM-FPU - i2c floating point co-processor
• uM-PWM1 - i2c 16 bit, 8 channels PPM decoder/generator
• Timecop's i2c to PWM converter
• autodetect sensors
• Autopilot with GPS waypoint and Return to home support.
• Altitude Hold perfected (over 10 cm)
• improve Acc calibration without any procedure (plug and play and store in memory)
• port to other architectures (stm32) boards
• replace low/mid/high for auxN switches with ranges (for those with n-way (multi)switches (n>3)
• turn vbat alarm levels into configurable items
• mavlink support (probably superseeded now by Alex' new implementation)
• full use of MPU6050 viewtopic.php?f=8&t=1080
• HOTT telemetry integration viewtopic.php?f=7&t=1284 (done in separate fork)
• FrSky/Jeti Telemetry support
• sonar viewtopic.php?f=7&t=1033
• Integration of SRF08 I2C sonar sensor viewtopic.php?f=7&t=1282
• consolidate various NextGeneration forks
• integrate dongs' stm32/FreeFlight port viewtopic.php?f=8&t=1193
• tune PID algorithm for stable sinking flight
• HC-SR04 Sonar support via secondary GPS Arduino I2C
• 3 warning levels for power consumption (same as with voltage)
• PID calculations at a constant time interval
  

ideas GUI

• pretty GUI graphics
• GUI -Able to backup/save/load settings
• Gui reset when lost signal with bluetooth
• GU remembers serial port
• GUI so it reports the full MWC firmware version number, INCLUDING the patch level
• GUI->Start includes intial ->Read
• GUI baudrate as configurable setting
• GUI advanced tab / convert some #defines to user configurable items
• Record flight data and replay for analyzing arter flying
• sliders for some more values
• port to android
• emulator for TX/RX input via GUI for testing
• tunable esc refresh rate

VTAIL is still on the V2.0

Bledi wrote:VTAIL is still on the V2.0

you mean it is included already? okay, removed from wishlist.

Not sure if current "Position Hold" fits into waypoints. Its more relevant to me in real life
"Autopilot with GPS waypoint, Postion Hold and Return to home support.

Should be a minor add for the GPS coders. (Not me! have not been follwing that part)

Yes,

Sonar and waypoint could be good

Hamburger wrote:Summary of wishlist items and implementation status.

• blablabla
• turn vbat alarm levels into configurable items
  

I've already done it a while ago....
http://www.multiwii.com/forum/viewtopic.php?f=7&t=974&hilit=fr3d&start=10#p6797

now I will try to implement it in mw 2.0

and currently for megaboard I've (re)defined gps led which
-turn off gpsled if gpsnumsat = 0
-blink gpsled if gpsnumsat < 3
-turn on if gpsnumsat > 3

and I can memorize a new gpshome point with following procedure
-motor not armed,
-gpsnumat > 3 (gpsled on)
-gpshome switch activate for a short moment.

code will follow after this afternoon tests.

Magnetron's moving average for gyros sounds interesting: viewtopic.php?f=8&t=1290&start=180#p10679

stable sinking flight
corrections thru sensors while Thottle at minimum, switchable flexible like e.g. sensors in GUI

abstract class or a wiki page for easy esc pwm timer and soft pwm calculation
official support for 8mhz (yes it is flying)

Request:

FrSky Telemetry support (A lot of us use it for CPPM and they have a good history of sharing protocol information) sending telemetry data in a format the FLD-02 can directly use would be sweet!
Even a simple batt voltage audible warning to the module would be invaluable.

HC-SR04 Sonar support via secondary GPS Arduino I2C or spare serial on the Naze

More support for Dongs (TimeCop's) STM32 Port (It's the future), maybe we could talk him into a sending Alex an AfroFlight (Naze) 32 for development?

Ive brought this up before and it's a wish ! I wish gui to have esc refresh rate in it like xaircraft gui does ! I mean where you can set refresh rate at what the esc's refresh rate is in the gui !! Come on Alex or someone , i know this can be done !!

Request:

Support for jeti telemetry system. using the jeti box for displaying flight data and modify PIDs.
there where a rudimental support for jeti some time ago. i have got the files but i am not a programmer to integrate it in a newer version.
if there is someone who can do this i will post the files.

I would like to see TimeCop's CLI feature incorporated.

http://www.rcgroups.com/forums/showthread.php?t=1595761

Gaijin wrote:HC-SR04 Sonar support via secondary GPS Arduino I2C

+1

http://www.youtube.com/watch?feature=player_embedded&v=ZZHBpg1WPQA#!



what about climbing???? will it be posibble??

hi,

it will be fine if you can integrate the saving and loading the whole copter config in a file, so I must no proceed printscreens to save a config and try another one ( like it is made in MultiWiiGUI).

thanks
flyman777

flyman777 wrote:hi,

it will be fine if you can integrate the saving and loading the whole copter config in a file, so I must no proceed printscreens to save a config and try another one ( like it is made in MultiWiiGUI).

thanks
flyman777

just use the wingui from eosbandi !
already done


by the way.... where is eosbandi?

But for using WinGui, you must have installed .NET
Otherwise, MultiWiiConf can run on all platforms that support Java and is lighter than WinGui.
This does not discredit the work of EOSBandi, his software runs very well.

Regards
flyman777

updated summary in post #2 of this thread
viewtopic.php?f=7&t=1417&hilit=wishlist&start=0#p10971

3 warning levels for power consumption (same as with voltage) - intend to implement

CP CCPM Helicopter integration

add optional configuration items to LCD config menu:
for all items currently #defined in config.h, which might need tweaking at the field and for which recompiling & flashing is undesirable.
Examples:
battery scale and 3 warning levels - yes.
minthrottle - yes
TRI vs. QUAD - no (I do not alter frames 'on the fly')
compiled in sensors - no (sensors are on the copter or not - I do not change that setup on a regular basis)
you get the idea.

I SECONDED the Ultrasonic both the D12/D8 and the I2C versions.

GUI-
download firmware option/configuration to your board without the need to use arduino. Arducopter has this now in their mission planner, very nice feature for noobs!

I think MultiWii is a very good platform but it lacks lots of things like perfection.. I should wait with doing new things.. Just make everything "perfect".. In code, performance, GUI, ..
Then start with adding a plugin system for the MutliWii so you have the multiwii core code.. without any sensors in it, every sensor could have it's own file in a sensor directory and it just loads the right sensors.. Which makes the code smaller.. more readable and it's easier to change things as a 3rd party developer.

Also I should advise Alex to change the variable names of some items.. Sometimes 3 different names are used for one thing..

Anyways. Making my own FC at the moment with sensor plugins and much more. Just an easy core that is rock solid.. No rocket science. Just the basic mechanism.. Everything else could be added via the plugin system that works on my own style of programming.

Just an idea that I'm working out, but hey it's open source so feel free to also develop it :p

Make the PID calculations at a constant interval. There are now faster processors using the software. The loop time at my 328P is about 3 ms. With an STM32 you have less than 1.5 ms. So the D term has half and I term double effect. I am just testing, what loop time make sense here. Maybe 10ms is enough.

it is already possible to auto trimming of the accelerometers?

jessestr wrote:I think MultiWii is a very good platform but it lacks lots of things like perfection.. I should wait with doing new things.. Just make everything "perfect".. In code, performance, GUI, ..
Then start with adding a plugin system for the MutliWii so you have the multiwii core code.. without any sensors in it, every sensor could have it's own file in a sensor directory and it just loads the right sensors.. Which makes the code smaller.. more readable and it's easier to change things as a 3rd party developer.

thats exactly what i think.

please stop adding all this wanted features before the current software is not finished and 100% working.
there are so many bugs and problems atm.
remember back to the beginning of the mwc, the code was perfected as far as possible till the first features were added.
now its like putting all thinkable features in a car and when u wanna drive it you have to realize that the car is to heavy to be driven only a meter.
i dont want to see the mwc like the arducopter or others soon, which have so many features added and never worked on a solid base and now its not even possible to fly a normal quad with default pid values!

Documentation!
-------------------
The website is not reporting all the features and there is a big lack of howto use the software and howto set up the functions!
This is very important because the forum is too dispersive :-/

warthox wrote:

jessestr wrote:I think MultiWii is a very good platform but it lacks lots of things like perfection.. I should wait with doing new things.. Just make everything "perfect".. In code, performance, GUI, ..
Then start with adding a plugin system for the MutliWii so you have the multiwii core code.. without any sensors in it, every sensor could have it's own file in a sensor directory and it just loads the right sensors.. Which makes the code smaller.. more readable and it's easier to change things as a 3rd party developer.

thats exactly what i think.

please stop adding all this wanted features before the current software is not finished and 100% working.
there are so many bugs and problems atm.
remember back to the beginning of the mwc, the code was perfected as far as possible till the first features were added.
now its like putting all thinkable features in a car and when u wanna drive it you have to realize that the car is to heavy to be driven only a meter.
i dont want to see the mwc like the arducopter or others soon, which have so many features added and never worked on a solid base and now its not even possible to fly a normal quad with default pid values!

This please.

Federico wrote:Documentation!
-------------------
The website is not reporting all the features and there is a big lack of howto use the software and howto set up the functions!
This is very important because the forum is too dispersive :-/

In the crius thread af RCG in first post is a good beginners guide.

I think that is unusual not to have the documentation on multiwii.com, it could be also a wiki, documenting every function and possibility... A beginner can't understand what multiwii is today reading the main page, and a pro can discover the news just reading trough all the forum...

all valid points and you got a new job!
Seriously, MWii is not strong with documentation. So it would help if a relative beginner described beginners' view and pitfalls.
There is the wiki as part of the google repository. It is currently ununsed apart from a single page of PWM description.
So your efforts are welcome, go ahead! (if you want to start the documentation wiki, contact Alex for write access and type away)

Hi !
+1 on perfect basic configuration (gyro+ACC).
+1 on documentation. I know I can find all needed info but it is spread around web.
Maybe 2 different releases like V.2.0 Basic and V.2.0 Bells&Whistles
Regards
Tom

Tifani wrote:Hi !
+1 on perfect basic configuration (gyro+ACC).
+1 on documentation. I know I can find all needed info but it is spread around web.
Maybe 2 different releases like V.2.0 Basic and V.2.0 Bells&Whistles
Regards
Tom

yep yep yep !

+ more documentation, real centralised documentation, written for 2.0+ (not 1.4 pre-alpha-beta-soupa-hamma-proof-of-concept version)
with step by step howto (building, coding, tuning)
+ stable and robust code/behavior/everything else for the basic configuration with the basic "frame" quad/tri with gyro/acc (arduino65536_64bit_arm42 for 32 motors with collective pitch looks great, but most of people start with the basic config)

Hi,

i noticed that the "basic" sketch's byte size growth (with standard config.h settings).. i think it may be better to isolate more things via config.h activation.

so i whish that:
- LCD would be not active in "standard" (i think the most people dont have LCD's)
- servo middle's are just in eeprom if LCD is active (else the defines should work)
- specal buzzer code is also seperated with a define (it takes ~750byte atm.)
- things like headfree mode's code (that may be a good thing for some people) is seperated with a define
- the codes size is less then 14000bytes with a gyro & acc to be able to use a smaller proc.

what do you think?



some things that may be reviewed to save size: (i know the most of us will know it ..)
- a if(){}else if(){} is sometimes smaller than a swicht/case or seperate ifs (eaven if it saves just 20bytes)
- check every 16, 32 or 64 bit variable of your code if thay are really need to be that big
- trie to use bitshift instead of / or *
bitshift:



ill trie to check and do as much of it as i can

regards

felix

stable sinking flight
corrections thru sensors while Thottle at minimum, switchable flexible like e.g. sensors in GUI

There's no need to specialcase this. Fast ESC solves rapid descent wobbles. "Idle" throttle shouldn't be screwed with, that is time when sensors should NOT be affecting the model.

More support for dongs (timecop's) STM32 Port (It's the future), maybe we could talk him into a sending Alex an AfroFlight (Naze) 32 for development?

I have no problem sending alex 1 or 2 or 3 or whatever hardwares, the problem is: poor guy edits code in arduino IDE. I don't really think he's ready for the shock that is 'normal' software development.

Hi Felix,
I am not in favor of optimizing for even smaller cpu. We are close to going 32 bit arent we?
But I like your idea about the yaw servo center from eeprom only if lcd is configured in. ThaT could help to avoid confusion.

Hi Hamburger,

Hamburger wrote:We are close to going 32 bit arent we?

it seems to be inevitable... as we all know dongs did that step and i think its the right way for autonomous flying copter with all possible features.
but how and when will we do it? dongs MWC port seems to work well and the hardware he uses is cheap....
so why do we still use this relatively expensive and slow 8 bit proc's?

i think the reason is thair simpleness and arduino.
eaven if arduino has the 32bit arduino due available.. i dont think we can support a 32bit proc with a 100% different architecture in one MWC version.
im almost sure that we need to split it then...

i personaly like multiwii as it was/is. i fly 99% in acro 1% in stablemode ;P so i dont need all the features .. well its funny to see how things can fly autonomous.

..for me the 8bit proc's are more then enough.. and i think if we or some of us want to keep it also on this 8bit things we need to take focus on the basics of a multirotor FC.

regrads Felix

Arduino Due is still not released yet right?

Well I was thinking to make my own 32bit FC too.. But after all.. People can complain about 8bit or 32bit..
But in my opinion after all..

Arduino is a good platform.. supports many things.. will keep on upgrading and for a flightcontroller it doesn't really restrict anything.. I think we should just stay at 8bit

We could just rewrite the code to use it outside the arduino IDE.. and compile it to a .hex file & make multiwii types (multiwii acro, multiwii stable, multiwii fpv) for saving bytes

Jesse

the limit is not so much in the copter type (TRI, QUADP, ...) but in the large set of supported sensors and combinations. You just cannoit fit the code for all of these into an arduino.

Here's a really simple feature request.

A button in the GUI to reset default PIDs. I'm doing a lot of messing around with different IMUs and sensor configurations and it would make like easier if I could return to defaults with one click.

Your prayers have been heard before you said them.
It is already implemented in the dev version.

Is there a timeframe/feature completion set for the 2.1 release. Looks like functioning GPS will be finished soon which is a bit of a milestone.

summary in post #2 updated.

"small mod to servo tilt function"
viewtopic.php?f=7&t=1507

VERY GOOD MOD !

convert GYRO_SMOOTHING into LCDmenu configurable items, store in eeprom - status: done.

I'd like to tiny-gps merged into the latest devs.