MultiWii

crazyal

Hello everyone, I don't know if it is the correct topic to post my message. I wanted to try the new implementation of "Oneshot" in Baseflight. It seems to work but i luckily (or not) noticed also something strange. I changed my looptime in the CLI to 1500 and i went to the "Motor Tes...

crazyal

try to adjust throttle mid and throttle expo. Throttle mid should be at the hovering point of your quad

crazyal

You can't disable the mag board from the CLI.
I would suggest to look at the orientation on a naze and adjust the cli variable align_mag according to your orientation.
Also make sure that align_gyro and align_acc have the same value.

crazyal

this describes it pretty accurately: https://github.com/TauLabs/TauLabs/wiki ... s#axislock
probably someone (not me) could even copy/adapt the taulabs controller to use in multiwii.

crazyal

first of all althold has nothing to do with other flight modes! it'll behave the same way whether in angle, horizon or arco mode. Also gps functions most likely won't work reliably, as the code isn't really finished. unfortionately the .hex isn't up to date, but you can try the one i linked in this ...

crazyal

it's just about the coding style, it still does the same thing. accTimesum gets converted from microseconds into seconds in the althold function. altough you are right, that can be optimized a bit. brm what were those issues with the pt1 element you mentioned ? stability issues as it's an iir filter...

crazyal

a pull req is kinda how you send your code changes to the main code repository on github.
unfortunately all the .hex i uploaded up to now are pretty useless, this one here should work. I flight tested it briefly and it seemed ok.

crazyal

hmm you broke it.. deltaT is an uint32_t data type, mutiplying it with 1e-6 and then storing it as integer made the result zero and broke the pt1 element.
I allready fixed it in the code, a pull req is on the way

crazyal

seems like brm found a bug thanks btw... i somehow totally missed that when implementing it. xeo-star it could be that the bug in the code caused your issues. Please try it again with this change. I have attached the compiled .hex for that change.

crazyal

Sure, try decreasing the values more, it basically determines how much the accelerometer influences the readings. So if you set them to 0 the copter only relies on the baro for altitude readings. If you want, I have attached a .hex with debugging enabled. Debug1 = Acceleration, Debug2 = Velocity and...

crazyal

Hi Crazyal, Thanks the reply and yep I think the acc's are calibrated. It flies really well in manual, horizon and horizon with alt hold for most of the time. Its just when I'm in horizon with mag and baro activated something triggers a full throttle signal after a bit of flying. Its also a repeata...

crazyal

please stop writing stuff without even knowing how stuff works in baseflight. if any of you knew what they are talking about you'd know that in baseflight the acc readings also influence the altitude reported. I know because i coded it you've got some nice graphs there, but i'm not sure what the exa...

crazyal

it's 16 bits

https://github.com/multiwii/multiwii-fi ... i.cpp#L268

crazyal

usually this shouldn't happen, except if you quad rotates faster than 2000dps, that's about 5.5 flips per second.
At that rate the gyroscope can't keep up anymore and the attitude estimation of the FC will be flawed.
Are you sure, that you definetly were in horizon mode and not in acro ?

crazyal

that's all there is so far:
https://github.com/multiwii/baseflight/ ... -Variables
power_adc_channel is the var to set in cli for the POWERMETER feature

crazyal

here is a graph of a naze rev5. The drift could be weather dependent tough. It was pretty windy outside when i did the warmup test. IMO the easiest solution is to just wait a bit for the board to reach a thermal equilibrium or an external temperature sensor might work too. Vibration dampening on the...

crazyal

I took vdjcs baseflight commit and cleaned it up a bit. The formatting should be allright now, but the global vars shared between gps.c and fw_nav.c are still unclean and should be changed into a clean struct according to timecop.
If anyone wants to proceed with it, here is my change: https://github.com/luggi/baseflight/com ... 8a34e52455

crazyal

