wishlist for the next version (or the one after)

[Hamburger]

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

Please keep in mind this is a wishlist - not an order form. Chances are, reasonable wishes get picked up by developers, but no guarantees.

integrated in intermediate pre-release

implementation submitted to *_shared

ideas FC

• 3 warning levels for power consumption (same as with voltage)
• RC rate adjustment for stable mode
• Tricopter servo; consider not moving the servo until after armed and control returned to center
• Something to show the stable trim
• 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.
• 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)
• 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
• HC-SR04 Sonar support via secondary GPS Arduino I2C
• slew mode in the gimbal control stabilization
• smooth transition between two (or more) different configurations (V-22 style)
• collision avoidance (via sonar?)
• add failsafe to passthru mode
• GPS Geofence boxing
• baro altitude fencing
• PIDs independant of cylce time
• Graupner digital signal SUMD 115200 Baud. with MX-16 HoTT and GR-16
• CAMSTAB pitch and roll input channel adjustable
• GPS: allow arming only if fix
• Advanced headfree mode
• sonar: support more sensors (trig/echo)
• Save and load the AUX-Settings too from/to GUI from/to .mwi-file
• toggle features via rc.serial
• smooth transition between modes
• tx-switchable configuration sets during flight
• Constant climb/decend mode for camera work
• PID tuning together with the Ziegler-Nichols method on a Aux pot. viewtopic.php?f=7&t=1701&start=30#p37557
• multiple Spektrum Satellite Support w. diversity
• Charlieplexing for (AUX) Led Pins ??
• transition between coptertypes (bicopter to airplane)
• Sonar/Baro sensor fusion
• Failsafe descent rate based on barometric pressure sensor based rate of descent rather than preset min throttle + set value.
• keep track of GPS-Pos if RC-Signal is good, set this as CH-Pos in Case of loss of RC-Signal (Failsave) and activate CH to back RC-Signal
  
  

ideas GUI

• GUI so it reports the full MWC firmware version number, INCLUDING the patch level
• Record flight data and replay for analyzing after flying
• sliders for some more values
• port to android
• emulator for TX/RX input via GUI for testing
• tunable esc refresh rate
• GPS update rate
• map

[Hamburger]

+ TRI3 - tricopter with 3 individual servos for semi-transitioning into forward flight
+ voltage monitoring for individual cells at the balancer plug; upto 6S
+ use the copter's pitch angle to mix yaw input into roll output accordingly (beginner mode, or fpv?)

[copterrichie]

You really put some real thought into this list. If most of these features are implemented, MWC will rival any FC out there.

[Hamburger]

too much praise, I am (not) sorry to say. All I did was collecting ideas and thoughts from other forum users , only omitting what I considered completely inadequate.

[fuh]

+Move code to Github.
+Proper working GPS POSHOLD filtered by the ACC/GYRO.

[Hamburger]

+Proper working GPS POSHOLD filtered by the ACC/GYRO.

What exactly do you have in mind? Care to explain or post a link to corresponding discussion maybe?

[fuh]

The latest thread was the one discussing why development stopped (I'm on tapatalk not easy copy/paste links to threads). But in a nutshell flip the switch and mw should stick at that point within a minimal error margin, this is a must have for a proper video platform.

[nebbian]

ideas FC

• Tricopter servo; consider not moving the servo until after armed and control returned to center
  

I've done this for my tricopter, after getting annoyed that the tail prop kept hitting the ground when arming and disarming. Note that this code stops the tail servo moving when the throttle stick is at zero, even if armed. This is because you don't want the tail prop hitting the ground when you disarm after a flight.

In output.cpp, change this line:

Code: Select all

    servo[5] = (SERVODIR(5, 1) * axisPID[YAW]) + get_middle(5); //REAR

to this:

Code: Select all

   if((rcCommand[THROTTLE] > conf.minthrottle) && f.ARMED){
       servo[5] = (SERVODIR(5, 1) * axisPID[YAW]) + get_middle(5); //REAR
    } else {
       servo[5] = get_middle(5); // There's no point vectoring thrust if there is no thrust to vector.
    }

I'd like to submit this somewhere, perhaps using a pull request on github. But I think that the main branch isn't using github? This really needs to happen... I'm a keen developer with decades of experience, happy to submit changes like this for approval. Github would make this really easy to manage.

[Hamburger]

servo[5] = get_middle(5); // There's no point vectoring thrust if there is no thrust to vector.

I guess that would be a matter of taste. I for one want to see correct servo movement whenever I move the stick. Seems like no single implementation suits all needs.

[nebbian]

ideas FC

• Tricopter servo; consider not moving the servo until after armed and control returned to center

I guess that would be a matter of taste. I for one want to see correct servo movement whenever I move the stick. Seems like no single implementation suits all needs.

I must admit that I don't understand what you want... You posted something in the wishlist, and then said that you don't actually want it implemented?

[fuh]

+ visual config.h generator

Hambúrguer will you update your first topic with other person's suggestions or it's only your whishlist ?

[Hamburger]

All I did was collecting ideas and thoughts from other forum users , only omitting what I considered completely inadequate.

Post 1 gets updated every so often.

[Hamburger]

I must admit that I don't understand what you want... You posted something in the wishlist, and then said that you don't actually want it implemented?

Sorry for the confusion.
The wishlist is a compilation of users wishes. I do not neccessarily share each and every one. In your case I commented from my personal point of view and describe why I do not share your position and why this feature should be optional if implemented.

[mikegiver]

Hi everybody

In two crashes, the arm of my tricoptere disassociated itself from the structure and impossible to stop the engines, the 1st, the receiver antenna was cuted and I had to disconnect the battery with all the risks that entails for the fingers .
Could we implement an Safety Tiggers Impact Sensor to DISARM on impact of 3G,5G or 8G or Off (option configurable in config.h) similar to what exists with Megapirate_X card (megapiratex.com english doc)

[Hamburger]

Sounds convincing to me. It is now on my ever growing list

[c128]

32bit mbed version

https://developer.mbed.org/platforms/mbed-LPC1768/