wishlist for v2.3

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

wishlist for v2.3

Post by Hamburger »

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

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 Alex' dev version and/or intermediate pre-release


implementation submitted to *_shared
  • tuning of Althold adjustment with sticks (viewtopic.php?f=8&t=4058)
  • SBUS center define (viewtopic.php?f=8&t=3957)
  • FAILSAFE_DETECT_TRESHOLD configurable
  • MY_PRIVATE_DEFAULTS (viewtopic.php?f=8&t=3987)
  • magHold is reset when arm is switched on (viewtopic.php?f=8&t=3910)
  • no RC averaging for Spektrum & SBUS
  • transmit amperage to GUI
  • default yaw Stick sensitivity /2
  • files migration to .h .cpp
  • turnkey Eclipse workspace
  • GUI servosettings pane
  • GUI globalsettings pane
  • reworked PID controller
  • hardware PWM servo support with variable refresh rate for mega2560 !!! some pin assignment changes !!!
  • partial hardware PWM servo support for m32u4 (only helicopters tested) with separate tuning of PWM rates !!! some pin assignment changes !!!
  • no more than one MSP per port and per cycle
  • max GPS speed for telemetry
  • config: new section for deprecated functionality (d12 power is first item)
  • Waypoint storage done - no functional WP navigation yet
  • DEBUG_FREE to display free ram at runtime
  • GYRO_SCALE repaired
  • various optimizations, new boards and displays
  • general servo handler
  • new powermeter computation
  • config.menu: when abort, revert all values back to last saved state
  • flash.check automatically detects new MWii firmware onboard and resets PIDs
  • visual feedback from servos during midpoint trim via LCD
  • no servo update during unarmed calibration of sensors which are sensitive to vibration
  • Avoid problems with RC configuration if failsafe is enabled. Problem is described in viewtopic.php?f=8&t=3400
  • VibrationTest And GUI pane
  • remove CYCLETIME_FIXATED, LEAVE_HEADROOM for private mixing
  • round-robin analog channel reading for battery voltage, current sensor and rssi voltage
  • OVERRIDE_* options in config.h for various preset pins
  • new Advanced Headfree mode
  • package now comes with defaults file to load via GUI
  • tune PID algorithm for stable sinking flight
  • 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
  • data logging for the boards those have flash chip - partially for uptime, failsafe conditions etc.
  • GUI baudrate as configurable setting
  • GUI advanced tab for more user configurable items


ideas MCU
  • 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 arter 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
Last edited by Hamburger on Fri Sep 20, 2013 6:16 pm, edited 3 times in total.

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

Re: wishlist for v2.3

Post by Hamburger »

+ optional memory saving (for m32u4 etc.): remove defaults for gui-tunable params from MWC code - load from defaults.mwi file via GUI instead

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

Re: wishlist for v2.3

Post by Hamburger »

+ select eeprom config set during flight via auxN - like flight modes switching in most computerized TX

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

Re: wishlist for v2.3

Post by copterrichie »

If one is using a Mega2560, Why not back Port Baseflight's CLI?

doppler
Posts: 64
Joined: Wed Sep 26, 2012 1:35 pm

Re: wishlist for v2.3

Post by doppler »

copterrichie wrote:If one is using a Mega2560, Why not back Port Baseflight's CLI?


+1

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: wishlist for v2.3

Post by Sebbi »

Protocols/telemetry seem to be a big thing on the wishlist. Maybe it should be programmed in a way so MultiWii allows different protocols and telemetry options to be compiled in. MSP or Mavlink or LCD-Terminal-thingy or CLI for bidirectional communication. HoTT and FrSky (or maybe even MSP over FrSky backlink) for one way telemetry. Interchangeable via config-parameters ;-)

GPS seems to be another big point for improvements.

If those two things get done (and I like to help) in 2.3 I'd be happy ;-)

User avatar
NikTheGreek
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece
Contact:

Re: wishlist for v2.3

Post by NikTheGreek »

Probably a medium to read/store data like SD Card Reader should be implemented.
Imagine that ALL PIDs are stored in this medium and through GUI you are able to change and store them.
Also Way Points can be stored this way . ;)

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

Re: wishlist for v2.3

Post by copterrichie »

Too bad we can not implement a Dynamic-Link Library, that would give new life to the 328 equipped with an SD Card Reader and an I2C-to PWM Converter. Hmmm.

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: wishlist for v2.3

