MultiWii

dramida wrote:Today i flew MWC R13 on a Crius AIOP Quad. It worked well but some time when i want to arm the copter , a long beep is triggered and the copter dosen't arm. After recalibration, it worked. And one more thing: Rushduino OSD (aka minimOSD) dosen't sense the ARMED state and the baro vario is shown reversed. More to dig in tomrow.

Long beep can be caused by the failsafe, simply arm again and it will work. (there is an integer wich has to be reset before arm).

The serial part is not touched, neither the vario number calculation, so possibly there is something with the Rushduino code.

Thank you Adrian.
After flying R13 for the third time I think that newly proposed function like:

-altitide controlled vario with throttle stick
-RTL with altitude control settings
-Home with altitude setting

is good enough to make in to the main trunk. I didn't test the failsafe procedure yet as my frsky has its own FS setting.

dramida wrote:
After flying R13 for the third time...

hi dramida,
is there a chance to make a demo video as usual??

Hi all,

Here is my new r15 release.
- based on 1322, so theoretically the hold position injection (WP16) works with EZ-GUI (not tested since EZ-GUI was released in the evening...)
- included advanced headfree mode (more details here: viewtopic.php?f=7&t=2951#p29370 )
- beep function for vario mode when switching between rising/descending (for Dramida)
- increased resolution for manual vario mode (2,5 cm/s...instead of 25 cm/s ), so even smoother vario mode
(if you modify my code, please note that AltHold is now in mm instead of cm, so use /10 divider for cm)
- many parts of the code is even more optimised, ie. PID changings are collected into IMU.ino for easier understanding
- rising/descending to target is more robust and direct. You'll feel in the air...
- some comments changed in config.h, I suggest strongly to go throush on them!

And don't forget the basics: TRY IT ON YOUR OWN RISK!!! This is the next state of a custom development, BUGs could be still remain.
If you need something well tested code for your expensive copter, download any of the OFFICIAL MULTIWII RELEASES instead of mine.....

BR
Adrian

Thank you Adrian. Have you tested your distribution with MinimOSD?

dramida wrote:Thank you Adrian. Have you tested your distribution with MinimOSD?

No, I'm using Mobidrone OSD. Theoretically there are no any changes in serial code compared to the official r1322 release so it should work on the same way as with the official r1322.

one quicky...

what if the hovering point is not at ALT_HOLD_THROTTLE_MIDPOINT

should I change ALT_HOLD_THROTTLE_MIDPOINT to about the hovering point or ?


also.... is it possible to use vario from taking off.. say... turn on alt hold (vario), then arm, then stick up for ascending... center stick for maintain hovering?

btw.. what kind of alt hold accuracy are we talking about here with ms5611?


thanks

jy0933 wrote:one quicky...
what if the hovering point is not at ALT_HOLD_THROTTLE_MIDPOINT
should I change to about the hovering point or ?
thanks

You have two options. "ALT_HOLD_THROTTLE_MIDPOINT" is for using defined throttle position for hovering, which doesn't depend on hovering point.
But if you would like to use your hovering throttle point instead of defined value, then simply comment "ALT_HOLD_THROTTLE_MIDPOINT" line.
Do not set it to 0 as copter would always rise!!!!

jy0933 wrote:also.... is it possible to use vario from taking off.. say... turn on alt hold (vario), then arm, then stick up for ascending... center stick for maintain hovering?

I would not recommend this since accZ has also influence on alt hold code, and can cause big jumps during takeoff. I recommend to activate the BARO in stable hovering!
BTW, if you are brave enough, can try it but with ALT_HOLD_THROTTLE_MIDPOINT uncommented. First arm copter then turn on baro then apply throttle.
I don't know how it will react!!!!!!

jy0933 wrote:btw.. what kind of alt hold accuracy are we talking about here with ms5611?

The alt hold code during hovering (0 cm/s target vario) is the same as in the official release!
That means accuracy is exactly the same as for the official release too!
It depends on alt hold PIDs/baro sensor/motor/prop/frame/weight/etc too... can't exactly defined!
Each setup has its own accuracy.

BR
Adrian

jy0933 wrote:one quicky...
btw.. what kind of alt hold accuracy are we talking about here with ms5611?
thanks

Another short comment at this point.
For the best alt hold behaviour I strongly recommend to set up the throttle curve and expo for hovering around 1500 throttle stick input with 3/4 charged battery.
That will definitelly cause the best and balanced alt hold behaviour could be reached!!!

ALT_HOLD_THROTTLE_MIDPOINT is basically for FPV purposes or countinous vario mode, since after many rising/descending it is hard to remember the throttle position of the activation. But when the center point is defined (ie. 1500), it is much easier to find the 0 vario.

BR
Adrian

make sense to me

here's what i defined.. and gonna go out test as soon as it gets warmer





say if the hovering point on tx is 70% throttle.. once i fly in hovering and turn on alt hold. I should bring the throttle stick back to 1500 to maintain the hold.. right?



thanks

One interesting observation about R13:

I've made a landing using vario altitude mode. After touching ground, the proppelers continued to spin (as expected) slower and slower until they reached the minimum arm throttle (1150us). So it could be possible to detect the landing and stop the motors.

jy0933 wrote:make sense to me

here's what i defined.. and gonna go out test as soon as it gets warmer

Code: Select all

 #define VARIO_ALT_MODE                          // define ALT HOLD code
    //#define VARIO_MODE_CHANGE_BEEP                  // beep if changing between rising/descending  - long beep when entering hoover mode, short beep when changing between rising/descending
    #define ALT_VARIO_MAX                     20   // in cm/s  - maximum rising/descending vario when full throttle applied  -  maximum 250!!!
    #define ALT_HOLD_THROTTLE_NEUTRAL_ZONE    50    // in us    - deadband of stick around hovering point when in ALT HOLD is active (us in PWM signal)
    #define ALT_HOLD_THROTTLE_MIDPOINT        1500  // in us    - if uncommented, this value is used in ALT_HOLD for throttle stick middle point instead of initialThrottleHold parameter.

say if the hovering point on tx is 70% throttle.. once i fly in hovering and turn on alt hold. I should bring the throttle stick back to 1500 to maintain the hold.. right?
thanks

Yes, you are right.

dramida wrote:One interesting observation about R13:

I've made a landing using vario altitude mode. After touching ground, the proppelers continued to spin (as expected) slower and slower until they reached the minimum arm throttle (1150us). So it could be possible to detect the landing and stop the motors.

Hi,

Interresting, I'll think on it! Thanks.

BR
Adrian

I'm trying the nhadrians build R15 on "Crius All in one pro" board . I get the following problem : If i use the include "#define FAILSAFE" option then the board doesnt work properly, it will not arm and it will not read the correct throttle reading in the gui and just do totally random things with the switches in the gui.
if i use a switch to arm, it can hardly fly, if i comment the "#define FAILSAFE" option it is back to normal.
On older builds the failsafe options works OK.
ITs the same problem with the build version r1317 so its not nharians code, its something from before his code.

(its a tri-copter)

scanman wrote:I'm trying the nhadrians build R15 on "Crius All in one pro" board . I get the following problem : If i use the include "#define FAILSAFE" option then the board doesnt work properly, it will not arm and it will not read the correct throttle reading in the gui and just do totally random things with the switches in the gui.
if i use a switch to arm, it can hardly fly, if i comment the "#define FAILSAFE" option it is back to normal.
On older builds the failsafe options works OK.
ITs the same problem with the build version r1317 so its not nharians code, its something from before his code.

(its a tri-copter)

I suggest to make an EPROM clear:

http://arduino.cc/en/Tutorial/EEPROMClear

I had something similar long time ago with an old MWI version, I got random switch checkboxes in the GUI, and this solved the issue for me.
But if you have false throttle channel reading than it is rather a hardware issue, because Failsafe code itself doesn't affect channel reading. Check all connections, solderings.

BR
Adrian

ok thanks , i tried the eeprom clear it didnt seem to help i will try it again, i dont think its connections because I can remove the failsafe switch and it works perfectly without touching any connections, but i will re-check.

By the way Adrian, thank so much for the "Tip" of using Visual Micro for arduino projects i was continually cursing the rudimentary arduino user interface including their extremely frustrating search function.

The R15 release of Multiwii works as expected. It can change altitude in flight as configured. A new MSP SET CURRENT ALTITUDE and Set WP ALTITUDE would be nice. It also beeps when changing altitude in alt Hold Mode with vario control.
Notice: when entering in hold altitude from vario mode, the loong beep is missing.

Here are two flights with R15:

Position hold and alitutde hold on wind
http://www.youtube.com/watch?v=8wImr9Jm4Yc

MAP GPS navigation and autolanding
http://www.youtube.com/watch?v=2wMqMO8-F_I

Great flights!!!

I have one question. Are you still using bluetooth only ofr Android communication? My first tests with HM-TRP modules (same as in the 3DR) were successful, I got extended range.
Are you thinking on to expand the range?

BR
Adrian

impressive.... i'm waiting for a better day to go out an test

nhadrian wrote:Great flights!!!

I have one question. Are you still using bluetooth only ofr Android communication? My first tests with HM-TRP modules (same as in the 3DR) were successful, I got extended range.
Are you thinking on to expand the range?

BR
Adrian

Actualy i am using bluetooth with a range about 200m. I am very interested about increasing the range to be able to take the shoots approximately from the same position without loosing the link. I am wondering if EosBandi woud update his WinGUI to be able to inject new PH and home.

dramida wrote:.... new MSP SET CURRENT ALTITUDE and Set WP ALTITUDE would be nice. ...

At this point serious help is needed!!!
For me it looks like that current nav structure can't handle proper WP navigation, so it must be reworked from the base.
Till now I developed my code without any help, but at this point it must be changed to a team play.

MSP, EEPROM, GPS, main loop, GUI, etc. must be chanded...

BR
Adrian

dramida wrote:...
Actualy i am using bluetooth with a range about 200m. I am very interested about increasing the range to be able to take the shoots approximately from the same position without loosing the link. I am wondering if EosBandi woud update his WinGUI to be able to inject new PH and home.

First I was wondering on handle an FTDI board connected to phone USB, but Bart said it is far too complicated.
I prefer the phone method since I'm using MAC OS. But my phone is always in my pocket.

The 100 mW 3DR modules have aprox. 800 m range, hardly depends on the antenna type. If the ground module is connected to the bluetooth module, it should give the same rande as with the WinGUI.
The only problem/important thing is the arrange of the modules, because my experience is that if the BT module is too close to the 3DR module, they push down each other.
Now they are separated on my FPV tray as far as they could be, and the antenna positions are also set to the best direction ( they are almost collinear, the transmit power is lowest in that direction for a 1/4 wavelength antenna)

So you took a 3DR uhf transciever module with 5v TTL output and re-programmed as slave. I am not clear about 3DR configuration. Some help please?

dramida wrote:So you took a 3DR uhf transciever module with 5v TTL output and re-programmed as slave. I am not clear about 3DR configuration. Some help please?

There isn't any master/slave option! 3DR modules are simple transparent serial connections, what goes in to first module, goes out from the second one, and reversed.
If you are interrested, I can share my setup values, but I think everything is written down clearly in the 3DR wiki site:
http://code.google.com/p/ardupilot-mega/wiki/3DRadio

Once you go through the wiki, you'll understand every important parameter.

And what I like in them, you can setup the 'air module" by remotelly, that means you connect one module to your FTDI, the second module is connected in the air, and you can setup both from the first one.
That means you can remotelly setup the module in copter and only have to connect the ground module to the FTDI instead of BT module.

Clearly spoken you only need a BT module and two "air 3DR modules" (the type without USB plug, the firmware is the same!!! there isn't any ground/air firmware!!!)

BR
Adrian

Adrian,

Sorry to ask such a basic newb question, but once I load your version of the firmware and have configured the appropriate define values in the config.h file, is this activated by just switching on "baro" on my transmitter or are there other switches involved?

I play around with lots of different boards and honestly haven't done that much with multiwii. As a non programmer, I am amazed that the expensive Naza board has been considered above the rest in alt hold performance for so long. I have searched for less expensive alternatives that perform as well to write about on my blog without much luck. This sounds very exciting!

Thanks,
Britt

If Naza has 10 out of 10 in altitude hold, i would give Multiwii -10 and arducopter 9.
And yes, you have to switch on the baro to enter in altitude mode.
I advice you to increase D factor to 60 if you are using MPU6050 or BMA180 as acceleration sensor because D factor is the amount of Z acceleration taken into Alt-hold calculation.

I found this clip with a barometer simulation of altitude hold and altitude variation using MWC code. It seems that multiwii code works perfect, the only errors are from sensor readings.

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

dramida,

I'm not sure I am following what you are saying. The code is perfect, but the multiwii altitude hold rates a -10. Why are the Naza and Arducopter so much better? Are you saying it is all because of the sensors? I don't know what kind of sensors the Naza uses, but the Arducopter uses a MS5611 which you rate a +9? Many Multiwii boards also use the MS5611. I must be misunderstanding.

NHA, sorry if I am cluttering the thread, I am very interested in your code and just trying to understand how it compares to what else is out there.

Well, I tried this out this afternoon and was very pleased considering it was my first pass and I am a multiwii novice. I am using a AIOP v1.0. All I did was uncomment the line "#define VARIO_ALT_MODE" and had a switch to activate the baro. It held altitude well. Certainly as good as my attempts with MegapriateNG, but not quite as well as the Naza yet. Of course, I did some quick setup and tuning, so that could be why. Overall, I am very impressed and will keep working with it. Thank you for your hard work Adrian!!

I was getting some strange random yawing, but don't think I have the Mag calibrated correctly which may be causing it. Dunno.

It can be a faulty mag calibration!

You can check in the gui. First, check the 4 major directions, then try to turn the copter aroung roll/pitch by 20-30 degrees and watch the gui. The direction must not change!

BR
Adrian

im just wondering what is that BT module... 200m is a very decent range for short distance test... mind give a link about it?

thx

BT module and 3DR air modules also can be bought at rctimer.com, and in many other webshops too.
Just google around!

I apologize if this has been answered before...

The altitudes like RTH_ALT are they absolute heights based on the GPS or are they relative to the altitude that arming takes place?

Mark_K wrote:I apologize if this has been answered before...

The altitudes like RTH_ALT are they absolute heights based on the GPS or are they relative to the altitude that arming takes place?

They are all relative heights relative to armed ground level.

There would not be any sense on using GPS height, once because it is not so accurate and second, when you would modify config.h, you should know the exact place where you will fly after...

BR
Adrian

nhadrian wrote:There would not be any sense on using GPS height, once because it is not so accurate and second, when you would modify config.h, you should know the exact place where you will fly after...

BR
Adrian

Thanks! I was assuming this is right but wanted to check before I got to watch my quadcopter auger into the ground while RTH because I told it to fly -97m below ground.

Today i flew R15 of NHAdrian on a Crius AIOP.

3 issues:

1- When in BARO mode, it dosen't beep when enters in altitude hold mode from climb or dive . So i still have to watch my stick carefully and a larger dead-band around has some counter-effects as described in 3.
2- Home altitude isn't reset at each arming so i had the surprise that after going on the other side of the road, i could not auto-land in rth mode.
3- After setting a clear dead-band (50us) around alt-hold position, when you are out of dead-band with throttle, the correction is calculated wrong from the middle point, not from middle point plus-minus dead band so you have a jump in altitude variation and can't set a slow variation just after exiting the dead band range .


Another issue was about GPS PH (not concerning baro)

After giving a waypoint more than 400m away (fpv mode with bluetooth, EZ-GUI android aplication), the PH went crazy and i have to reboot controller. No other tests were made after PH incident.

Hi Dramida,

here are my replies:
1.) I'll check the beep code, maybe can be solved easilly
2.) that's interresting because for me it resets on every arm. BTW, I'll check it again in code

