wishlist for v2.2 - CLOSED

Hamburger · Post by **Hamburger** » Mon Jul 16, 2012 5:37 pm

same old story:

well. v2.1 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.

Hamburger · Post by **Hamburger** » Mon Jul 16, 2012 5:37 pm

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

this list is closed now - v2.2 development is on feature freeze - release is imminent

integrated in Alex' dev version and/or intermediate pre-release

level is now both ang and horizon modes
more tunable params (marked with '*' in config.h)
another compile case defined (COPTERTEST 5)
for baro, new define SUPPRESS_BARO_ALTHOLD to use baro for alt measurement only but not for althold
auto baudrate switch and complete init of UBLOX gps modules
change LED blink frequency for acc-uncalibrated or tilt>25 from 50ms to 10ms
LCD/OLED telemetry: layout reformatting
load first step of telemetry_step sequence during lcd.init() -no user interaction neccessary to run telemetry info upon startup
optional defines to override automatic pin assignments
-separate uart handling for promicro and MEGA boards:
new AP FlightMode, Acrotrainer
unified alarm handling
Sport flying mode with stabilisation - now called horizon mode
optional fixate time interval for PID calculations
HexaH (shikra, PatrikE)
baro&mag code overhaul (mahowik et.al.)
task switching overhaul (Sebbi et.al.)
failsafe for normal rx monitors 4 channels, not just 1 (mis)
more tunable setings; configurable via Arduino IDE's serial monitor now
set individual board name string
MWC->GUI transmits #RC_CHANS channel data instead of fixed 8
ground course and variometer info
GUI: virtual horizon
3 sets of configuration in eeprom, user selectable via Stick combos
spektrum 12 channel
eeprom sanity checking (especially useful after recompilation with different feature set)
LCDconfig menu: with THROTTLE=High, increment is 10 times of normal
optional fixate cycle time (by burning cpu time away)
optional Repeat the Gyrocalibration if the copter is moved in the process of calibration
LEVEL_PDF removed
variometer (acoustic feedback on rise/fall velocity)
optional permanent logging to eeprom
reworked alarms handling
optional spektrum bind support
GPS waypoint in the works
optional service alert for accumulated flight times threshold
GUI: reconnect to last used comport
optional remove MSP support from MWC for extreme memory saving
re-initialize OLED to allow hot-plug (not safe with i2c but works)
New MultiWiiSerialProtocol MSP between MWC and GUI
GUI: RSSI state info
sensor orientation can be enforced for all boards from config.h
servos are moved to neutral position during calibration and lcd.configuration
perfect euler angle computation in case of 9DOF (better heading)
allow override of motor/servo mixing from config.h - no need to edit Output.ino
allow choice of serial port for LCD to run LCD and GUI simultaneously
new default PID settings
more sensors and boards
uncounted enhancements & code tuning
faster cycle time than 2.1

implementation submitted to *_shared