Post by QuadBow »

Sebbi wrote:Protocols/telemetry seem to be a big thing on the wishlist. Maybe it should be programmed in a way so MultiWii allows different protocols and telemetry options to be compiled in. MSP or Mavlink or LCD-Terminal-thingy or CLI for bidirectional communication. HoTT and FrSky (or maybe even MSP over FrSky backlink) for one way telemetry. Interchangeable via config-parameters ;-)


I support this idea. A new file named telemetry.ino or similiar could take all the related code for the different protocols.
I am using the Frsky protocol introduced to this forum last year viewtopic.php?f=7&t=1929&p=31338&hilit=Frsky#p31338 and it is running well for my configuration with some modifications. So, at least the Frsky port seems to be mature enough for inclusion in the official part.

Hamburger wrote:Autopilot with GPS waypoint and Return to home support.

Also this is a very nice idea that should be continued, since other software developments have it already included.

And now to another point:
I think the variety of required pid parameters is too wide to provide only one set for a standard copter, which will fail, if the copter is too small or too heavy, if the pwm resolution is too good or whatever...
What about a better support by different parameter sets for different copter types?

tj_style
Posts: 12
Joined: Mon Aug 27, 2012 5:31 pm

Re: wishlist for v2.3

Post by tj_style »

copterrichie wrote:If one is using a Mega2560, Why not back Port Baseflight's CLI?

+1 for backport Baseflight's CLI

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

Re: wishlist for v2.3

Post by Hamburger »

you do understand not all features can be in the code for the small mcu like m328p? So a config + compile is needed to enable support of most features.
MWii already has an equivalent to CLI, that is called LCD_TTY. Not all parameters are tunable yet - that is a work in progress.

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

Re: wishlist for v2.3

Post by copterrichie »

Hamburger wrote:you do understand not all features can be in the code for the small mcu like m328p? So a config + compile is needed to enable support of most features.
MWii already has an equivalent to CLI, that is called LCD_TTY. Not all parameters are tunable yet - that is a work in progress.


Would it be possible to add a feature to the LCD_TTY to disable it when connected to the GUI or When using WinGUI, to use the CLI terminal?

Edited: I think (it has been awhile) with Baseflight, you send a # or three + to enter CLI mode, so would this be possible with the LCD_TTY?

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: wishlist for v2.3

Post by alexia »

Advanced headfree mode is a great idea 8-)

Gimbal
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: wishlist for v2.3

Post by Gimbal »