*******Just to avoid any confusion for other users***********
Please note that in RTH mode I didn't have any auto-land feature!!!!!!!!!!!!!!!!!!!!!!
The only feature I have is descending to a safety altitude once home reached!
This is NOT an autoland feature since there isn't any ground sensing algoríthm in it, nor a slow-down one.
Maybe it can be used for autoland but generally not made for that purpose!!!
***********************************************************
3.) nice catch, I'll modify the code, not a big issue, but till now I didn't think on this...

____________________________________________

About PH, that part wasn't touched in the code.
I'm still having the oppininon that the current MWI code is not capable for proper WP navigation, inserting WP16 by MSP and changing nav mode is only a forced solution but have many weak points. The complete restructure of navigation algorythm would be neccessary.... :S

I also tested the EZ-GUI PH modification within 80-100 m range, it worked quite well. (with BT + 3DR communication)
Unfortunatelly many things could cause that breakdown, even some overflow in navigation code caused by long distances....

BR
Adrian

Thanks for reply, i will make further tests with your code. Keep up the good work

dramida wrote:Thanks for reply, i will make further tests with your code. Keep up the good work

2.) and 3.) are corrected. I'll upload once flight tests are done.
1.) is more tricky since for me it beeps when entering into hovering. BTW I'll try to find the problem.