As the controller controls the velocity, the stick response should definetly be better and it makes tuning easy(I never got the pids on the old althold 100% right. With the new approach it was a matter of minutes). Also it definetly behaves better when there are disturbances such as wind etc. The ra...

crazyal

imho the way to go is a cascaded pid controller like the one I implemented in Baseflight: https://github.com/multiwii/baseflight/ ... imu.c#L395 feel free to do your own implementation on multiwii. Every every flight control software with working althold uses a similar approach.
Here is an example of it working with default pids: https://www.youtube.com/watch?v=A0XaMP3PCFU (not my copter)

crazyal

First of all, thanks for this great tool! I would like to ask if the Failsafe function is functional and tested? The receiver I use only lets me set failsafe for the throttle channel, so I really like to use the failsafe function of the board. I've set 'feature failsafe' and saved. But when I turn ...

crazyal

Simply because it didn't work as well as hoped. I never really got the default pids tuned right and timecop didn't like the float pid factors, because they don't blend in nicely with the 8-bit defaults. If you like playing around with beta stuff, give it a shot and we might find some values that wor...

crazyal

But is it a #define? That's the innovative part. Recompile each time you want to change RTH height. Fuckin' brilliant. @timecop...you're clearly an uptight bastard... I'm not listening to you, you're a fuckin moron that thinks you're smarter than you really are. yes, it's a define...as are many, ma...

crazyal

Hi, I test this with defaults values and it is OK, but this parameter are not prog in CLI are this just constant ? cfg.P8[PIDVEL] = 120; cfg.I8[PIDVEL] = 45; cfg.D8[PIDVEL] = 1; Vario for althold is missing ! Also (Taboo ) GPS PH + RTH is " working again " on Naze32 rev4 with "Afro32...

crazyal

latest progress: not my video, but it's using the latest velocity based althold https://www.youtube.com/watch?v=A0XaMP3 ... ata_player
my video: http://www.youtube.com/watch?v=owIIuswYv98 sry for the bad quality

crazyal

http://microquad.blogspot.co.at/2013/04 ... oller.html

crazyal

Just for info...yesterday I have tested (in garage) the latest baseflight hex from git. ALT HOLD works now almost prefect. At default settings. Quad is in + - 20 cm I'm happy camper now. But I saw on git that there exist new VEL_PID's for baro, but I can't tune them in chrome configurator. Just for...

crazyal

hello, I found the rate of altitude change in Baro mode a little bit slow. 1.) I found a bug (?), as I tried to improve it: In IMU.cpp line 1296 the change of AltHold is computed according to the difference of rcCommand[THROTTLE] and initialThrottleHold. As I understand the code, BaroPID should be ...

crazyal

Just to be clear about what acc_unarmedcal does. As the named says the accZ vector is calibrated/zeroed when the copter is unarmed. I implemented this feature to have a simple compensation for accz offset errors which can be caused by a change in temperature or a wrong calibration. basically it only...

crazyal

I'm the curlpit who wrote this code I understand that the code isn't easy to see trough, but from what I can tell it is working fine with some small errors which probably could be overcome by doing the integration every measurement and not in the altitude loop. You are probably right about too much ...

crazyal

cGiesen wrote:
ChristianGeek wrote:This looks great...is it only for jailbroken devices or are you able to submit it to the App Store?

He told me, that he can puch it to AppStore
But we need V4 BlueTooth (about 40$)

http://www.ebay.com/itm/1xHM-10-CC2540- ... 3cd3e8942d

crazyal

looks good imho.
btw baseflight allready uses a right handed coordinate system... Y points LEFT not right... check again

all that ruckus about nothing...

crazyal

@brm Why do you keep criticizing my posts without even reading them? I already posted your NED link in order to stress that both NED and ENU are right-handed coordinate systems . All I wanted to do is to propose a new feature, which might prove helpful to some people (including me) and in the cours...

crazyal

