MultiWii

Well, an I2C-Servo or an I2C-GPS seems to be in other but that will never meet the TC's standard. Hmmm.

With 8 servos available in airplane mix mode, I doubt there's going to be any need for a HACK.
And with serial GPS working in both PPM and PWM input modes, what's the point for I2C GPS again? Remind me. Another point of failure? OK, thanks.

timecop wrote:With 8 servos available in airplane mix mode, I doubt there's going to be any need for a HACK.
And with serial GPS working in both PPM and PWM input modes, what's the point for I2C GPS again? Remind me. Another point of failure? OK, thanks.

Your Words: "p.s. enabled GPS in PWM mode as well - reduces number of channels to 4RC+2 AUX."

P.S. I count six motor pins, where do the other two servo pins come from?

last I checked, that was the max number available on your beloved tarduino pro mini without hacks.

I'm asking about the Naze32, how would one go about connecting eight servos to it?

There are total 14 PWM channels that can be configured as inputs or outputs in various groups.
If you truly care, have a look around http://code.google.com/p/afrodevices/so ... /drv_pwm.c

There are 6+8 header pins where things can be connected. Infact if one so wishes, the 6 motor pins can be used as RC inputs and the 8 pins on the side can be outputs etc.

Thank you for the information and Yes I do care. Just don't like the BaShing at times.

timecop wrote:p.s. enabled GPS in PWM mode as well - reduces number of channels to 4RC+2 AUX.

Great, TC! I'm sincerely grateful

timecop wrote:I have a solution that looks like a turd, I can commit it today.
Or I can spend some time on it and make it nice - something most 8bit devs dont seem to care about.

but it would be good for all who are also coding on the same project. i am waiting for your solution i nearly went back to the last commit having flying wing support. you could push those things to a feature-mixer branch and let others participate in searching for ideas.

i don't knew ho expensive merging or rebasing is with svn but i am doing this up to 20 times a day at work using git where branching and merging is low cost.

Basically the problem with current solution is lack of flexibility. Too much stuff needs to be configurable, even previous builds needed recompile. I'll bring that back in a bit w/some more options as a temporary solution (flyingwing only) but for future, proper mixer needs to be reimplemented.

edit: k, flyingwing mixer is back. airplane mixer will happen later.

as far as ideas/discussion, go ahead.
basically: it has to be configurable, nothing hardcoded, fairly flexible (i.e. completed airplane mixer would be able to do flyingwing just by configuring it as such), and be able to mix in X number required servos in whatever orientation.

thanks for bringing flying wing back. i'll test it as soon as i can leave the city.