BR
Adrian

nhadrian wrote:

dramida wrote:Thanks for reply, i will make further tests with your code. Keep up the good work

2.) and 3.) are corrected. I'll upload once flight tests are done.
1.) is more tricky since for me it beeps when entering into hovering. BTW I'll try to find the problem.

BR
Adrian

Hi Adrian, Thanks for improving MWC.
I want to make you a donnation in MWC components for helping the community. Please send me a PM list with what you want.

Question:
-What happens if i fly in a valley with altitudes lower than starting point?
-Can i set rth home altitude to -2m?

Easy improvements:
- when altitude is less than 7m and auto RTH enabled/ failsafe enabled, the altitude variation speed should be minimum, 25 cm/s (for a easy landing).(these values should be define-able) If i set 25 cm/s by default, it will take a loooong time to descent from 100m
- after reaching ground, if copter continues to descent, propellers will spin slower and slower. You could put a condition apliable only in descent with Altitude controlled mode that verifies when output throttle is less than 1300us fore more than 2-3 seconds.

Hi,

Please understand me but I don't want to make any autoland function for RTH only with BARO!
My oppinion is that RTH is made for bringing the copter back if any unwanted orientation loss/video signal loss in FPV happens.
Once it hovers on a safety altitude over home, control can be given back and land manually or continue the flight.