the sensors can be aligned via setting the rotation described here: m 0 is defalult, 1= 0deg, 2=90degCW to sensor orientation(see datasheet) whereas the baseflight default sensor orientation is x-axis -> front and y-axis -> left. It should be really easy to rotate sensors that way and the mag works

crazyal

+1 I'd also like to see an eplanation to that obfuscated code

crazyal

it's actually pretty easy, just do angle[ROLL] = euler_y; angle[PITCH] = euler_z; and heading = euler_x; for the heading that is if you are also using the magnetometer with the mpu6050 otherwise don't change it. just note that heading is in degrees and roll/pitch is in degrees*10 so 100 means 10.0 d...

crazyal

that's what I did, makes no difference as far as I can tell.
here are my latest changes: https://github.com/luggi/baseflight/commits/mag

crazyal

@Gaijin: Thank you very much for your info about that headfree stuff, I was already scratching my head. Since I have no openpilot, I think that their hardware (you need SPI sensors) and software is way superior to what we have here - but how that translates to real life flight experience I dunno. @...

crazyal

No, it's definitely the formula, which includes the *ground* temperature, which is used for all aviation around the world. All barometric altitudes in the aviation for a defined area are calculated based on barometric pressure and temperature of an airport. This is not correct, but since all airpla...

crazyal

dunno if that's still up to date.
but that's a coding fail:
https://github.com/Crashpilot1000/Summe ... /imu.c#L71
let's read gyro values AFTER we calculate attitude *facepalm*

crazyal

just to be clear, the sensor orientation issue has never been resolved ?

crazyal

brm wrote:the file with the code snippets has a Copyright at the very beginning.
you obviously did not copy them.

i am not a fan doing so.

here it is just a Placebo test.
no Feedback no source code - that simple.

whatever.. your post makes no sense again.

crazyal

Oh, yes shure. Thats why it reads here m: // Chip Unique ID on F103 #define U_ID_0 (*(uint32_t*)0x1FFFF7E8) #define U_ID_1 (*(uint32_t*)0x1FFFF7EC) #define U_ID_2 (*(uint32_t*)0x1FFFF7F0) Even the comment shows Its intend: Identify the CPU and not for some softwareversion. MSP_IDENT would have been...

crazyal

for your new code ? with current baseflight everything is allready documented in mw.h you may check the sign of the baro velocity. to me you should reverse the sign. It is correct as in positive vel means going up and neg vel means going down. I didn't change that part coming from multiwii. explain...

crazyal

imho having R1,R2 and vref in the code isn't that easy to implement efficiently and the so called developers of multiwii probably won't like it.
yep SMOOTH does that, as the name suggests

crazyal

Thanks, but I don't see the main change to conf.vbatscale = (R1+R2)/R1 * vref * 10 and the definitions... Sorry, but I'm not expert in programming, otherwise I made it already myself BTW what is for vsum and VBAT_SMOOTH? + in the patch file means line added - means line removed.. so conf.vbatscale ...

crazyal

good questions basically there are 2 complementary filters which mix baro velocity with integrated acc velocity and double integrated acc altitude with baro altitude. The tuning parameters are baro_cf_alt and baro_cf_vel those factors go from 0 to 1.0f. Setting those factors to 0.9 means 90% acc rea...

crazyal

for your new code ?
with current baseflight everything is allready documented in mw.h

crazyal

JUERGEN_ wrote:.
and

When will NAZE32/FPU

with STM32F303CC

the I2C driver, timer stuff has to be rewritten etc, so when there is code that supports the new mcu

but it doesn't look like anyone including me is motivated to code that stuff.

crazyal

that was just making a point here is the real one, untested tough. Index: MultiWii.cpp =================================================================== --- MultiWii.cpp (revision 1563) +++ MultiWii.cpp (working copy) @@ -410,23 +410,15 @@ case 1: { static uint8_t ind = 0; - static uint16_t vvec[V...

crazyal

vbatpatch.zip: (303 Bytes) Downloaded 217 times

;)

Search found 84 matches