ideas MCU

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
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)
slew mode in the gimbal control stabilization
change PID controller based on gyro+acc for yaw to become a crisp, steady HeadingHold controller (at least as good as traditional good Heli gyro
smooth transition between two (or more) different configurations (V-22 style)
collision avoidance (via sonar?)
add failsafe to passthru mode
GPS Geofence boxing
PIDs independant of cylce time (done with fixated cycle time option?)
Graupner digital signal SUMD 115200 Baud. with MX-16 HoTT and GR-16
CAMSTAB pitch and roll input channel adjustable
data logging for the boards those have flash chip (aiop2 for now)
GPS: allow arming only if fix
Advanced headfree mode
sonar: support more sensors (trig/echo)

ideas GUI

GUI so it reports the full MWC firmware version number, INCLUDING the patch level
GUI baudrate as configurable setting
GUI advanced tab for more 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

Tommie · Post by **Tommie** » Mon Jul 16, 2012 5:50 pm

Configurable number of AUX channels with a configurable number of steps.
Patch is already available: https://github.com/wertarbyte/multiwii- ... x_channels
GUI: https://github.com/wertarbyte/multiwii- ... x_channels

Tommie · Post by **Tommie** » Mon Jul 16, 2012 5:52 pm

Transmit debug messages from copter to GUI.
Patch is already available: https://github.com/wertarbyte/multiwii- ... 08832afd6e

PatrikE · Post by **PatrikE** » Mon Jul 16, 2012 6:31 pm

Configurable servosettings from Gui?

chris ables · Post by **chris ables** » Mon Jul 16, 2012 7:24 pm

Glad to see my wish for gui - tunable esc refresh rate ! Come on code writers this can be done but i dont know how to write code ! Anyway glad to see it there !

jy0933 · Post by **jy0933** » Mon Jul 16, 2012 8:20 pm

this might sound dumb.. a calib gyro button in gui(or set it to calibrate along with acc)?

Sebbi · Post by **Sebbi** » Tue Jul 17, 2012 12:01 am

my wishes:

a velocity vector from the accelrometer (and sensor fusion with gps, baro, sonar, optical flow) to facilitate new modes (descent/ascent with constant speed, position hold without gps) and/or improve existing flight modes (position hold/altitude hold) viewtopic.php?f=7&t=2015
#defines that enable super accurate calculation of imu values (no small angle approximation, using quaternions, floats and correct formulas, has anyone even tried that before on a 328?) ... this will be slower and will need more flash, so it's probably not for everyone
someone should take a look at the scale factor for the gyros. It is the wrong value at least for the popular mpu6050. The comments next to the current value suggest that it was experimentally derived ... are the formulas using it correct then?
move to git (Github prefered) viewtopic.php?f=8&t=825

I very much like the idea of using constant time intervals instead of "as fast as possible". It should make PID values more predictable. Recording of the GUI values (graphs) would be a fantastic feature, too (debugging testflights). Having a nice Android version by some who knows what he/she is doing would be nice, too ... no offense ;-)

It could even be a multiwii emulator as most phones/tablets have the same sensors as our copters ;-)

jevermeister · Post by **jevermeister** » Tue Jul 17, 2012 8:15 am

- Support for Pilotlight (I am on it)

- Pausing of GPS RTH or PH while doing a stick input

PatrikE · Post by **PatrikE** » Tue Jul 17, 2012 11:07 am

jevermeister wrote:- Pausing of GPS RTH or PH while doing a stick input

Or change PH to current after stick input.
Aka Adjust the pos.

Sebbi · Post by **Sebbi** » Tue Jul 17, 2012 11:44 am

Regarding constant timing intervals for sensor reading and PID calculations ... Arducopter seems to be a good example of doing this right. Main sensors and calculations run with 100 Hz and some slower sensors (mag/gps) run with lower frequency. They still have a very stable level mode / position hold, even in windy conditions:

http://www.youtube.com/watch?v=AD3KVra6RrA

Bledi · Post by **Bledi** » Wed Jul 18, 2012 10:11 am

don't forget the excellent accro trainer mode (flip and loops on stable mode) : viewtopic.php?f=16&t=1944
and the VTAIL modes : viewtopic.php?f=8&t=2033&start=10#p18663

dr.tom · Post by **dr.tom** » Wed Jul 18, 2012 8:20 pm

on flying wing and aeroplane mode:
-Camerastab (tried it at wing config, it doesn't output)
-GPS functions like on multirotor (but with defined circling PosHold obviously)
it could maybe be ported from APM , they have aeroplane and wing with gps functions,
same has been done for multirotor already, successfuly by EosBandi 8-)

if possible it would be great

thank you all great people 4 making it work

cardboard · Post by **cardboard** » Thu Jul 19, 2012 3:24 am

