MultiWii

I can't help but I noticed the beeping as well when I set up my rate profiles on the weekend.

Guys, am i the only one having issues with the Android App "Naze32 configurator" and CF @ Naze32 board?
Just wanted to confirm befor i post an issue @git

MäX

FinalGlide wrote:I can't help but I noticed the beeping as well when I set up my rate profiles on the weekend.

Ok, so maybe it is a common issue which still needs to be fixed.

Update: according to Dominic this should be fixed in the latest binary. Will test it this week. Thumbs up
Update of the update: All good. The latest binary works perfectly

Cleanflight and OneShot work fantastically on an FPV mini quad Dominic. Thanks again!
https://www.youtube.com/watch?v=D8ZgDsHPY8k&list=UUuibbKUX0wT5yie0_EM0Smw

Hi Guys,

Can you point me to where I can learn about what the different commands do? I tried the the Multiwii wiki, and I found some there, but not all.

For example. I was trying to find out what set thr_mid = 50 is referring to. Maybe setting the # that allows the multirotor to be stable in the z axis when the throttle is at 50%?

I would like to mention that the cleanflight project now has support for JRPropos XBus Mode B serial receivers.
From the documentation:


Thanks to all people involved in baseflight/cleanflight that makes it possible for us to enjoy this hobby!
Merry Christmas!

I just tried the latest GUI and it's brilliant. Thanks again guys!

Hey all, Trying out cleanflight on a naze32, Am i missing something with setting up RX_Serial feature on cleanflight or is there a current issue with the Gui or firmware?
As I can not get cleanflight to save the rx_serial feature, I can get the box to be ticked then when hit save it just goes unticked again, also same thing happens when trying to enable it in cli.
Also can not set alignment above 180 of the board on yaw axis unless in cli (wont allow 270 board alignment yaw when in GUI board alignment, baseflight is the same with this one).
last thing will Multiwii EZ Gui for android work with cleanflight?
If i cant get at least RX_serial working i will have to go back to baseflight or i cant fly

In order to get RX_SERIAL to save, you must have completely configured the serial port, i.e. provider and sceanrio. See Serial.md, and Rx.md. For example (Spek Sat).

Works fine.

Is there a detailed explanation of these settings anywhere? So I don't have to ask for more help

I found it lol, one more thing does any of that set the data pin that you connect serial rx to or is that unchanged from baseflight

For Spek Sat, pin #4.

Thanks heaps, also for pid tuning with pid controller 1 is there a difference in what p i or d do or is it the same as pid controller 0, also pid controller 2

Pid controller 1 pids are going to similar- the difference is that adjusting PIDS does not have an appreciable affect on RC Roll and Yaw rates- this was always an annoying problem with Pid Controller 0. In addition the yaw PIDs act differently and in many cases better and easier to tune (to many things to describe here).

Pid Controller 2 incorporates floating point coefficients, so in some cases is more accurate and smoother. You have to be careful with this controller- generally you need to start with lower P t erms, and much higher I terms. This controller isn't fully vetted out, and doesn't receive much support- so be careful.

Thank you HFman and all the guys above that helped me, very much appreciated

If roll & pitch rate was used in pid controller 0 to decrease the pids and allow more let go rotation, and is no longer effected like this on pid controller 1 , then does roll & pitch rate still actaully do anything at all in pid controller 1.. if you can follow what i mean to say

Hello everyone, I am new here, got a naze32 for christmas and decided to get involved.
First, big thank you to tc for great hw and hydra for is leadership. And everyone else who is involved.
Did my first CF flight yesterday and everything was fine except a little jumpy on the z in baro mode. After reading, i can see, it will need tuning.
I will participate in many ways but for now here are a few features that I would like to propose:
Optical flow stabilization (like in the inspired)
RTH without gps like what we were using in the old days (before gps for you young kids) for transcontinental flights, using INS (inertia navigation system).
I know, these are far fetch but I just like to put somethings on the horizon...
Going to go get some led strips now!
P.S. I can test flight test new code any time.

Paulyz wrote:If roll & pitch rate was used in pid controller 0 to decrease the pids and allow more let go rotation, and is no longer effected like this on pid controller 1 , then does roll & pitch rate still actaully do anything at all in pid controller 1.. if you can follow what i mean to say

