Baseflight aka multiwii port to stm32
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Baseflight aka multiwii port to stm32
Well, an I2C-Servo or an I2C-GPS seems to be in other but that will never meet the TC's standard. Hmmm.
Re: Baseflight aka multiwii port to stm32
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.
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.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Baseflight aka multiwii port to stm32
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?
Re: Baseflight aka multiwii port to stm32
last I checked, that was the max number available on your beloved tarduino pro mini without hacks.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Baseflight aka multiwii port to stm32
I'm asking about the Naze32, how would one go about connecting eight servos to it?
Re: Baseflight aka multiwii port to stm32
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.
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.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Baseflight aka multiwii port to stm32
Thank you for the information and Yes I do care. Just don't like the BaShing at times.
R: Baseflight aka multiwii port to stm32
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
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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
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
Re: Baseflight aka multiwii port to stm32
Any chance airplane mode will be implemented ?
Re: Baseflight aka multiwii port to stm32
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 addCode: 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.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
Cool, so the MTK guy was right.
Maybe someone can figure out what's wrong.
Maybe someone can figure out what's wrong.
Re: Baseflight aka multiwii port to stm32
@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?
Re: Baseflight aka multiwii port to stm32
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.
so first servo will be pwm3, etc.
so you should have the motor plugged into pwm1.
I'm pretty sure it should be working.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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.
Your pwm init procedure is too crazy for me without some more comments. But the Problem seems to be in there.
Re: Baseflight aka multiwii port to stm32
maybe the gimbal feature is on, wich gives output 1/2 as tilt and roll of gimbal, wich are servos.
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
ok haha I will take another look and scope things out and see what's going on.
Re: Baseflight aka multiwii port to stm32
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
Re: Baseflight aka multiwii port to stm32
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
tanks
Re: Baseflight aka multiwii port to stm32
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?
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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?
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?
Re: Baseflight aka multiwii port to stm32
Did you put foam over baro and make sure there's no wind from props/etc over it?
Re: Baseflight aka multiwii port to stm32
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?
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?
Re: Baseflight aka multiwii port to stm32
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
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
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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?
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?
Re: Baseflight aka multiwii port to stm32
acc noise I would suspect.
I wonder if programmatically reducing acc influence (modifying cf factors) or increasing acc lpf based on throttle would help.
I wonder if programmatically reducing acc influence (modifying cf factors) or increasing acc lpf based on throttle would help.
Re: Baseflight aka multiwii port to stm32
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?
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?
Re: Baseflight aka multiwii port to stm32
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
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
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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!
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!
Re: Baseflight aka multiwii port to stm32
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 just need the part where an adc channel reads the voltage from pwm8.
Re: Baseflight aka multiwii port to stm32
I'll see what I can do. I did make an ACS756 breakout PCB last year, so I actually have something to test with.
Re: Baseflight aka multiwii port to stm32
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
@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
Re: Baseflight aka multiwii port to stm32
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".
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".
Re: Baseflight aka multiwii port to stm32
Yes, mostly. OK, i'll try. THX!
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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
Re: Baseflight aka multiwii port to stm32
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.
- Attachments
-
- baseflight.zip
- test version calculating standard deviation for motion detection
- (56.41 KiB) Downloaded 3048 times
Re: Baseflight aka multiwii port to stm32
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.
My testquad flies great with both naze32, hence both boards are fine. There must be another issue with my big copter. Probably vibrations.