dr.tom wrote:on flying wing and aeroplane mode:
-Camerastab (tried it at wing config, it doesn't output)
-GPS functions like on multirotor (but with defined circling PosHold obviously)
it could maybe be ported from APM , they have aeroplane and wing with gps functions,
same has been done for multirotor already, successfuly by EosBandi

if possible it would be great
thank you all great people 4 making it work

Adding to that aircraft mode making failsafe work under all flying modes.
If your in bypass mode and you turn off your Tx level mode wont active. The motor will turn off after the set period but no auto level.
I tweaked the code so even in when I'm in bypass mode and failsafe activates it will go into level mode.

As a side note I also trimmed level mode so the aircraft enters a wide continuous left bank, kinda like dumb loiter mode.

Looking forward to full GPS support for aircraft mode though

palton · Post by **palton** » Thu Jul 19, 2012 11:30 pm

I would like:

- flow + sonar sensors integrated and fully working.
- Tommie AUX stuff, with multiple (many, like a 6 pos switch) threasholds per channel but also more possible channels.
- Geofence, looks pretty nice as well. http://diydrones.com/profiles/blogs/geo-fencing-for-arducopter-keep-your-copter-fenced-in. even if it was in some simple form where one just save the positions while flying..

Alexinparis · Post by **Alexinparis** » Thu Jul 19, 2012 11:46 pm

Hi,

Sebbi wrote:[*] #defines that enable super accurate calculation of imu values (no small angle approximation, using quaternions, floats and correct formulas, has anyone even tried that before on a 328?) ... this will be slower and will need more flash, so it's probably not for everyone

I think it's a good idea for "academic" purpose, or for stronger procs.
Some days ago, I tried your quaternion implementation but something seems to be wrong (movements are quite slow in the 3D gui representation)

Sebbi wrote:[*] someone should take a look at the scale factor for the gyros. It is the wrong value at least for the popular mpu6050. The comments next to the current value suggest that it was experimentally derived ... are the formulas using it correct then?

To be more accurate, GYRO_SCALE should be defined for each gyro, not in IMU part.

I very much like the idea of using constant time intervals instead of "as fast as possible". It should make PID values more predictable.

As you say it *should*.
But if you do some empirical tests flight, you will see that some approximations or delay variations won't affect really the stability.
Everyone should understand the soft is "flight oriented" and based on some empirical hits, leading some times to surprising conclusions and code oddities.
+ the fact it's based initially on a limited perf proc.
For instance:
Empirically, an average loop time at around 3ms gives very good results.
6ms is still ok but not as good. Too low delays (bellow 2ms) are not the so good also.
I suppose it would be very difficult to understand via formulas exactly why.

Sebbi · Post by **Sebbi** » Fri Jul 20, 2012 12:24 am

Hi Alex,

good points. But what I mean with "more predictable" PIDs and constant time intervals is 1) PIDs which don't depend too much on motor thrust and model weight would become comparable between models/users 2) it is easier to simulate/imagine what changes to certain PID values might do while variable timing makes that a little bit more guess work (as you wrote: 3ms is good, below 2 ms or above 6 ms is not so good)

btw: ArduCopter has a fixed loop time of 10 ms and seems to be able to fly ;-)

copterrichie · Post by **copterrichie** » Fri Jul 20, 2012 1:21 am

I hope I am able to explain this, what I would like to see in in the next release is, the ACC remain on full time with an option to change the weight given to the ACC. What I mean by this is, people seems to be having the most problems when attempting to switch modes in midair. I have noted with my copters during takeoff, until the copters are airborne, they will rock from side to side. I think when people activate the ACC midair, there is some origination problem but I am not sure. With the ACC on full-time, this may eliminate this issue. I understand ground turbulence and this is not related. I personally fly with the ACC on full-time because my copters are mainly designed for aerial video but there are times when I need less influence from the ACC than others. So I guess this would be similar to is a High and Low Rate mode for the ACC verse On and Off.

Thank you.

fr3d · Post by **fr3d** » Thu Jul 26, 2012 3:19 pm

my ideas :
parametable values for :

vbat and vbatlevel123,
minthrottle,
mincommand,
maxthrottle,
for tri,plane and gimbal min/max servo travel and neutral point.
a way to check vibrations on mwconf for each motor, maybe the sum of all gyro should be a good idea ?

to be followed

itain · Post by **itain** » Thu Jul 26, 2012 9:34 pm

Given two points and a radius (points can be at the same location for a circle). Positive radius=left turns, negative=right turns (or the other way).
+ Implement also for fixed wing aircraft (with some minimal, radius)
+ Rotor type aircraft could maintain "Look Forward", "Look at point" etc... heading. (Useful for photography).

itain · Post by **itain** » Thu Jul 26, 2012 10:14 pm

The V22 is only one example of what could be done... The idea is to be able to smoothly switch between two (or more) different configurations while in stable flight mode.

captaingeek · Post by **captaingeek** » Fri Jul 27, 2012 12:13 am

Pure wish but a working ESC calibration and programming feature. So I can easily program the ESC's in an octocopter without having to monkey around with the cables.

sismeiro · Post by **sismeiro** » Fri Jul 27, 2012 7:16 pm

Hi to all,

captaingeek wrote:Pure wish but a working ESC calibration and programming feature. So I can easily program the ESC's in an octocopter without having to monkey around with the cables.