Absolutely it works. But the Roll & Pitch rates won't seemingly change as you adjust the PIDS. On pid controller 0, if you cranked up the 'P' term on roll or pitch, their respective roll/pitch rates felt as if they were decreasing, even though their value was not changing. This does not happen when using pid controller 1. You still have full ability to adjust Roll & Pitch rates, no matter what pid_controller you select.

I tried GPS Hold today with the 14th December firmware with GPS improvements. Much better than previous versions. Thanks to whoever took the time to make the improvements that were needed. I had 9 sats and it held position to within about 2m whereas previously this was more like 12m or not at all.

The feature does exactly what it says it will do, i.e. "hold", as in when I hover in a position and flick the GPS Hold switch it tries to maintain its position. If I then apply some pitch to force it away from it's hold position, when I release the pitch it will try to recover it's hold position. Is there a way to make it behave more like a helper, whereby when in "GPS Assisted" mode if all sticks are released it will hold the position where the sticks were released?

Any thoughts appreciated

uk-Pedro wrote:I tried GPS Hold today with the 14th December firmware with GPS improvements. Much better than previous versions.

Hi Pedro! Thanks very much for posting your feedback, it was me who took the time to investigate what was going on with the GPS code, further improvements are planned for the future.

Can you open a feature request on the github issue tracker (link in 1st post) with your idea and if someone's up for creating the feature then they will have a place to discuss it. It doesn't sound very hard to implement though.

Can you tell us more about the GPS receiver you were using and how you mounted it? A link and a photo or two would be great.

Just a heads up, I upgraded today my Naze32 board to the latest GUI and firmware (as of today).
When trying to set the mixer to tri in the configuration tab, it does not save the change, it reverts to quadx. It saves in CLI as it should.

dominicclifton wrote:Hi Pedro! Thanks very much for posting your feedback, it was me who took the time to investigate what was going on with the GPS code, further improvements are planned for the future.

Thanks Dominic, excellent news - I look forward to more improvements...

dominicclifton wrote:Can you open a feature request on the github issue tracker (link in 1st post) with your idea and if someone's up for creating the feature then they will have a place to discuss it. It doesn't sound very hard to implement though.

I've opened a new issue #270 (I hope that's how it's done)

dominicclifton wrote:Can you tell us more about the GPS receiver you were using and how you mounted it? A link and a photo or two would be great.

The GPS receiver I'm using is this one: http://www.ebay.co.uk/itm/321625467280

It's mounted above the battery in a cheap case, close to the CofG in terms of X and Y but above it of course. Have a look here:


Cheers,
Pedro

After reading here: https://github.com/cleanflight/clean...cs/Failsafe.md

Using a cppm connection

I tried the default failsafe values, and it does not seem to activate when I turn off the TX.

So, I changed the values to:
(min and max values are the endpoints of the TX)

failsafe_delay = 10
failsafe_off_delay = 50
failsafe_throttle = 1200
failsafe_min_usec = 1107
failsafe_max_usec = 1932

If I watch the receiver tab in the CF GUI, when I turn off the TX the values freeze at the last throttle stick position.
If I disconnect the battery (the FC is receiving power from the USB) then Failsafe activates.

What do I do to get the FC to recognize when the receiver is lost?

Dave Pitman wrote:If I watch the receiver tab in the CF GUI, when I turn off the TX the values freeze at the last throttle stick position.
If I disconnect the battery (the FC is receiving power from the USB) then Failsafe activates.

What do I do to get the FC to recognize when the receiver is lost?

I think the trick is to tell the RC receiver to not send pulses to the flight controller when the signal is lost. It appears that the way to do this is to set the failsafe on the receiver with the radio turned off, at least for FrSky receivers.

2bluesc wrote:I think the trick is to tell the RC receiver to not send pulses to the flight controller when the signal is lost. It appears that the way to do this is to set the failsafe on the receiver with the radio turned off, at least for FrSky receivers.

It is not an FrSky RX, but maybe it is the fault of the RX and nothing can be done? This RX is not configurable, and FrSky is still on the wish list.

