MultiWii

jevermeister wrote: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.

Nils, I do think that alt hold need some more development...but I love LED code and buzzer functions. They are very usefull and they can really save your multicopter more often than GPS and Baro functions.

Luciano

flyman777 wrote:...
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.
...

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!!!!!!
...

alexia wrote:[
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)

To me this does not look like a wish.
You better realize this is a wishlist in the ideas section. It is _not_ a demands list nor is it an order form.
Diminishing other people and their work is by no means an appropriate approach.
You are addressing people who offer their time and work for free. Obviously you already use it. So start now and show them and their work some respect.

That is the last I have to say to you.

Hamburger wrote:

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,

Just between you and I, when talk first started about adding a Baro to these multi-rotor copters, I had a gut feeling it was not a good idea. One of the subjects I really enjoyed in school was methodology, and the Barometric pressure changes are unbelievable even within a 10 foot radius. I have two Baro here (one on the ST32 and one from Jesse) and have don't lots of bench testing. With both boards completely stationary, props not running, the readings were all over the place. Under flight conditions, we have to add to that the pressure differences created by the spinning props. So, trying to improve on the Baro is just a waste of time in my opinion. As to how Naza is holding altitude, I don't know because it is a close system but I strongly believe using the GPS altitude as a REFERENCE only to compensate for ACC-Z drift is the simplest way for now.

Termic1 wrote: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.

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...

Luciano,
you are welcome to express your ideas and wishes for MWii future development; that is whole point of having this thread. I am sorry your post got in the line of arguments.
Just curious, for minimum altitude during RTH would not the max altitude be sufficient (and safe)?
If you want to contribute, you can always donate some of your time to help others and add to the documentation wiki

@copterrichie
the entire alt.hold thing is not in my focus, I do not follow its development, even less the discussions.
I take it as is.

Hamburger wrote:Just curious, for minimum altitude during RTH would not the max altitude be sufficient (and safe)?

I mean that it would be nice if you can define a specific altitude (i.e. 20 meters) where the multicopter should go before returning home. The goal is that if you are flying low and far (i.e. FPV) and you need to come back in emergency the quad raises approx to this altitude and than it starts coming back avoiding trees or other obstacles. Don't know if this is possible at this stage

Hamburger wrote:If you want to contribute, you can always donate some of your time to help others and add to the documentation wiki

This is what I'm doing in our Italian forum (http://www.baronerosso.it) helping other to make their multiwii working. I'm also contributing in testing functions (like GPS) and reporting test results and videos. My english is poor so I do'nt know if I can contribute to add documentation. But if there are some topics to cover I can try...

Ciao!

Luciano

Lu cano,
That is cool.
I did not mean you would have to do all of the above:)
Have fun. It is a hobby, right?

Hamburger wrote:Luciano,
That is cool.
I did not mean you would have to do all of the above:)
Have fun. It is a hobby, right?

...absolutely yes...it's a great hobby!
Luciano

Hi,

I understand the hope to have a better alt hold mode, and it's normal to wish
It's also my hope and one of my priority.
I know it is possible to achieve something much more solid than what we have, or at least less dependent from the parameter tuning.

The problem I personally encounter to make it better:
* This is a function that need an open space space to test it. So It's basically something almost impossible to run multiple tests at home if you live inside a flat with no green outside => I can only test it once on the field with only few adjustments, reducing the possibilities to find empirically something interesting. Hopefully, we have some code contribution we can test.
* This function seems to be one of the most complicated to tune.

Besides this, multiwii can evolve and there is no need to freeze it as long as the function are well isolated and won't interfere with the control code. (for instance Buzzer, LED, LCD, Serial)
There are multiples devs, and this is not a mono focus project.

Termic1 wrote:

Hamburger wrote:Luciano,
That is cool.
I did not mean you would have to do all of the above:)
Have fun. It is a hobby, right?

...absolutely yes...it's a great hobby!
Luciano

With some, it's just a hobby, great hobby, with others, it's the passion.

Alexinparis wrote:* This is a function that need an open space space to test it. So It's basically something almost impossible to run multiple tests at home if you live inside a flat with no green outside => I can only test it once on the field with only few adjustments, reducing the possibilities to find empirically something interesting. Hopefully, we have some code contribution we can test.

I totally agree with Alex, as the ALT HOLD even GPS POS HOLD, with an enough/solid height, my tricopter nearly glued to the sky, not any movement (looks like a high-end wookong naza system), but at low height, it never want to stop, it goes around. Of course it's "factory" ALT PID settings.

I think the current code is good enough and acceptable, the HOLD characteristic is different from kit to kit. So with the "end-users", choosing Multiwii mean you want to know how it works, want to do much DIY stuff, want to read alot for a good knowledge and want to tweak. The cool developers have built a very interesting system, just for free, the users/players should spend time to tweak, tune and feedback (if willing) instead of demanding/asking for the cooler thing . Wishlist is just a wish list, feel free to spread your ideas.

Thank Alex and all of the others coders for make this cool open-source project, love multiwii!