Why don't someone develop a firmware program just for calibrating and programming the ESCs outside the MultiWii code? Since we have to upload firmware do to the calibration and again comment the config.h to upload the flying firmware the effort is the same.

I think MultiWii should be the best possible SW doing what it does best, being a multipurpose flight firmware. Things like calibrating ESCs don't have nothing to do with flying the multicopter, helicopters or wings and should be removed from the main code. I think this is my wish for 2.2.

And there are better devices to calibrate and configure the ESCs and aren't that expensive.

Regards,
Luis Sismeiro

copterrichie · Post by **copterrichie** » Fri Jul 27, 2012 11:01 pm

sismeiro wrote:Hi to all,

Why don't someone develop a firmware program just for calibrating and programming the ESCs outside the MultiWii code? Since we have to upload firmware do to the calibration and again comment the config.h to upload the flying firmware the effort is the same.

I think MultiWii should be the best possible SW doing what it does best, being a multipurpose flight firmware. Things like calibrating ESCs don't have nothing to do with flying the multicopter, helicopters or wings and should be removed from the main code. I think this is my wish for 2.2.

And there are better devices to calibrate and configure the ESCs and aren't that expensive.

Regards,
Luis Sismeiro

AMEN, AMEN and another AMEN!

FYI, it does not happens every time however, I have seen a few of my pro-minis reboot when connecting the FTDI. I THINK this is where the false sense of safety enters the picture, the Pro-mini (my pro-minis) does not reboot each time the FTDI is connected, but will at random reboot. Considering there is power to the ESC for calibration then connecting the FTDI is a potential cause for alarm. I personally, say, take the time and do things right, remove props at the very minimum!

copterrichie · Post by **copterrichie** » Fri Jul 27, 2012 11:04 pm

copterrichie wrote:
sismeiro wrote:Hi to all,

Why don't someone develop a firmware program just for calibrating and programming the ESCs outside the MultiWii code? Since we have to upload firmware do to the calibration and again comment the config.h to upload the flying firmware the effort is the same.

I think MultiWii should be the best possible SW doing what it does best, being a multipurpose flight firmware. Things like calibrating ESCs don't have nothing to do with flying the multicopter, helicopters or wings and should be removed from the main code. I think this is my wish for 2.2.

And there are better devices to calibrate and configure the ESCs and aren't that expensive.

Regards,
Luis Sismeiro

AMEN, AMEN and another AMEN!

FYI, it does not happens every time however, I have seen a few of my pro-minis reboot when connecting the FTDI. I THINK this is where the false sense of safety enters the picture, the Pro-mini (my pro-minis) does not reboot each time the FTDI is connected, but will at random reboot. Considering there is power to the ESC for calibration then connecting the FTDI is a potential cause for alarm. I personally, say, take the time and do things right, remove props at the very minimum! Also Note: Once I have calibrated my ESCs, I have NEVER had to recalibrate them. period.

cGiesen · Post by **cGiesen** » Tue Jul 31, 2012 6:43 pm

I would be happy, when there is a link to the right wiki page for all settings in config.h

gompf-2 · Post by **gompf-2** » Wed Aug 01, 2012 8:56 pm

copterrichie wrote:I have seen a few of my pro-minis reboot when connecting the FTDI

I only have this if I connect usb after rs232 or the copter wasn´t grounded to the PC before connecting RS232. In my opinion calib code works as expected, at least in my setups. You can always take some additional "hardware interlocks" (eg ~5ohms in VBat, very small batt/wall wart that can´t handle full throttle current ..., I limited lab PSU) or remove the props.

Wish: Parameters to change PID-MIX via GUI if possible without a much bigger cycle time, for testing odd setups (different vtail angles, non symetrical arms etc).

Regards.
gompf

chris ables · Post by **chris ables** » Thu Aug 02, 2012 3:59 pm

Im seeing alot of newbies adjusting the pitch and roll pid's for the acc ! I think that the level on the gui needs to be changed to say ACC instead of saying LEVEL ! If im wrong someone please correct me but the pitch and roll pid's are for gyros and the level pid's is for ACC , right? Just a thought and it would help people understand setting pid's better !

palton · Post by **palton** » Sat Aug 04, 2012 9:36 pm

itain wrote:The V22 is only one example of what could be done... The idea is to be able to smoothly switch between two (or more) different configurations while in stable flight mode.