Is this the normal behavior for the barometer when the quad is resting on ground? And what is the scale for X, meter?

Airdrone wrote:Is this the normal behavior for the barometer when the quad is resting on ground? And what is the scale for X, meter?

I wondered the same thing a the other day after installing a barometer on my Naze32 and haven't been able to test my barometer just yet. I think it is valid. The scale on the right side says "meters" and I think I recall hearing that the accuracy using the barometer is about 1 meter, so it seems to make sense. For reference, mine looks like this:



Hopefully someone with experience with altitude hold can chime in and confirm.

I am trying to achieved smooth level flight. Seems difficult. I know, I was told this board is for acro, not for smooth flight, but I want to give it a try. That baro sensor has a resolution of 10cm. CF should be able to maintain the attitude within that, but it is not happening. During my test flights in boro mode, the quad doesn't maintain the altitude, but oscillate about the same that we see in the graph when the craft is resting on the ground. CF seems to react well to what the sensor is reporting, but the reporting is wrong... It is no use to have a resolution of 10cm, if the reported values oscillate +/- 1 meter.

hi dominic,

I found an error in the latest firmware !!!
I connected serial rx with sumH, everything ok, BUT the rc ranges displayed in the gui are NOT correct anymore!
in the radio I have the range "1000-2000us", but in the gui is displayed "875-2125", cleanflight somehow "expands" the range, so it is not correct anymore ...
I tested this with an older firmware version, there everithing is displayed correctly, so it must be an error with the latest changes.


and one other thing, I would like to connect a gps to my naze32 rev5 board, but I only can find documentation for connecting it to "pin4" (uart2), but there is my serial rx already connected!
can I connect the gps maybe at uart1 or softserial ports, and how to setup that ?

greetings

joachim

Doesn't the fine documentation help, in particular example (d) (for the GPS case)?

stronnag wrote:Doesn't the fine documentation help, in particular example (d) (for the GPS case)?

I have read that, but there is "gps passthrough", I thought this is "passthrough" or sth. does it mean, I can connect gps on softserial1 ?
that would be great ... I try that.

and I have another problem, ... can I output channel 5 of my serial rx input to a standard servo on the naze board ? channel5 on my receiver doesnt work, if I use telemetry, so I would like to connect a servo on the naze board insted ? is that possible ?

greetings

joachim

wildflyer wrote:hi dominic,

I found an error in the latest firmware !!!
I connected serial rx with sumH, everything ok, BUT the rc ranges displayed in the gui are NOT correct anymore!
in the radio I have the range "1000-2000us", but in the gui is displayed "875-2125", cleanflight somehow "expands" the range, so it is not correct anymore ...
I tested this with an older firmware version, there everithing is displayed correctly, so it must be an error with the latest changes.

I found out, the error is only in rx_serial mode, in ppm mode it is ok ...

Hi,
first post in this forum, repost from RCGroups - hope for somebody knowledgeable here;)

"Any Idea why I would see no rX on PWM input? I have an Devo1202, connected all 8ch, am connected to the TX and powered up, but nothing in the gui?

This is a board on default settings, so RX_PARALLEL_PWM is on and about nothing else.
I've tried setting filtering on, no difference.
I switched 22/11ms on the RX, no difference (not sure where to change this in CF)

Any other ideas?"

Edit: Works fine ootb with an Orange RX620x. Weird.
Edit2: A LemoRX 10ch works fine as well via PWM. I assume the Rx1202 is defective:/

Thanks and keep up the good work:)
---------------------------------------------------------------------------
Edit3:

Can I use any Serial Connection (eg GPS) when using a PWM receiver? The hardware pins are blocked this way ...
Do i see it right that the best type of receiver is PPM/SUM since it only uses a single port and does not block any of the others (compared to s.bus) ?

I cannot find, where I can set alt_hold mode for use with "middle-stick" like naza (throttle stick in the middle is alt hold)...

in multiwii I could set that in the source code, but where in cleanflight ?

HI All,
I stumbled across this device the other day, NXP PCA9685 and wondered if it would be possible to integrate it into the Cleanflight code for driving extra servos on flight controllers that don't have any spare pins?

