dev_2013_08_23_r1573_pre_2.3 user feedback

[linuxslate]

MultiWii_dev_2013_08_23_r1573_pre_2.3 - Are you grinning like a Cheshire Cat due to the awesome stability and performance, or are you in hospital preparing to undergo back surgery from having to bend over so many times picking up the pieces?

Please post experience, GUI config shots, config.h lines here.

Please DO NOT post suggested code changes, feature requests, etc. in this thread.

Be sure to include a basic description of your aircraft (Quad, Tri, Plane, etc.), and anything about your aircraft that may make it "non-generic".

[Wayne]

No pre_2.3 joy for me.
Tri, Paris 4.0, MPU-6050, BMP085, HMC5883 & i2C GPS.
My hardware setup works great with MW2.2.
I2C freezes when i2C_GPS is activated using pre_2.3. When commented, everything else works, even with i2C GPS still hooked up.
Back to 2.2 and all is well again.

[alll]

Not working!
My test-board:
QuadX, Crius-Lite, Futaba 6 channels

Cleared eeprom, uploaded fw, calibrated acc, arming =>

not all motors start,
1 motor even unarmed gets jerky signal,

manu

[vistauser]

Hi MultiWii fans,

My copter:
MWCX 45cm
Props are cut to 9" EPP1045
EMAX 2213-935Kv
Flyduino 25A ESC SimonK firmware.
3S1P 2200 mA Akku.

Flyduino Mega FC, ATAVRSBIN1 Sensorboard, BMP085 on Flydusense,
FMP04 serial GPS on Flyduino FMP04 GPS Bob

TX a Spektrum DX7 with Satellit RX.

First results:
Configuration and loading the new pre release 2.3 sw without problems.
Engine start and indoor flying with default settings smooth and safe.
GPS fix available after some seconds.

Thank you Alex in Paris
vistauser

[Alexinparis]

@linuxslate, thank you for initiating this post
@Wayne: I will check this tonight, maybe a problem with GPS I2C devices with SONAR enabled
@all: are you using the java GUI ? It's important due to one MSP message update
@vistauser: I hope we will have a lot of feedbacks like yours

[Wayne]

I forgot to mention I also have an OLED_I2C_128x64. I have no sonar. Plus my MAG and BARO are on the MPU-6050 secondary i2C.
This morning I tried again, using Arduino 1.5.2 and doing power-off resets after eeprom_clear I get the same results.
That is ‘it all works until I bring i2C_GPS into the sketch’.
Alex, no need to work on my problem. I am extremely happy with the way 2.2 works and I can wait for others, if any, to chime in on this.

[Alexinparis]

I forgot to mention I also have an OLED_I2C_128x64. I have no sonar. Plus my MAG and BARO are on the MPU-6050 secondary i2C.
This morning I tried again, using Arduino 1.5.2 and doing power-off resets after eeprom_clear I get the same results.
That is ‘it all works until I bring i2C_GPS into the sketch’.
Alex, no need to work on my problem. I am extremely happy with the way 2.2 works and I can wait for others, if any, to chime in on this.

I tried to reproduce it with a Paris 4.0 SIRIUSGPS (Paris GPS MAGv1r3: I2C GPS + I2C mag separated)
and all is working fine

[linuxslate]

Since I started this feedback thread, I guess I should provide mine.

In short - No complaints. Works fine.