This would be really coool! :=)

jy0933 · Post by **jy0933** » Wed Aug 08, 2012 12:29 am

just btw.... probably give a fix on this fail too

cGiesen · Post by **cGiesen** » Wed Aug 08, 2012 7:46 am

jy0933 wrote:just btw.... probably give a fix on this fail too

I never see this befor.
For me it works fine!

jy0933 · Post by **jy0933** » Fri Aug 10, 2012 12:55 am

and one more thing for wishlist..

im not sure if other people has similar problem but i think it is worth to add

background.. my er9x the stick reading around center jumps around from 1495~1505.. so i set deadband 20 so that 1490~1510 are consider 1500

then i found when i tune the quad, i still need to trim roll/pitch to keep it close perfect level(acro mode, thus gyro only).. then i found it is impossible to trim tx for this when dead band is set..

so i wonder if there is possible to give a block for stick center offset for trimming?

( just btw... am I doing wrong? since im not good at pid tunning.. i only did the basic tuning so that it does not oscillate at a good P. and left I/D default.. then trim it to perfect at acro mode... and then based on this to trim acc.... but eventually i will have auto level on all the time..)

Sebbi · Post by **Sebbi** » Mon Aug 13, 2012 2:48 pm

Thats a problem of the unmodified Turnigy (at least mine had the problem too). Stick values jumping when stick is center. I replaced the default TX module with a FrSky one ... since then I had no problem with the stick values jumping.

And yes, trimming the TX with a deadband set is not really possible ...

jy0933 · Post by **jy0933** » Mon Aug 13, 2012 5:49 pm

i actually have changed the radio to frsky.. but the jumping has nothing to do with the radio.. just the sticks

arkcom · Post by **arkcom** » Sun Aug 19, 2012 10:42 am

How about sliding deadband? Average the stick position while within the deadband, and make that the center.

crono · Post by **crono** » Mon Aug 20, 2012 12:44 pm

remzibi osd please

Alexinparis · Post by **Alexinparis** » Tue Aug 21, 2012 10:11 am

crono wrote:remzibi osd please

It's up to remzibi.
Please read and understand the 2.1 release note and things about MSP evolution.

scanman · Post by **scanman** » Tue Aug 21, 2012 11:24 am

does "sonar" in all of these post just mean "altitude" ? If so can I add "collision avoidance" to the wish list?
I need to fly within 20cm of a wall without crashing into it.

Hamburger · Post by **Hamburger** » Mon Aug 27, 2012 6:26 pm

summary updated viewtopic.php?f=7&t=2077&p=18946#p18946.

Hamburger · Post by **Hamburger** » Tue Aug 28, 2012 10:45 am

block dangerous GUI commands while armed (eeprom write etc.) - found out by crashlander the hard way.

scanman · Post by **scanman** » Tue Aug 28, 2012 1:01 pm

Looping switch:
I got this idea for a feature, because using V2.1 I have noticed an alarming bug that occasionally happens: Both motors on one side stop dead, and the motors on the other side go full power. The result is about 3 spectacular High speed loops within about 1m altitude. The quad normally crashes afterwards!

Why not integrate this as a feature: flick a momentary switch on your transmitter and the quad can do crazy loops. release the switch and it returns stable!
We can call it the #WARTOX option!

alexia · Post by **alexia** » Fri Aug 31, 2012 10:03 am

THE MOST IMPORTANT thing for me is to only improve baro mode and gps! other thing are great!
i wouldn t see multiwii like arducopter...so many news features which doesn t work well...we have to working on features which are already here!!!!!! i am so sad to see on the forum, already news fonction for multiwii and not imrpovement for most important things like baro.....i think is not the spirit of multiwii to have so many features like waypoint...
but a good baro mode,stable , accro and basic gps fonction will be the best thing we could have(accro and stable are already good now)

flyman777 · Post by **flyman777** » Fri Aug 31, 2012 10:48 am

I agree entirely with Alexia.
It's now important to improve the baro mode and GPS.
Don't waste your time with LED blinking and so on.
The basis must be clean and safe with simply settings before charging uselessly the config.h with so much options.
Remember, the origin of MWC was an arduino 328 and it is as good as on its memory and fonctionality boudaries.

Sans rancune
Regards
Claude

LenzGr · Post by **LenzGr** » Fri Aug 31, 2012 11:46 am