I thought it might be a good option for folks who want retractable landing gear, camera gimbal or extra switchable outputs, controlled by spare RC channels.

Datasheet: http://www.nxp.com/products/lighting_driver_and_controller_ics/i2c_led_display_control/series/PCA9685.html

ADAFRUIT 16-CHANNEL 12-BIT PWM/SERVO DRIVER - I2C INTERFACE: http://www.adafruit.com/product/815

I'm not a programmer, so this is just a nice idea from a layman, for your consideration.

Thanks for looking!

HI,

i put the last (december) version of cleanflight in my mini quad and without any tune it flows very well (see video). I just increase the rates for make flips and rols.



im loving this firmware and following the development. Im a developer too but i dont understand nothing abour hardware or microcontrollers programming to help this project.

today i start the build of my new mini quad and when i try do connect the 4th esc i see the magic smoke. I think my esc burnt but its ok, what smoked was my naze and the output for motor 4 its no working.

i almost throw away my naze but i see a guy in the rcgroups with same problem and it solve using custom mixer making the 5th output work as the 4th. (http://www.rcgroups.com/forums/showpost ... count=6787 )

he uses:
"go into the CLI
at the prompt type the following commands (enter after each)
mixer custom
cmix load quadx
cmix 5 1 1 -1 -1
save
Plug M4 motor into M5 output and see what happens..."


if i use the same mixing, it will work in cleanflight? the problem with this solution its that i cant use motor tab to test the 4th motor and after i upgrade firmware i have to remember to ther is a better way to do this, like remaping the outputs?

One last question, i have a tbs disco with naze32 full and its flying well. The firmware its very old and i cant use the current baseflight gui to change anything. I want to test cleanflight with this quad too but i cant read the current pids. There is a way to get the current baseflight pids for a older firmware version? if i put the same pid values in the last cleanflight firmware it will fly the same way?

thank you so much!

nevermind

Once again, the configurator has been silently updated, which breaks everyone's ability to update anything on their quad.

To even retrieve settings requires the use of a third party terminal program, despite there being a perfectly good CLI tab in the configurator...

This is especially frustrating when developers like me are working on improvements to the cleanflight codebase, and now can't even access the settings on my quads. I now need to not only download the latest code, but backport my changes into the latest codebase, just to get the configurator to talk to my boards again.

Dominic, have you heard of the concept of "Loose coupling"? Can you see how this is not being applied to the configurator, as regards to communication with boards (that had the latest code a week ago)?

Most software lets the user decide if they want updates to:

1. Update Automatically (usually a bad idea)
2. Be notified, but not update. (My preferred choice, lets you prepare if needed.)
3. Not look for updates at all.

I'm not sure why a development team (Cleanflight) would want to deviate from this norm? I don't have knowledge specific to Chrome Apps, but I would think that these basic rules could be adhered to.

Dave Pitman wrote:Most software lets the user decide if they want updates to:

1. Update Automatically (usually a bad idea)
2. Be notified, but not update. (My preferred choice, lets you prepare if needed.)
3. Not look for updates at all.

I'm not sure why a development team (Cleanflight) would want to deviate from this norm? I don't have knowledge specific to Chrome Apps, but I would think that these basic rules could be adhered to.

Not sure this is the norm. Unless updating the users out of the picture is the idea. Baseflight did the same thing! No way to save your current setup before updating the firmware, but firmware required to use the App. BS!

Updates should never BE imposed on users. That would include Chrome, as it has crippled apps with auto updates.

For those complaining about auto-updates, you did agree to have them in the EULA after all, but this is how you can disable them if you want to:
For apps/extensions: http://www.dslreports.com/forum/r266534 ... to-updates
For Chrome: http://www.chromium.org/administrators/ ... to-updates
I've never had a problem with auto-updates anyway.

P.S. Remember this is free software. You didn't pay for it, nor does anybody owe you it. So some more politeness would be fitting imho.

I've installed both versions of the configurator. No problem.

Remember this is free software. You didn't pay for it, nor does anybody owe you it. So some more politeness would be fitting imho.

I don't know how you perceive the comments above as impolite?

The auto-updating of the configurator has not been a problem for me, I save dumps that I can re-enter. The other comment was from someone who is working on developing code (for free) to possibly enhance Cleanflight and the auto update can be a pain for him and others doing the same thing.

There are too many solid 'free' applications that provide the courtesy of letting you choose when you want an update to bother naming. Do you auto update all the apps on your phone? If you do, you are brave.

I am among the many who appreciate Dominic and team's work. This is just basic protocol here. Cleanflight is about programming the right way, correct?

markus1234 wrote:I've installed both versions of the configurator. No problem.

Being a DA, could you explain how to do this and where to get the previous configurator? On that note, how do you keep both from updating with the next rev?
Keep in mind that not everyone is a computer savvy user.

@ Turdsurfer
In reading all EULA's word for word, I know that I have agreed to let them bury me where ever and whenever they want.
But backwards compatibility shouldn't be forgotten.
How would you use your current windows without DOS? Yes, I know, you use Linux, right?
All your USB 2.0 devices are obsolete because they came out with USB 3.0?

Are you saying that you don't donate or that we don't donate?

@ RC_Adik: Here is the way I've done it, maybe there is a better way:

1. get the required version from "https://github.com/cleanflight/cleanflight-configurator/releases" and unpack it
2. I'm using chrome, open the url "chrome://extensions/"
3. check the box "developer mode"
4. click "load unpacked extension" and select the folder form 1. That's it

I'm using a german version, so there may be differences of the names of buttons and check boxes.

Perhaps rather than whinging, someone should log a feature request for the configurator: "ability to preserve and restore, or at least dump previous board settings prior to flashing new firmware"?

Me, I appreciate all the hard work that's going into this. Once GPS support is solid, Cleanflight will be the go-to firmware for just about everything multirotor.

strepto wrote:Perhaps rather than whinging, someone should log a feature request for the configurator: "ability to preserve and restore, or at least dump previous board settings prior to flashing new firmware"?

Me, I appreciate all the hard work that's going into this. Once GPS support is solid, Cleanflight will be the go-to firmware for just about everything multirotor.

Good luck with the feature request.

And, quit whining about the gps, they are working as hard as they can!

Dave Pitman wrote:

strepto wrote:Perhaps rather than whinging, someone should log a feature request for the configurator: "ability to preserve and restore, or at least dump previous board settings prior to flashing new firmware"?

Me, I appreciate all the hard work that's going into this. Once GPS support is solid, Cleanflight will be the go-to firmware for just about everything multirotor.

Good luck with the feature request.

And, quit whining about the gps, they are working as hard as they can!

Where on earth in that statement was he whining about gps! Chill people.

strepto wrote:Perhaps rather than whinging, someone should log a feature request for the configurator: "ability to preserve and restore, or at least dump previous board settings prior to flashing new firmware"?

Me, I appreciate all the hard work that's going into this. Once GPS support is solid, Cleanflight will be the go-to firmware for just about everything multirotor.

I did this yesterday:

https://github.com/cleanflight/cleanfli ... /issues/40

https://github.com/cleanflight/cleanfli ... /issues/41

I don't have a problem with the configurator auto-updating, I have a problem with way that new versions make no attempt at backwards compatibility.

41south wrote:

Dave Pitman wrote:

strepto wrote:Perhaps rather than whinging, someone should log a feature request for the configurator: "ability to preserve and restore, or at least dump previous board settings prior to flashing new firmware"?

Me, I appreciate all the hard work that's going into this. Once GPS support is solid, Cleanflight will be the go-to firmware for just about everything multirotor.

Good luck with the feature request.

And, quit whining about the gps, they are working as hard as they can!

Where on earth in that statement was he whining about gps! Chill people.

It was an attempt at sarcasm...sorry.

The only "whining" is being done by folks that I guess only want to hear praise and glory, and not frank discussion. If there are users of the software that have issues with the software, then they are free to respectfully voice their issue. Some people call this whining I guess, but I doubt that mind reading is something Dom and Co. are good at, so they probably rely on feedback..no?

I'm more than happy to put this dribble to bed, unless someone else wants to jump in and tell others what they should want (whine in other words. )