Autoland with automated slow down function is available in FAILSAFE_RTH routine, because failsafe means there is no any valid connection between transmitter/copter, so it must be taken down somehow. In that case autoland decreases the probability of crashes. But that's all!

A good autoland function should be taken into a separated function, for example to a switch: Take off/land position
For good autoland instead of baro and GPS, optical flow sensor and sonar must be used!
For this we need 2 things:
- optical flow sensor
- sonar sensor

We would need something like this:
https://pixhawk.ethz.ch/px4/modules/px4flow

Once sensor handling is implemented into MWI, values could be used for a SAFETY autoland feature!!! I'd be pleased to help making a good autoland/takeoff feature just like ie. in ar-drone...

So this is the reason why I would not support any improvements related to autoland except in FAILSAFE mode, I hope you understand my position.
____________________________________________

Dramida, I'll check out what happens if you fly lower than armed level!
So in my next release I'm sure it will be tested/solved if there will be any problem caused by negative value.
Please be patient for some days because it is snowing since many days here...

BR
Adrian

Hi Adrian, most if not all FrSky radio users sets the failsafe of the receiver to RTH + Baro, with throttle at midpoint. Are you suggesting that receiver failsafe should not be used?

Hi Dramida,

I can't understand your question completely.

I like the current receiver failsafe code. The trigger is that any of first four channel drops under 980 us).
Most receivers have the same option (ie. Futaba FASST, FrSky, Graupner, etc. receivers all have a programmable failsafe option, that means receiver gives a pre-defined output on throttle channel when connection is lost).
But maybe also the RSSI could be used for that purpose, ie. if the RSSI signal is under 10% it goes to failsafe mode. I don't know how accurate the rssi output on a receiver is...
For Failsafe I suggest to use the FAILSAFE_RTH mode if GPS is available, and configure well the receiver output and failsafe mode.