Fix serial so sbus work's one's and for all, and check stop byte in rx to stop glitching
Sorry can't provide code i'm in Pakistan working and my hard drive crashed :-(
Anders

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: wishlist for v2.3

Post by QuadBow »

Hamburger wrote:
  • uM-FPU - i2c floating point co-processor


I saw already an i2c FPU in http://www.micromegacorp.com/umfpu-v2.html.
Of course, floating point operations are time-consuming (ca 200 clocks per multiplication, that's at 16MHz 12.5us)
However, transferring 8(address)+8(command)+32(multiplicator)+32(multiplicator)+32(product as result)=120bits via i2c requires 30ms.
I wonder whether this approach is promising... Has anybody got better experience with such a co-processor?

Hamburger wrote:
  • PIDs independant of cylce time (done with fixated cycle time option?)


A fixed cycletime gives a better control. However, it requires a different approach. It doesn't make much sense, just to wait unttil the end of the fixed cycletime has been reached. Actually, the best solution would be staggered interrupts which are not available at AVRs and must be implemented in software.
E.g. the control algorithm is running at a fixed cycletime of 5ms and long lasting calculation (like GPS because of man floating point operations) are spread among several cycletime in annexCode. But, this requires a major change of the program structure.

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: wishlist for v2.3

Post by alll »

Possibility to set flight parameters (PID rate, rc rate) via aux1 and aux2.
Sometimes i want to fly calm, other times i enjoy 3D.
manu

arduifriki
Posts: 4
Joined: Mon Mar 04, 2013 10:47 am

Re: wishlist for v2.3

Post by arduifriki »

(from "v2.2 release is coming" post)
Alexinparis wrote:
arduifriki wrote:Hi All ,

Thank you to all the people of this community for the hard work you do.

I would like to know if it is possible to have something like a FAILSAFE_RTH option. I think it is the safest caracteristic we can have inside the FC of our copters.

I guess it would be easy to set GPSHOME mode ON just checking the failsafeCnt variable.

I have hacked the cheap Turnigy RF9X-V2 module getting a wire from the led indicator, in order to have a DIY failsafe option. The wire is connected to an analog input of my Crius card, so I can trigger the failsafe just swithcing off my radio emitter. I define in config.h a RSSIPIN as A6 input and then I trigger the failsafe in the mail loop if that value is less than 0.6V. It works fine and is a cheap solution if you have a cheap radio w/o failsafe, but this "only" lands the copter.

But independently of this I think It would be fine to get an automatic RTH if we lost radio contact with the copter.


in the next release


Thats, all. Alex knows :D

(Sure it is easy for a 328p micro, just setting f.GPS_HOME_MODE =1 if failsafeCnt > 2, and then GPS_I2C_command(I2C_GPS_COMMAND_START_NAV,0); -good for I2C nav card-).

Cephalgie
Posts: 2
Joined: Tue Jun 19, 2012 1:25 pm
Location: Germany

Re: wishlist for v2.3

Post by Cephalgie »

Position hold with optical flow sensor viewtopic.php?f=7&t=1413

FrSky direct Telemetry support

RCvertt
Posts: 172
Joined: Fri Sep 14, 2012 11:45 am

Re: wishlist for v2.3

Post by RCvertt »

Servo stretching past 90 degrees. 180 would be nice but a minimum of 130 degrees.

ebourlet
Posts: 9
Joined: Tue Mar 12, 2013 5:42 am

Re: wishlist for v2.3

Post by ebourlet »

Failsafe descent rate based on barometric pressure sensor based rate of descent rather than preset min throttle + set value.

AndrejLV
Posts: 23
Joined: Wed Mar 14, 2012 9:37 pm

Re: wishlist for v2.3

Post by AndrejLV »

ebourlet wrote:Failsafe descent rate based on barometric pressure sensor based rate of descent rather than preset min throttle + set value.


+1

User avatar
KasparsL
Posts: 75
Joined: Wed May 16, 2012 3:31 pm

Re: wishlist for v2.3

Post by KasparsL »

AndrejLV wrote:
ebourlet wrote:Failsafe descent rate based on barometric pressure sensor based rate of descent rather than preset min throttle + set value.


+1

+1 :geek:

Goetz
Posts: 82
Joined: Sun Mar 04, 2012 3:40 pm

Re: wishlist for v2.3

Post by Goetz »

another Idea / Wish:
optional Autodetect when fail of one ESC/Motor/Prop (measuring yaw) and switch Motormix for rescue-flight (possible of course only with 6 or 8 Motors) e.g. switch hex2quad

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

Re: wishlist for v2.3

Post by copterrichie »

I would like a feature to adjust the throttle value based upon battery voltage. Meaning, as the battery voltage drop over the duration of the flight, the throttle is increased to maintain the same Transmitter Throttle stick position.

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

Re: wishlist for v2.3

Post by Hamburger »

A first attempt is already in the code albeit hidden.
Enable the 3 governor defines. Only the 3rd will have effect for fixed pitch copters. Enable via aux switching.
It is tuned for 3s and will try to increase output values such that it would equal a constant 12.6v supply. Requires vbat reading.

This works quite well for my helis. Beware you will not feel the lipos end through noticable power sag so you must use vbat warning, powermeter and timer to fly safely.

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

Re: wishlist for v2.3

Post by copterrichie »

@Hamburger Interesting, will have a look.

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

Re: wishlist for v2.3

Post by Hamburger »

revert powermeter to be time based again - should reduce config hassle

Goetz
Posts: 82
Joined: Sun Mar 04, 2012 3:40 pm

Re: wishlist for v2.3

Post by Goetz »

another Wish / suggestion:
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

Goetz
Posts: 82
Joined: Sun Mar 04, 2012 3:40 pm

Re: wishlist for v2.3

Post by Goetz »

KasparsL wrote:
AndrejLV wrote:
ebourlet wrote:Failsafe descent rate based on barometric pressure sensor based rate of descent rather than preset min throttle + set value.


+1

good for different payloads (Akku, Camera...)

jy0933
Posts: 180
Joined: Wed Jun 27, 2012 4:24 pm

Re: wishlist for v2.3

Post by jy0933 »

ebourlet wrote:Failsafe descent rate based on barometric pressure sensor based rate of descent rather than preset min throttle + set value.


with assistance of z-acc to prevent over accelerating at beginning

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: wishlist for v2.3

Post by Katch »

Not sure if this has been suggested or even if it would work but could you;

Have the motors cut if the acc detects that the quad is inverted? So basically in Acro - when you flip the quad - while you're learning if you forget to cut the throttle you bury your quad props first into the deck (whilst preparing the soil for planting...)

If this worked you could just pull full elev back the quad would start to flip - acc detects invert - motors cut - acc detects back right way up and motors kicking again....

just an idea

zidlov
Posts: 16
Joined: Mon Jan 07, 2013 10:08 am

Re: wishlist for v2.3

Post by zidlov »

Support for i2c gps would be great, so that users with a HK or Crius Multiwii SE (with only one serial port) can use the Follow_Me and Set_Position functions from Ez-Gui...
As I understood it , for this to work, the desired position would have to be sent to the gps which isn't working with the i2c bus so far.
Don't really understand why we would need to send gps data TO the gps, though, and why it's not possible to just do all the arithmetics inside the MW board, but what do I know...:)

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: wishlist for v2.3

Post by Plüschi »

I do use a nanowii as FBL in a helicopter, and i did use it in a in a plane before.

One thing i dont like is the soft-generation of the 50hz signals for the servos when there is hardware available to do the job. A 16 bit timer is perfectly able to produce a good 60hz servo signal so why not use it? The 328 processors only got 2 output compare units, so very limited, but the 32u4 got 4 of them plus some 11 bit ones. I did patch the heli code to make 4 * 60hz servo signals in 16 bit hardware, while the esc signal is made 240hz on 11 bit hardware.

This leads to the next point, output.ino is unreadable due to the multitude of #if defined. There are 3 main paths for the 3 types of processors (mega,promini,promicro) causing close to 100 #if defined. Could we not make 3 main parts for the 3 processors and simply repeat the functions?

instead of the actual mess i propose:

#if defined(MEGA)
void writeMotors()...
void initOutput()...
void initializeServo()...
#endif

#if defined(PROMICRO)
void writeMotors()...
void initOutput()...
void initializeServo()...
#endif

#if defined(PROMINI)
void writeMotors()...
void initOutput()...
void initializeServo()...
#endif

would make life soo much easier...

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

Re: wishlist for v2.3

Post by Hamburger »

Plüschi wrote:instead of the actual mess i propose:

...

would make life soo much easier...


No. It would just create another mess of duplicated code that was common to all mcu types.

Gimbal
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: wishlist for v2.3

Post by Gimbal »

Fix serial:

" while (SerialAvailable(CURRENTPORT) GPS_COND SPEK_COND && CURRENTPORT != 1) {"

and Rx:

"#if defined(SBUS)
void readSBus(){
#define SBUS_SYNCBYTE 0x0F // Not 100% sure: at the beginning of coding it was 0xF0 !!!
static uint16_t sbus[25]={0};
while(SerialAvailable(1)){
int val = SerialRead(1);
if(sbusIndex==0 && val != SBUS_SYNCBYTE)
continue;
sbus[sbusIndex++] = val;
if(sbusIndex==25){
sbusIndex=0;
if (sbus[24] == 0x0){"

for Sbus permanently

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: wishlist for v2.3

Post by Plüschi »

Hamburger wrote:
Plüschi wrote:instead of the actual mess i propose:
would make life soo much easier...

No. It would just create another mess of duplicated code that was common to all mcu types.


Since the hardware is different there are already 3 parts of the code. It would not be necessary to split code which is the same for all 3 cpu types, like soft-pwm generation and mixing for different copter types.

The split of cpu-types is already here, not once, but all over the code. This makes it incredibly hard for a newbie to understand or change the code. Should the code be elitist only for a chosen few or do we want an easy understandable code?

The interface to hardware is just servos[] and motors[]. I dont understand why the mixing is not in another file since mixing and output are in another logical layer. Does the system of splitting the code in .h and .c files not work with arduino?

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

Re: wishlist for v2.3

Post by Hamburger »

what you proposed will split code, only following another aspect -the one you are currently interested in. It is not better nor worse than the current layout scheme doing ifdefs inside the function bodies. But it would require duplicating the non-mcu type specific parts of the functions.

Historic reasons for limited number of files and files' layout. The code is not optimized for a newbie to understand but optimized to work efficiently regarding the design principles as seen at time of writing. I consider that to be the more important aspect.

Anyway, this is a wishlist; so I will not engage in rehashing architectural discussions here - feel free to start yet another thread if you feel the need.

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: wishlist for v2.3

Post by Plüschi »

The hardware division sensors.ino is exaclty how i propose it for output.ino. Code duplication is avoided using gyro_common and acc_common routines. This division will become very useful when boards like the arduino due start showing up.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: wishlist for v2.3

Post by -ralf- »

Gimbal wrote:Fix serial:

" while (SerialAvailable(CURRENTPORT) GPS_COND SPEK_COND && CURRENTPORT != 1) {"

and Rx:

"#if defined(SBUS)
void readSBus(){
#define SBUS_SYNCBYTE 0x0F // Not 100% sure: at the beginning of coding it was 0xF0 !!!
static uint16_t sbus[25]={0};
while(SerialAvailable(1)){
int val = SerialRead(1);
if(sbusIndex==0 && val != SBUS_SYNCBYTE)
continue;
sbus[sbusIndex++] = val;
if(sbusIndex==25){
sbusIndex=0;
if (sbus[24] == 0x0){"

for Sbus permanently


Before changing my configuration that works with the fix above:

It's not part of the new r1435-dev. Does this mean S.Bus is broken again?

rickmorel
Posts: 3
Joined: Sun Apr 14, 2013 2:21 pm

Re: wishlist for v2.3

Post by rickmorel »

I recently tried Megapirateng on my Cruis AIOP. I feel that MultiWii is much better, but I stumbled upon a feature I can only describe as WONDERFUL! It's "Simple" mode. I've been flying models and fullsize since I was 5 years old. I'm now 67 and the eyes aren't what they used to be. I had a couple crashes because I lost orientation. Not a problem with "Simple".

"Simple" notes the heading when you arm. Then as long as you don't physically turn your body, forward is away from you, back is towards you, roll right is to your right and roll left is to your left, no matter the orientation of the quad. It's a bit disconcerting at first to have the quad nose in to you and move the stick forward to make it "back up". It even works while the quad is spinning around at a good rate.

Now I can fly much further away and still have perfect control. It's really made the difference between giving up on quads or not. This function would make MultiWii the almost perfect system for me.

Gimbal
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: wishlist for v2.3

Post by Gimbal »

-ralf- wrote:
Gimbal wrote:Fix serial:

" while (SerialAvailable(CURRENTPORT) GPS_COND SPEK_COND && CURRENTPORT != 1) {"

and Rx:

"#if defined(SBUS)
void readSBus(){
#define SBUS_SYNCBYTE 0x0F // Not 100% sure: at the beginning of coding it was 0xF0 !!!
static uint16_t sbus[25]={0};
while(SerialAvailable(1)){
int val = SerialRead(1);
if(sbusIndex==0 && val != SBUS_SYNCBYTE)
continue;
sbus[sbusIndex++] = val;
if(sbusIndex==25){
sbusIndex=0;
if (sbus[24] == 0x0){"

for Sbus permanently


Before changing my configuration that works with the fix above:

It's not part of the new r1435-dev. Does this mean S.Bus is broken again?


Well not much response for this, guess not to many using Sbus so we have to live with it, got my self an Frsky Delta8 Rx putting out ppm from S-FHSS 23$, will use it with Baseflight witch only have two uart

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: wishlist for v2.3

Post by Mis »

rickmorel wrote:This function would make MultiWii the almost perfect system for me.

Turn on the HEADFREE box in multiwii and... Tada, you have "Simple mode".
Better, if you have GPS and you enable "advanced headfree" in config.h, then if you fly over 15m from starting point, pulling the pith stick down your copter always return to you, independed from posttion and orientation of copter.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: wishlist for v2.3

Post by -ralf- »

Gimbal wrote:
-ralf- wrote:
Gimbal wrote:Fix serial:

" while (SerialAvailable(CURRENTPORT) GPS_COND SPEK_COND && CURRENTPORT != 1) {"

and Rx:

"#if defined(SBUS)
void readSBus(){
#define SBUS_SYNCBYTE 0x0F // Not 100% sure: at the beginning of coding it was 0xF0 !!!
static uint16_t sbus[25]={0};
while(SerialAvailable(1)){
int val = SerialRead(1);
if(sbusIndex==0 && val != SBUS_SYNCBYTE)
continue;
sbus[sbusIndex++] = val;
if(sbusIndex==25){
sbusIndex=0;
if (sbus[24] == 0x0){"

for Sbus permanently


Before changing my configuration that works with the fix above:

It's not part of the new r1435-dev. Does this mean S.Bus is broken again?


Well not much response for this, guess not to many using Sbus so we have to live with it, got my self an Frsky Delta8 Rx putting out ppm from S-FHSS 23$, will use it with Baseflight witch only have two uart

Hi Gimbal,

I just compiled r1449 (with latest GUI) .... S.Bus is broken!
Do you have a fix that matches the latest serial.ino?

EDIT: I opened a new thread in Software Development with a fix that works fo me.

Greetings
Last edited by -ralf- on Tue May 21, 2013 5:41 pm, edited 1 time in total.

awarche
Posts: 6
Joined: Tue Apr 16, 2013 9:57 am

Re: wishlist for v2.3

Post by awarche »

Is it possible?
MWC controllinng brushless gimbal like it does with servos gimbal. Without IMU on the gimbal.

rickmorel
Posts: 3
Joined: Sun Apr 14, 2013 2:21 pm

Re: wishlist for v2.3

Post by rickmorel »

Mis wrote:
rickmorel wrote:This function would make MultiWii the almost perfect system for me.

Turn on the HEADFREE box in multiwii and... Tada, you have "Simple mode".
Better, if you have GPS and you enable "advanced headfree" in config.h, then if you fly over 15m from starting point, pulling the pith stick down your copter always return to you, independed from posttion and orientation of copter.


Well DUH on my part. I had seen HEADFREE it didn't click in. Thank you so much Mis, and thanks to the entire MultiWii "team". As soon as my 3D printer finishes its job, I'm going back to the much better MultiWii.

Now, if the 15 to 20 mph winds we've had for a week will just settle down....

mopedcrosser
Posts: 52
Joined: Sat Feb 23, 2013 12:35 pm

Re: wishlist for v2.3

Post by mopedcrosser »

Hi,

I would consider these points as most important

- GPS Failsafe integration (has already been done). I think its very important that the copter comes home safely in case of a radio error and does not
crash down at the current location.
- +1 for Telemetry integration (has also been done before). Its nice to see current voltage, heigth and distance from home. Especially because bluetooth range is
very limited.
- +1 for mission mode with waypoints (probably needs a lot of work -> therefore possible in 2.3 ?).
- +1 for Mavlink integration

GUI:

- It would be nice to have a map (like in arducopter or Enzio app)
- It would be nice to have all radio (aux) channels available instead of the current 4

Related to the "Release more often" thread we had befor 2.2 was released... We (better Alex ?! ) probably should define the features to integrate then "freeze" the features and work until they are all in. Then we all should test this end finally release the 2.3. I think at this time nobody has a idea when 2.3 is supposed to be released and which features are supposed to be included. If we would set a goal, all the workforce could focus on getting the important features done instead of working on features that will be discarted anyways.. (eg. HOTT telemetry, GPS failsafe etc)

Sebastian

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: wishlist for v2.3

Post by felixrising »

+1 on the release cycle goals... good to put down a roadmap and work towards it.

Maybe we can put down a coding standards and code submission policy/process on the wiki to clearly communicate what is expected of devs for it to make it into multiwii? There are many very good devs here, and "less good" devs that are still learning but can become good with feedback, having code accepted and committed is an important part of keeping them engaged and active.

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

Re: wishlist for v2.3

Post by Hamburger »

felixrising wrote:+1 on the release cycle goals... good to put down a roadmap and work towards it.

Maybe we can put down a coding standards and code submission policy/process on the wiki to clearly communicate what is expected of devs for it to make it into multiwii? There are many very good devs here, and "less good" devs that are still learning but can become good with feedback, having code accepted and committed is an important part of keeping them engaged and active.


good in theory; please consider...

we all do it as a hobby project in our free time out of free will. If I had to submit to a contract on what I was going to do for a release, it would always have been zero - nothing. In reality this has not happened with a single release in the past, but contracting would bring a drastic change of behaviour? I guess that is part of the beauty and downside of hobbyist open source development - devs do what and when they want to (so long as it fits the general project idea).

Alex put up kind of a roadmap for the forthcoming release, and we found we want to release more often (2.2 had longest development cycle ever). That is as precise as it will get, I am afraid. In practice, I expect a next release shortly after the major servo rewrite has settled.

For contributions, I try keeping the readme.txt uptodate http://code.google.com/p/multiwii/sourc ... README.txt . It is imperfect - as is our current code. As a rule of thumb, start new thread '[patch] new leveling algorithm" for your new contribution, describe what it does and include a 'diff -u' so we can easily see and apply what changes you made. Chances are, one of the registered active devs will pick up on the topic and incorporate it. Chances are, it will not happen - then you can always contact a dev who is 'close to your subject' and _kindly_ urge him to take a look. As a last resort everyone is free to contact Alex.. But beware, not every possible mod is considered appropriate to become part of main branch, read the readme on that. If you do not like the outcome you can always fork your own multiwii offspring.

Yes, many good devs around. We want everyone to participate, the process of getting sucked in takes some time - and effort, for all of us.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: wishlist for v2.3

Post by felixrising »

Thanks Hamburger for clarifying,

Do you mind if I put the contents of the README.txt onto the wiki under a Developers section?

It would be good to adopt a practice of placing a feature list accepted for inclusion for the next (ie 2.3) release cycle in the OP for that release cycle, ie "MultiWii roadmap for 2.3" along with the volunteer dev who is picking it up or wants to contribute. As you mentioned, there are often one or two big changes which make it in, items that don't meet a release date would automatically end up in the next release cycle... etc... This would make it clear to volunteers what is already being worked on and by whom, and for items not being worked on, they could easily volunteer. Submissions going through the more senior devs with access is a good way to keep more eyes on a submission and ensure quality of submissions. Adding some clear framework makes it easier for people to organise themselves and to contribute, IMHO.

Anyway, I realise this is a hobby for all, and I for one certainly appreciate all the hard work that goes into this, be it out of self interest or more altruistic motives.

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

Re: wishlist for v2.3

Post by Hamburger »

felixrising wrote:Do you mind if I put the contents of the README.txt onto the wiki under a Developers section?

not at all; please go ahead. I would like to see the primary source of this development related info staying close to the source, so maybe add a link to the original source readme.txt.
It would be good to adopt a practice of placing a feature list accepted for inclusion for the next (ie 2.3) release cycle in the OP for that release cycle, ie "MultiWii roadmap for 2.3" along with the volunteer dev who is picking it up or wants to contribute. As you mentioned, there are often one or two big changes which make it in, items that don't meet a release date would automatically end up in the next release cycle... etc... This would make it clear to volunteers what is already being worked on and by whom, and for items not being worked on, they could easily volunteer. Submissions going through the more senior devs with access is a good way to keep more eyes on a submission and ensure quality of submissions. Adding some clear framework makes it easier for people to organise themselves and to contribute, IMHO.

All very true. What I said earlier about the development cycle does only reflect my personal opinion and experience with this project. I do understand the wish for a more standardized procedure; I had proposed a similar approach with the wishlist. From past experience and knowing how some of the devs prefer to work I am not sure the project would benefit if such tight procedure was enforced. I certainly do not expect nor hope it is going to happen (on contrary, I have seen such enforced approach drive people away in other volunteer projects).
Sometimes, some devs may have an agenda for the upcoming version (like EOSbandi announced waypoint) but some things simply pop up (my powermeter rewrite or the servo reassignment/reorganisation). In the end, everyone does what one wants to do, it is a hobby. Yes, we could announce our intentions if/when we happen to know. Obviously it may look intransparent to outsiders - and it is for the most part. ( for me too)
Sounds very imperfect but has proven to give quite good results nevertheless.
Anyway, feel free to suggest modifications to the dev cycle. You can never know beforehand, what gets picked up and pertains. Just keep in mind developers in the hobbyist world in general do not necessarily like tight development rules - ADA never was a big success in this realm for a reason.
Anyway, I realise this is a hobby for all, and I for one certainly appreciate all the hard work that goes into this, be it out of self interest or more altruistic motives.

Right. We sure have fun doing what we do.

Post Reply