I have a very generic 450 quad
HJ Alien frame upgraged to DJI arms.
Crius AIO Pro 1.0
UBLOX GPS
Bluetooth
MinimOSD 0.1 KV Team r345 (Haven't upgraded OSD yet.)
Fat Shark Predator 250mW 5.8 transmitter

-- Flashed EEPROM Erase from arduino examples and rebooted
-- Did it a few more times (OCD Symptom)
-- Flashed dev_2013_08_23_r1573_pre_2.3
2.2 legacy control loop
57600 GPS (was 115200)
all other config settings same as before/default
No GPS Lead Filter (as before)
-- Used screenshot of my configured 2.2 GUI to set exactly the same PID and other values.

No Problems at all. It flies at least as well as it did before. ALT hold (baro) seems better.

GPS RTH was all over the sky the one time I tried it. In my previous FSW (Slightly customized 2.2), I had set the nav rate a little faster. I'm Using the devaults in pre_2.3, but it still Waaayyyyy overshoots. Possibly 50M, then overshoots the other way. It probably missed a pole by less than a meter. This pole was no where near a line from where it was to the home position. It never really did stablize over the home position. It kinda settled out about 10-20M East of home, but was still behaving erratically, so I took it out of RTH.

Could have just been the GPS signal at the time, as GPS HOLD tried at other times worked fine. I will try again -- With and without GPS Lead filter.

Even with the lack of good RTH, it definately seems stable (in both the sofware, and control loop sense), and is clearly an improvement over 2.2.

Thanks to the Dev's -- Great work.

[mopedcrosser]

Hi all,

is this the complete changelog ?

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

I´ll put it on this weekend hopefully and report...

Thx for all the work so far !

Seb

[mopedcrosser]

Alright,

i got it flashed without any problems as usual. All features including GPS seem to work fine so far. I wasnt able to take it out for a testflight and will do that tomorrow.
There is one thing I found in the GUI. You cant see the servo setting tab before you click read once in the settings tab.. It took me an hour to figure out how to configure the gimbal because the tab wasnt there and the setting in config.h is no more present. A problem I couldnt solve is how to set the channel for the gimbal roll/tilt override. It had been in config.h but is no more present. Can somebody help me out ? I wasnt able to find it in the GUI... Will report my testflight asap

Thanks for all the work !

Seb

[mopedcrosser]

Alright,

i got to fly outside and couldn´t something i would complain about. I noticed that the baro worked a little smoother and that the stability in sinking flight almost perfect now. With 2.2 my copter started to wobble during fast descending. I also tried the advanced headfree which worked good as well. All in all superb work ! I also noticed a better and smoother position hold but I enabled the gps lead filter this time while i was using 2.2 without. Due to many recommendations i disabled it but after I fixed my wiring and have a properlyworking compass now i think that gps lead helps to soothen the ph out.

So far so good. Conclusion is works on crius aiop V.1.1 / hexa without noticable flaws except the 2 points below.

There are 2 things I couldn´t find yet:

1. Where can you adjust the channel for manual gimbal roll / pitch ? Was in config.h before.

2. Where can I set the maximum nav travel speed ? Was in config.h before as well.

Thanks for all again

Seb

[Hamburger]

r1589: TRI on mega2560 and m328p works

[Alexinparis]

1. Where can you adjust the channel for manual gimbal roll / pitch ? Was in config.h before.

It's no more settable in config.h
It can be done only via GUI.
In the gimbal servo setting you can select a static center of each servo, or select the channel which will command this center.
(it's less intuitive, but much more generic like this)

2. Where can I set the maximum nav travel speed ? Was in config.h before as well.

somewhere here in GPS.cpp I think:
#define NAV_SPEED_MIN 100 // cm/sec
#define NAV_SPEED_MAX 300 // cm/sec
#define NAV_SLOW_NAV true
#define NAV_BANK_MAX 3000 //30deg max banking when navigating (just for security and testing)

[Wayne]

I can report that r1604 has loaded and is up and running without errors.
Thanks.
Wayne
Tri, Paris R4, 400kHz, MPU6050, BMP085, HMC5883, RCAUXPIN8, i2c GPS.
Now out to the field for flight tests…..

UPDATE: On the way out the door I remembered that my OLED was on my Mega board back on the bench. I grabbed it and headed to the park. I installed the OLED and powered up. Nothing, frozen again.
I pulled out the notebook computer and removed i2c GPS from the sketch and up loaded. OLED now worked and I did get to fly a couple packs.
Back home this morning I find I can have, while i2c GPS is active, either OLED plugged in OR OLED activated in the sketch, not both at the same time. Without i2c GPS activated OLED works just fine.
Note to the developers, I do not need this fixed as I understand the limitations of the 328. I just wanted to show I can now get pre2.3 working on my system.

[Noctaro]

Hi,
i did 4 (Quad-X) testflights with the new dev for now. GPS Pos hold works fine for me. Circles aorund 1-2m position with 9 sats. (FFimuV2 + MTK GPS)
But RTH. ->

linuxslate:
GPS RTH was all over the sky the one time I tried it. In my previous FSW (Slightly customized 2.2), I had set the nav rate a little faster. I'm Using the devaults in pre_2.3, but it still Waaayyyyy overshoots. Possibly 50M, then overshoots the other way. It probably missed a pole by less than a meter. This pole was no where near a line from where it was to the home position. It never really did stablize over the home position. It kinda settled out about 10-20M East of home, but was still behaving erratically, so I took it out of RTH.

As i watched my OSD i could see arrow pointing to right direction, but copter still went away...weird...

My mag mismatch at full throttle is around 10°, would this be the problem? As far as i remember had RTH working with 30° offset using 2.2.
Also it does some random Yaw wobble if my mag is active. Maybe calibration went wrong... Will keep testing.

tested:
Acro - works
Level - works
Baro - works
PosH - works
Mag - ?
RTH - ?

GUI (32Bit Win7) bugs. Crash after random time connected. (grey box)

Greetz Noc

update (2 additional flights):
I recalibratet compass, now everything is working again (except GUI). Also no yaw overshoot left. It was definately my fail, sorry...

tested:
RTH - works (also face to home direction working now fine with RTH)
Mag - works