So why there is an autoland feature in the failsafe routine?
Because maybe the connection error is caused not by distance but anything else (empty transmitter battery, etc), so even if the copter is back at the home position, the connection can't be restored. In that case copter will land to prevent any further crashes.

For normal flgiht, I strongly recommend to take off/land manually.

BR
Adrian

nhadrian wrote:Hi Dramida,

I can't understand your question completely.

I like the current receiver failsafe code. The trigger is that any of first four channel drops under 980 us).
Most receivers have the same option (ie. Futaba FASST, FrSky, Graupner, etc. receivers all have a programmable failsafe option, that means receiver gives a pre-defined output on throttle channel when connection is lost).
But maybe also the RSSI could be used for that purpose, ie. if the RSSI signal is under 10% it goes to failsafe mode. I don't know how accurate the rssi output on a receiver is...
For Failsafe I suggest to use the FAILSAFE_RTH mode if GPS is available, and configure well the receiver output and failsafe mode.

So why there is an autoland feature in the failsafe routine?
Because maybe the connection error is caused not by distance but anything else (empty transmitter battery, etc), so even if the copter is back at the home position, the connection can't be restored. In that case copter will land to prevent any further crashes.

For normal flgiht, I strongly recommend to take off/land manually.

BR
Adrian

Yes, i agree with you about auto-landing. It's only a last resort option. Thank you for making the concept clear. So i should re-bind the FrSky receiver to discard pre-defined failsafe values.