@Hamburger: Probably you can move those two into submitted to _shared:
Sport flying mode with stabilization (If I properly understand/use Horizon mode)
PID calculations at a constant time interval (probably your implementation)

And it is probably worth mentioning Shikra / PatrickE's addition of HexaH

Regards Andrej

Hello everybody,

May I make a request to add another command to MultiWii protocol for setting IMU data ?
The name could be MSP_SET_RAW_IMU and the code could be 210, currently not used.
Currently I'm implementing MultiWii protocol for STM32 on a home built prototype board:
https://code.google.com/p/cortex-ap/.
The additional protocol command would be useful during simulations.
Sensor data coming from flight simulators as X-Plane would be sent to the board replacing data froma actual sensors.
I did not find a similar request in the posts. Sorry if it's been already asked, anyway.

Thank you.

Lorentz

Lorentz,
maybe you best double post your proposal to the serial protocol thread.
Alex is in charge of the serial protocol. He may not find it here and your proposal would go unnoticed.

lorentz wrote:Hello everybody,

May I make a request to add another command to MultiWii protocol for setting IMU data ?
The name could be MSP_SET_RAW_IMU and the code could be 210, currently not used.
Currently I'm implementing MultiWii protocol for STM32 on a home built prototype board:
https://code.google.com/p/cortex-ap/.
The additional protocol command would be useful during simulations.
Sensor data coming from flight simulators as X-Plane would be sent to the board replacing data froma actual sensors.
I did not find a similar request in the posts. Sorry if it's been already asked, anyway.

Thank you.

Lorentz

Hi,
what would be the interrest to run multiwii code on a board where the sensors are not tied ?

crashlander wrote:@Hamburger: Probably you can move those two into submitted to _shared:

done.

Alexinparis wrote:Hi,
what would be the interrest to run multiwii code on a board where the sensors are not tied ?

Running simulations on the MW algorithms. I have been thinking about this same thing, but haven't had the time to do anything about it, as it would allow running a simulated copter under a myriad of conditions and assert how multiwii code reacted. Great for trying new approaches without spending too much money

@Hamburger: done. Thank you for the advice.
@frogstarb: thank you for the reply to Alexinparis question, I couldn't have esplained better.

Regards

frogstarb wrote:

Alexinparis wrote:Hi,
what would be the interrest to run multiwii code on a board where the sensors are not tied ?

Running simulations on the MW algorithms. I have been thinking about this same thing, but haven't had the time to do anything about it, as it would allow running a simulated copter under a myriad of conditions and assert how multiwii code reacted. Great for trying new approaches without spending too much money

very good idea

Waypoints + Android GUI = perfection!
A better pos hold would be cool, even alt hold based on gps. Baro just doens't work gread in a windy day.

I would be happy to help with android GUI, I bought a tablet to do just that! and other stuff too...

Some of us we are facing problem to align all motors to the same power level during the setup.

so i think that it would be great , if it's possible , to make an "auto level motor function" !!!

NikTheGreek wrote:Some of us we are facing problem to align all motors to the same power level during the setup.

so i think that it would be great , if it's possible , to make an "auto level motor function" !!!

you need to make sticks min 1000, mid 1500, max 2000 (or as close as possible)
and use the DEADBAND value.

otherwise, the gyroI always sees an error and will drift the motor speed.


My wishlist is to make all configurable parameters in config.h be settable from the GUI. its a major pain to have to reflash just to change one thing. I know other FC software has this feature. Thanks.

doughboy wrote:My wishlist is to make all configurable parameters in config.h be settable from the GUI. its a major pain to have to reflash just to change one thing. I know other FC software has this feature. Thanks.

the lcd.config menu has other/more options to tune than the GUI. Enable it in config.h; use lcd.textstar or lcd.vt100 as display type.
Then run arduino IDE and connect from its terminal. Ignore the control chars displayed, navigate with your tx. Use the stick cheat sheet if unsure about stick combos.

it will not be possible to control everything in config.h like that. the defines used there control the compiling of huge code segments. the only way to achieve yoir goal would be to compile everything and enable/disable it afterwards.that would lead to huge code an a massive memory load. the config.h is made to keep the code fast and small. IMHO there is no need to alter the config.h all the time.
nevertheless: there are some parameters that could be variables (vbat and gimbalvalues etc) nils

exactly. You do not change the gyro&acc sensors attached to a copter's board too often. But you may fly with varying weight due to different batteries, attached camera, etc. and need to adjust the failsafe throttle accordingly.
It is acceptable to recompile and upload firmware in first case but not in the latter. That's about what describes current strategy for lcd.conf tunable settings from config.h

so everything that does not use defines is a parameter and should not be there right?we should define a new set of params. alex is that possible with the serial protocol? i do not want to bloat stuff because here are a lot of usera that do not need this stuff.

it will be great to have a reverse fonction for motors..it will be easier to mount his motor without desoldering if it s not in the good direction
i don t know if it s possible ..