regarding your mixer thing: what about having a set of configurable mixes like in er9x (http://www.youtube.com/watch?v=uc3TdQhNc_g). it would be enough to have those sources: rcchannels, pid loops, fixed value and a weight for each of them.

it's not that easy to implement it so it's usable in the console but it would be possible

edit: i tried it on my wing right now. mixes in gui seem ok but they aren't written to the servos. tried to add

in writeServos in mixer.c line 200 but it didn't do the job

Any chance airplane mode will be implemented ?

frog32 wrote:thanks for bringing flying wing back. i'll test it as soon as i can leave the city.

regarding your mixer thing: what about having a set of configurable mixes like in er9x (http://www.youtube.com/watch?v=uc3TdQhNc_g). it would be enough to have those sources: rcchannels, pid loops, fixed value and a weight for each of them.

it's not that easy to implement it so it's usable in the console but it would be possible

edit: i tried it on my wing right now. mixes in gui seem ok but they aren't written to the servos. tried to add

Code: Select all

            pwmWriteServo(0, servo[0]);
            pwmWriteServo(1, servo[1]);

in writeServos in mixer.c line 200 but it didn't do the job

that was the problem, it should work, no?

Remember for airplane-like stuff I rewrote PWM driver, so now M1 pin is gonna be throttle, and then servos 4+ are on M3, M4.. etc (motor pins).
Did you check there? I just commited the fix for writing servos though. This is not in the manual yet but I'll stick it there on next revision.

Gimbal wrote:Any chance airplane mode will be implemented ?

Sure, you can start on it See discussion above.

Thnx

FYI TC, I am busy building a new airplane for testing. I first need to make sure it flies well before installing a flight controller.

Yesterday I tried the latest build-218

Past 10 seconds after turn on GPSHOLD mode, system is out of control, it not response to commands and dives to the ground. After that, on the earth, i cant turn off the motors. It looks like board hangs.

Cool, so the MTK guy was right.
Maybe someone can figure out what's wrong.

@timecop: tried flying wing again. mixer seems ok. i couldn't start the motor and tried to reduce motorpwm to 50hz. i even tried probing with a servo. which pin should be motor out on flying wing? is it possible that pwm initialisation doesn't work with flying wing?

check the source - in servo/wing modes, pwm1/2 are motors, the rest are servo.
so first servo will be pwm3, etc.

so you should have the motor plugged into pwm1.
I'm pretty sure it should be working.

I enabled the new mahowik althold in baseflight since r220.
Those with freeflight/afro32 hardware can try it out by grabbing latest build. All the parameters are tunable:
acc_lpf_for_velocity = 10
baro_tab_size = 21
baro_noise_lpf = 0.600
baro_cf = 0.985
Probably start with some fixed looptime as well, 3000 seems to be a good choice.

on pwm1/2 i have valid servo outputs but they seem to be the wing servo mixes. maybe the servo mapping is wrong and it overrides motor out.

Your pwm init procedure is too crazy for me without some more comments. But the Problem seems to be in there.

maybe the gimbal feature is on, wich gives output 1/2 as tilt and roll of gimbal, wich are servos.

not it's not on and it's realy wing output i have gyro correction, and also the radio input in it and it reacts to changes in pitch_direction_r etc.

ok haha I will take another look and scope things out and see what's going on.

frog32 wrote:on pwm1/2 i have valid servo outputs but they seem to be the wing servo mixes. maybe the servo mapping is wrong and it overrides motor out.

Your pwm init procedure is too crazy for me without some more comments. But the Problem seems to be in there.

ok you were right.
in the leftover hack of remapping motors as servos when useServo was on, i also did same for airplane mix, essentially killing the motor outputs and replacing with servos.

Now it works correctly and flyingwing layout is:

PWM1 = throttle
PWM2 = unused
PWM3, 4 = servos

Only tested in PPM mode but it should be fine in PWM as well

i 've tested it today and it seems to work. i wasn't able to test fly it but the corrections are being made in the right direction, and motor is working again.

tanks

acc_lpf_for_velocity = 10
baro_tab_size = 21
baro_noise_lpf = 0.600
baro_cf = 0.985

I just soldered a baro on my FreeFLight 1.2. It showed up and I can activate it. Works fairly well but it would be interesting to tune it. The problem is that I can't seem to find a description of the parameters.

Anyone with a link or a quick description?

check the altitude hold improvement thread in software section.
There are different params needed for bmp85, both lpf and cf.
since default adxl on free flight is pretty noisy, you might want to increase lpf for velocity as well.

Thank you. I read through the thread and found this post very useful: viewtopic.php?p=22429#p22429

Grabbed the latest build from SVN and tried the following ALT-PIDS: 5 - 0.030 - 30

When looking at the data in the GUI it seemed like there was a lot of noise from the baro, so I increased the baro_noise_lpf to 0.900 and increased acc_lpf_for_velocity to 15.

My quick test today was not very good. I simply lost a lot of power when turning on the baro. The tricopter tried its best to hold the height, but with modest success. Probably because of the low power. When turning off the baro again the tri got its power back and thrusted upwards.

Any hints on what settings to adjust?

Did you put foam over baro and make sure there's no wind from props/etc over it?

Yes, the baro is well protected with foam that is letting air through. I did not loose power when turning on the baro in the previous version. But unfortunately I changed a lot of settings as well compared to what I had with the previous version, so I don't know if the loss of power is due to the new version or my current settings.

The baro is on a separate board that I soldered on to the FF with wires. The way it is mounted now is that it is inside a blob of foam on top of the board. The baro itself pointing down towards the board. Would that disturb anything? My idea is that it is measuring air pressure, so letting the hole point down shouldn't be a problem as long as it is properly covered from prop wash and sunlight. But still letting air in?

Yea, thats a good way to insulate it.
When I was testing with bmp, I was experiencing the opposite of what you're seeing... stuff would shoot UP in the air, but once a few meters up it would be decent. Anyway, Freeflight is a pretty bad combo for accZ based alt-hold - adxl345 on there (and rev1 nazes) is really noisy wihtout proper power filtering, plus vibrations will affect it more. This is why you have to use high acc_lpf in level mode. try runing up acc_vel_lpf even more and see if that helps, also you do know you can go to default settings by doing 'defaults' in console right

OK. Thank you. I'll do some more tests later today. The tri is very stable and well balanced. The T-motors are smooth out of the box and I've balanced them to perfection as well. The FF is mounted on rubber dampeners and I have no jello on my GoPro on this rig. In my quick test earlier today I had 8" props on. I'll try again with 10" props to give it some more basic power. Will report back here when I've done some more testing.

In general I am extremely satisfied with this multiwii setup. Have been flying KK, KK2, OPCC, Rabbit and Naza. But this baseflight-upgraded FF is now giving me a very reliable and stable platform for both AP, FPV and acro. Would be very nice to get the baro working a bit better for my FPV-flights.

Did some more testing and now it is working much better. Didn't change any settings, but got rid of the 8" slowflyers and installed some GWS 3 blade 9" props. And now it keeps the height very well. The only thing I can compare it to is my Naza and rabbits with the old and new baro. The naza is still a step better, but my FF with baseflight is now actually close to the Naza. Both my rabbits are a joke in comparison. When they're not falling out of the sky due to bugs they keep the height with an accuracy of 20 meters or so. Even the one with the new baro.

So, with the settings I mentioned in an earlier post and the 9x5x3 props the FF holds height within 30 cm or so.

But: it is doing some strange pulsating when giving full throttle with the baro turned on.

Too high P, I or... D for altitude?

acc noise I would suspect.
I wonder if programmatically reducing acc influence (modifying cf factors) or increasing acc lpf based on throttle would help.

If I understand you correct the FF is disturbed by both physical vibrations and electrical noise. I've ordered one of these: http://www.readymaderc.com/store/index. ... cts_id=533

And will put it between the battery and the power input on the FF to reduce electrical noise. I'll also experiment a bit more with the settings. But I can't seem to find any good descriptions of exactly how the different baro-adjustments work. This is my idea so far:

lpf = low pass filter. So:

acc_lpf_for_velocity
Increasing it will filter out high frequent input from the acc. So, a low value will let the acc influence throttle (height) even for small vibrations. A high value will only let the acc influence throttle for bigger movements of the copter.

baro_noise_lpf
Increasing it will filter out any small changes in pressure and only let the baro kick in for bigger changes in pressure. I already have this pretty high (0.900).

But for these I'm completely blank:
baro_tab_size = 21
baro_cf = 0.985

And for altitude PIDS the D will adjust how fast the main loop will react on altitude? And P+I will adjust how fast the copter should react on baro input?

at least 1 mag axis is reversed on this 32bit board due to pcb layout
http://www.goodluckbuy.com/kcopter-stm32f103cbt6-flight-control-board-with-itg3200-bma180-hmc5883l-ms5611.html

copter is pointing north, but in gui arrow shows south (180 degrees shift).
pitch axis is reversed, roll and Z is ok as it seems for now.

here is a picture of the board, showing a flying direction with red arrow and zoomed MAG chip letters orientation.



not a big thing in acro flying as you can see below,
board flies great with mag off
http://youtu.be/jpGn16prTj4



but I'm planning to hook up an GPS, there it will render it useless.
because it uses mag to turn to an coordinate(home or pos hold) and keep the heading,


please, is there a way to reverse the readings, via some command in ''putty serial''?
if not, can someone compile baseflight.hex with a fix?

in mwii it's just a matter of ''-'' in front of that axis in 'defines' tab, but this 32bit is too new for me at the moment to deal with it.


thanks a lot

yes someone needs to code a way to dynamically swap and invert sensor axes without too much performance hit.
A solution very close to good has been posted before, but still not optimal. compiling stuff by non developers is out of the question. When implemented, it would be a CLI option.

@eirikso - I'm not sure, might be better off asking in the original thread for mahowik alt hold, but I think the consensus there is that adxl sucks for this purpose.

so, for now
the only way to fly that IMU(and GY86 I have, same mag orientation) is on good old 8bit atmel?
ordered this shield:
http://www.goodluckbuy.com/kcopter-mult ... opter.html

hope developers will come upon a solution,
performance is not everything, keep that in mind.

you're welcome to submit patches for the features you want added.
This is not supported because apparently no one cares enough to code a solution.
seems you want to make use of different oriented sensors, start coding.

Now this tricopter with Baseflight is starting to behave very well. Including altitude hold.

Running a FreeFlight 1.2 with Baseflight and have added a baro as well. A couple of LOS-clips to test stability and some nice FPV clips after that:

https://vimeo.com/50946967

As you can see the latest altitude hold code works very well. Because it is no wind it is hanging there like it was position hold. With no input from me... And baseflight gives that nice locked in feeling in rate mode. Rock solid and also very nice for AP. Some vibrations in some of the clips due to a crash earlier in the day that made the tail arm slightly loose. Easy to fix and my best advice for all is to remember loctite on ALL screws!

What about bringing powermeter back? I have an ACS756 current sensor on my plane and it would be great to be able to use it in my osd which i integrated into baseflight. I tried to mess around with the adc and the dma but i didn't manage to measure anything with it and even killed vbat measurement while trying it. how much beer (or something else) do i have to donate to have this done by someone who knews better about the internal hardware than me?

I just need the part where an adc channel reads the voltage from pwm8.

I'll see what I can do. I did make an ACS756 breakout PCB last year, so I actually have something to test with.

It looks like there is something wrong till r229. Can't get any gyro movement with my rev0 naze32. Any ideas?

@TC: I just want to thank you. Yesterday my third naze32 arrived after just about 10 days in Berlin. These boards are just soo cool

Green light is always on, right? go to cli and set moron_threshold=64 + save
its the new anti-shaking stuff and depending on the gyro noise (I think mpu3050 is a bit noisier) default 32 is not enough to detect "idle".

Yes, mostly. OK, i'll try. THX!

It worked, but that's strange, I have another naze32 of the same revision and that one worked without the problem. I had the one with a problem mounted on a copter which flew, but It always felt like a drunken sailor, even without ACC.
I moved the naze32 to my test quad to check the behavior now. Maybe its just a very noisy sensor or there is something broken.

The calculation is kinda stupid, it should depend on absolute change from center (i.e. post-sensor offset) but instead it depends on absolute change from 0, before applying offset. Maybe I'll rewrite the motion logic to take that into effect. Anyway, setting it to 64 will work - its not sensor's problem but it depends how large initial bias is, which could be bigger in some revisions of mpu3050

arne wrote:It worked, but that's strange, I have another naze32 of the same revision and that one worked without the problem.

please try the attached build.
its same version as what's in latest svn except different algorithm is used to detect gyro motion (which should be better than dumb average I used before).

leave moron_threshold at default (32?) and see if it trips on any of your boards.

The modifed baseflight is working fine out of the box, but I did a quick test on the desk only. THX.

My testquad flies great with both naze32, hence both boards are fine. There must be another issue with my big copter. Probably vibrations.