dramida wrote: So i should re-bind the FrSky receiver to discard pre-defined failsafe values.

Don't forget that if you re-bind the FrSky receiver, on TX signal lost it will output last values! Tu use MultiWii failsafe You need to push the button on receiver, while transmitter is OFF. Then RX will stop outputting anything on TX signal loss, witch can be detected by MultiWii.

Sorry for spam, if You already knew that

You got me right!, thanks alot, i didn't knew that one!

Ok today i did try compile this code to my quad but as soon i activate the gps in code i get a fail.....
Probably because i have some config faults ....
it is a promini with gy86 and i2cgps , i will try it on my mega to see if that works better.


this is the line
//Home position reached
nav_mode = NAV_MODE_POSHOLD;
this ---->> TargetAltReached = 0; // reset parameter when switch mode
if (NAV_SET_TAKEOFF_HEADING) { magHold = nav_takeoff_bearing; }

with this fail
GPS.ino: In function 'void GPS_NewData()':
GPS:419: error: 'TargetAltReached' was not declared in this scope

Can anyone give me some tips ??

// Tazzy

Hi, please send me your config.h to nhadrian@gmail.com I'll check it.
Also, please give some info what release do you try?

Hi all,

I attached my latest release.

News:
- now it resets altitude on every arm, not only once after power on
- vario mode resolution increased (AltHold is now in mm instead of cm)
- the "gap" is removed when stick is out of the center deadband (Dramida's catch).

It is based on the official r1342 release.

I wish good luck!

BR
Adrian

Thanks for the work! Can I just replace the config.h with my existing one from your last release?

Mark_K wrote:Thanks for the work! Can I just replace the config.h with my existing one from your last release?

Alright, I answered my own question. Short answer is no...

Long answer is to windiff it and change the couple of differences.