jevermeister wrote:it will not be possible to control everything in config.h like that. the defines used there control the compiling of huge code segments. the only way to achieve yoir goal would be to compile everything and enable/disable it afterwards.that would lead to huge code an a massive memory load. the config.h is made to keep the code fast and small. IMHO there is no need to alter the config.h all the time.
nevertheless: there are some parameters that could be variables (vbat and gimbalvalues etc) nils

good point and I totally agree and want to keep code small.
but how about for features added already via define that takes parameters?
like GYRO_SMOOTHING, DEADBAND, etc.?
It would be nice to be able to change the value via GUI or serial command.

doughboy wrote:good point and I totally agree and want to keep code small.
but how about for features added already via define that takes parameters?
like GYRO_SMOOTHING, DEADBAND, etc.?
It would be nice to be able to change the value via GUI or serial command.

The NAZE32 had the right idea with its CLI serial Interface however this feature would be impossible to implement on the ATMega328. Just not enough memory.

alexia wrote:it will be great to have a reverse fonction for motors..it will be easier to mount his motor without desoldering if it s not in the good direction
i don t know if it s possible ..

Unfortunately that's not possible. The Firmware just sends a pulse signal to the ESC that defines the speed, not the direction. You would need to have ESC firmware that would be capable of reversing the direction. Right now, the only way to achieve this is by exchanging motor cables.

Would be cool to be able to set magnetic declination from the GUI.

luanlmd wrote:Would be cool to be able to set magnetic declination from the GUI.

It's one-time config

vpb wrote:

luanlmd wrote:Would be cool to be able to set magnetic declination from the GUI.

It's one-time config

Not when you travel a lot

Please make CAMSTAB pitch and roll input channel adjustable

more infos ( patch included )
viewtopic.php?f=7&t=2498
viewtopic.php?f=7&t=1507

arne wrote:Please make CAMSTAB pitch and roll input channel adjustable

more infos ( patch included )
viewtopic.php?f=7&t=2498
viewtopic.php?f=7&t=1507

I have made this mod on my hexa and it works perfect im also hope this can be a function in next release;)

Adding Graupner digital signal SUMD 115200 Baud. I just try it on a MEGA2560 with MX-16 HoTT and GR-16. Reason for me is that fine little GR-12SH+ receiver has no PPM sum signal.

Not sure if this has already been addressed, but the CRIUS LCD doesn't work since v1.9. I know there's a way to get it working again by flashing the firmware on the LCD, but it would be nice not to have to do that...

What about waypoint flying ? Most FC have this function.

[s]just wondering if sonar is to be added to next ver or not? [/s]

found in change log it is in
I felt all my MRs fly much better with mwc over APM.. sonar will really be helpful for close ground acro (~1.5m)

and GJ

xoxota wrote:Not sure if this has already been addressed, but the CRIUS LCD doesn't work since v1.9. I know there's a way to get it working again by flashing the firmware on the LCD, but it would be nice not to have to do that...

which board are you using? my crius lcd works flawlessly on Crius SE, and still good on AIO Pro, all with 2.1 version.

heideflieger wrote:Adding Graupner digital signal SUMD 115200 Baud. I just try it on a MEGA2560 with MX-16 HoTT and GR-16. Reason for me is that fine little GR-12SH+ receiver has no PPM sum signal.

+1

heideflieger wrote:Adding Graupner digital signal SUMD 115200 Baud. I just try it on a MEGA2560 with MX-16 HoTT and GR-16. Reason for me is that fine little GR-12SH+ receiver has no PPM sum signal.

+2
But than for more than 8 channels! Like Spektrum!

Just a smal wish from those who use the Poor-man's TX called Turnigy 9x or familiar with a sum signal. After all those experiments finally figured out the proper sequence for the CPPM.

#define SERIAL_SUM_PPM THROTTLE,ROLL,PITCH,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Turnigy 9x

And I am sorry if this is already known. It was just a small idea.

Are you sure? I use my turnigy 9x (i find it to be very capable when used with a FrSky module) with

#define SERIAL_SUM_PPM ROLL,PITCH,THROTTLE,YAW,AUX4,AUX1,AUX2,AUX3

Aux channels are reordered because I use some mixing there ... but why is Throttle you first channel? Is that a mode 1 turnigy 9x?

is that order dependant on the FrSky transmit module or the TX firmware?
As a consequence:
Should the description mention FrSky or T9x?

Channel order is set by the T9x ... FrSky (or whatever module is used) just transmits the ppm signal it gets from the RC. I suspect The_Assistant is using a mode1 T9x?

This is strange, this is what I use with ER9X with FrSky mode 2:

#define SERIAL_SUM_PPM THROTTLE,PITCH,ROLL,YAW,AUX1,AUX2,AUX3,AUX4 //For 9X KeesvR

KeesvR wrote:This is strange, this is what I use with ER9X with FrSky mode 2:

#define SERIAL_SUM_PPM THROTTLE,PITCH,ROLL,YAW,AUX1,AUX2,AUX3,AUX4 //For 9X KeesvR

You can select the channelorder in the menus in the radio.
Or in eepe in general settings (Channel Order for templates)

On open9x you cant change channel order only stick axles orders.
Me with Frsky.

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