scanman wrote:Why not integrate this as a feature: flick a momentary switch on your transmitter and the quad can do crazy loops. release the switch and it returns stable!
We can call it the #WARTOX option!

Something like this is actually exists and it's merged already: AcroTrainer Mode

Hamburger · Post by **Hamburger** » Fri Aug 31, 2012 1:05 pm

flyman777 wrote:IDon't waste your time with LED blinking and so on.

Fortunately not yours to decide what others spend their time on.

You and others have made your point, you want alt.hold. Question is, what are you willing to do to make it happen?
Why not stop the useless rant and start programming your baro stuff?

Hamburger · Post by **Hamburger** » Fri Aug 31, 2012 1:07 pm

alexia wrote:THE MOST IMPORTANT thing for me is to only improve baro mode and gps! other thing are great!
i wouldn t see multiwii like arducopter...so many news features which doesn t work well...we have to working on features which are already here!!!!!! i am so sad to see on the forum, already news fonction for multiwii and not imrpovement for most important things like baro.....i think is not the spirit of multiwii to have so many features like waypoint...

you are entitled to your own view. So are others.
Running another petition will not get you anywhere.
Save the speeches, start programming your baro stuff.

Termic1 · Post by **Termic1** » Fri Aug 31, 2012 1:18 pm

As long as BARO ALT Hold function is so weak I think it is useless to develop new functions (like waypoints or other). ACRO and LEVEL mode are great. CAREFREE is working fine. I love GPS Hold and RTH functions, they are really impressive ... but without a solid ALT Hold you can't do a real and secure Hold or RTH autonomous flight.

In my personal wishlist I have ALT Hold improvement as priority 1.

As priority 2 I'd like to have a minimum altitude during RTH - Multicopter should raise to a predefined altitude before returning home in order to avoid obstacles.

Luciano

NB
Of course this is my personal point of view. As I'm not a programmer I'm not able to collaborate to this project writing code. I can only propose my wishlist priorities and contribute to the project with ideas...and with some donation...

alexia · Post by **alexia** » Fri Aug 31, 2012 5:22 pm

Termic1 wrote:As long as BARO ALT Hold function is so weak I think it is useless to develop new functions (like waypoints or other). ACRO and LEVEL mode are great. CAREFREE is working fine. I love GPS Hold and RTH functions, they are really impressive ... but without a solid ALT Hold you can't do a real and secure Hold or RTH autonomous flight.

In my personal wishlist I have ALT Hold improvement as priority 1.

As priority 2 I'd like to have a minimum altitude during RTH - Multicopter should raise to a predefined altitude before returning home in order to avoid obstacles.

Luciano

NB
Of course this is my personal point of view. As I'm not a programmer I'm not able to collaborate to this project writing code. I can only propose my wishlist priorities and contribute to the project with ideas...and with some donation...

+1

so hamburger like you can see it s not only one person...and it s a wish list so we can say what we want to see..i don t undertand why you attack so many people who are not agree with you..(on rcgroup it s the same thing)

yes i am not a coder and i would like to have more competence about programmation but it s not the case..but you,could you surgering a person in my place?everybody has a different job and we are not rock in programmation or not the time

Magnetron · Post by **Magnetron** » Fri Aug 31, 2012 5:56 pm

I will try again on baro alt position hold with a new concept and a new routine based on the data becomes from accs, if someone could help with test...

jevermeister · Post by **jevermeister** » Fri Aug 31, 2012 7:11 pm

flyman777 wrote:Don't waste your time with LED blinking and so on.

Oh that is very nice that you consider my spent time on the LED and buzzer code as "wasted".
My work was to improve a function that is already there, just as you wanted.
I wanted to give something to the mwc community and stated with something I understand. I am not good enough to code GPS but good enough to code LED and Buzzer.

It is a shame that people like you do nothing and try to force other people in doing in their willing?

Go and buy yourself a fancy 6000$ Mikrokopter if you want everything working or grab your gear and programm it yourself.
You know, there are people that are enyoing acromode and need a good warning pattern and blinking stuff.

And now I use your words: They do not need fancy gps stuff.

My consequence is this:

I will use my code for myself and will not share it anymore, I will not share my knowledge with leechers that want a multicopter for commercial use without paying anything - not even respect and don't give a f**k about the work of other people.

Nils