MultiWii

happul3

Thanks happul3, looks like you have spent decent amount of time looking into it. What approach did you take to set the alt pids? Here is an example of alt hold I had before m I have never managed to achieve anything similar with MW Nice build, nice stability. And yes, I have similar stability in no...

happul3

You asked for the views. Here is mine After spending good amount of time collecting real-time logs of sensor inputs and tuning PID controller in-flight, I've concluded that MW althold code is adequate, at least for the set of sensors I use (MS5611,MPU6050). I've built three very differently sized mu...

happul3

I know what is velocity multiple by time, but... If quadro will increase in altitude, than stops, so acc_Alt will be still higher and higher because you impute vel*dt in every cycle.. understand me what i am meaning? Words "increase in altitude, than stop" mean that initially vel is posit...

happul3

witc68 wrote:Well in baseflight is
I do not understand why there is .... accAlt +=..... + vel * dt - why +vel*dt ? Can ynyone explain it?

Seems straightforward: velocity multiplied duration produces distance traveled (=change in altitude in this case).

happul3

Hi, So my question is: How can I get distance (altitude) from accelerometer (probably oddouble integration of accel.)... SO what are the steps to get it? I do not think you can do that practically with the regular hardware. Acc is just too noisy to integrate twice. It works fine to augment baro inp...

happul3

I wrote it from scratch. Have not thought about license. What's the least restrictive terms? Pubic domain, right?

If that's the case, I declare it pubic domain

happul3

Bench and flight tested, but only briefly. Use at your own risk. //lut-based atan2, returns angle in 0.1 degree units, granularity varies between 0.1 and 0.2 degrees, max absolute error 0.05 degrees int16_t atan2_tbl[256] = {0,2,4,7,9,11,13,16,18,20,22,25,27,29,31,34,36,38,40,42,45,47,49,51,54,56,58...

happul3

There is an interesting asymmetry between angle[ROLL] and angle[PITCH] calculations. The former one is fairly straightforward, using two elements (z and x) of estimated gravity vector. But the latter is more complicated, and I am baffled as to why. It costs tens of microseconds to produce square roo...

happul3

Can anyone shed some light on specific reasons why gyro and acc rounding (adding 256 before >>9) was taken out in 2.4? It was introduced in v2.3, but is no longer present in 2.4. - better gyro & acc calibration accuracy (r1546) http://www.multiwii.com/forum/viewtopic.php?f=7&t=3880

happul3

Leo Until now my understanding was P - means how much copter should relay on the baro sensor. Higher the value is, stronger the copter relays on the Baro reading. I - is used to compensate drift costed by battery voltage drop during the time. Higher the value is faster the copter will react to volt...

happul3

Leo BTW, regarding your PID settings, after my ROLL/PITCH/YAW tuning I have very close results to yours. I wished I could achieve the same on the ALT HOLD settings. I am going to try to re-seat the board and better dump vibrations. Thanks for your advice about the other forum thread, it is very int...

happul3

Isn't there a redundancy in the following MW code? delta = imu.gyroData[axis] - lastGyro[axis]; // 16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800 lastGyro[axis] = imu.gyroData[axis]; DTerm = delta1[axis]+delta2[axis]+delta; delta2[axis] = delta1[axis]; delta1[axis] = ...

happul3

originally had 4Hz (0.25 sec) update rate for send_Temperature(); and send_Time(); while other data are updated once a second. It is trivial to change overall update rate I did not mean update rate but delay. Do you think delay is less when i use higher update rate? Possible, will have to check. By...

happul3

Yes, the exaggerated vertical movement was my concern in that example sketch. If the FC was mounted in the center VS the wingtip, they are going to see different accelerations during a turn. Maybe I'm over-thinking this and the distance issue would be negligible. I reviewed the IMU code - although ...

happul3

I can't say I understand meaning of four arrows in your drawing, so I'll respond generally about roll. For clarity, we need to make a distinction between roll itself and transitions to/from roll. Let's ignore transitions for a moment. During roll itself one wingtip is higher, other is lower. This st...

happul3

Perhaps someone can steer me in the right direction to research this a bit more? Curious if anyone has attempted to apply correction values for an accelerometer that is not installed in the center of the airframe? I have an application that would put the sensing unit a fair distance from the center...

happul3

re-uses of FLD-02 display "real estate" I do the same thing. I display distance to home and course to home. But i have found the whole frsky telemetry / FLD02 thing is very very slow. It takes over a second from transmitting a value to having it displayed on the FLD02. Steering a car/boat...

happul3

Hi. I'm also wanting to use a MultiWii as a sensor data logger but I'm wanting to broadcast the data via Bluetooth. So has anyone got any ideas where to start of if anyone is or has done anything similar? Cheers. It is very simple to send any sensor, motor, stick,etc. values via BT. You do not need...

happul3

Are there other proposals (other use of acceleration entries, other use of RPM, other use of temperature) ? Good to see that telemetry will be incorporated in official version at some point soon. Personally, I've been using multiwii telemetry code fished from old threads with my own cosmetic modifi...

happul3

Wouldn't angle mode do what you want if you use pitch trim on the transmitter to set desired attitude? Alternatively, you should be able to trim ACC while airborne, which gives the same net result (I never tested that functionality myself, though).

happul3

When you mount your motors straight on to a frame the yaw is caused by the drag of the props (rotation speed). Thats a small force that almost never provide a fast and good yaw authority. You have to make sure that the distance between the motors (pair) are exactly the same. E.g.: if distance betwe...

happul3

Hi Guys, I currently finished a build with the following components. DJI f450 clone Witespy EV3 Blackboard Sunnsysky 2216 900kv Rctimer 30amps esc I noticed as said in the subject that my yaw speed differs from the two directions. My clockwise seems to be sluggish even feels that its struggling to ...

happul3

Vibration dampening on the FC won't give you much better results. You can also do the low pass filtering in software. Probably the main problem is in the sensor fusion of the baro and the ACC. A kalman filter might do the trick instead of a complementary one(not an option on 8-bit). I agree - vibra...

happul3

Are you sure that the drift you observed is temperature-related? Have you established that it is repeatable and reproducible or is it one time observation? If it is the latter case, there is one explanation that does not have anything to do with your baro sensor. People sometimes forget that atmosph...

happul3

But I'm a bit surprised by this statement about accZoffset: ...it varied from 4980-4982 when copter was level, and 4960-4963 when tilted 90 degrees. At rest and levelled and after properly calibrating acc my MPU6050 provides a value of exactly 4096 = 8 * acc_1G, rarely floating by +/- 1. When I til...

happul3

Limited experimentation I did suggests that the limiting factor in purely barometric altitude control is NOT the sensor itself but the pressure transients produced by props and airspeed (that includes both wind and horizontal movement of copter). As hang glider pilot I have experienced firsthand jus...

happul3

I am glad we got this sorted out.

And, yes, the accZoffset is approximately 512*8. For example, last time I examined it, it varied from 4980-4982 when copter was level, and 4960-4963 when tilted 90 degrees.

happul3

Just imagine the case if the bank/pitch angle were 90° when arming, accZOffset would be vanishing. I think this particular quoted sentence provides perfect illustration of the point of confusion. To put it bluntly, contrary to your expectation, the accZOffset is not at all vanishing when copter is ...

happul3

I've just verified it with my copter: accZ is zero whenever copter is stationary, regardless of whether it is level or tilted 45 degrees. It only deviates from zero when the copter's vertical velocity is changing, exactly as intended by good people who wrote multiwii. Note that its primary use (the ...

happul3

I don't have copter handy to verify experimentally at the moment, but as far as I remember the accZ is not supposed to change with orientation (at least when approximate math is in acceptable range?) The raw acc values are indeed affected by orientation relative to gravitational vector, but the accZ...

happul3

Calibrating on level surface followed to moving to non-level surface should not adversely affect validity of accZoffset. That value is affected only by acceleration. In other words, do not arm if copter it is not stationary. It may be helpful to you if you make slight modification to code: debug1=ac...

happul3

If by 'regular' you mean bipolar junction transistor (BJT), they can certainly be used a switches, albeit less efficient ones. The turn-off time is inherently slower, the voltage drop (collector-emitter vs source-drain) is usually larger, controlling is done by current rather than voltage for MOSFET...

happul3

Hi happul3! Sorry for my mistake. I am so much into the terminology of my own stuff that I mixed it up. In my former post the "I" should have been a "D". I use the gui delivered "D" term just for anglecorrection so it is a PD controller. I omitted the errorintegration ...

happul3

As promised, examples of althold pid values effects. Hopefully the attached images will help someone

: So-so tuned PIDs. Notice minor, but noticeable oscillation.

: This is what I consider nicely tuned althold. There is some variation due to very light but gusty wind

: This is an example of poorly tuned PID values. The D is too small, P is too large, which results in P-induced oscillation

: And this is what too high I value can cause in combination with P value too low - I-term-induced oscillation.

happul3

Thank you very much happul3 for wrapping your head around that subject! Concerning the "I" part you can diminish it (with a lower limit like 50%) according to the highterror during "vario" hightchange. I currently just do it during Autostartsequence to get quicker off the ground...

happul3

looks good, you could improve the response with ignoring the d-term for a few baro measurement cycles. set the counter for example to 10 when you detect a different altitude hold settings. when the counter is active, aka > 0, then ignore the d-term in the pid calculations. Thanks. I agree, the resp...

happul3

Finally, I got to test the proposed change in altitude hold code. The logic behind the fix seemed flawless, but I was half-expecting that there is something I missed and the test would reveal that. Well, imaging my joy when the improved code worked exactly as intended on the first try. It produced c...

happul3

And it doesn't compile because rcCommand isn't visible from inside the PID loop scope. I suspect the second version will have a similar problem with dterm_temp. As I mentioned, I have not tested the code, so it is no big surprise that it does not compile. But it is easy enough to make it compile. I...

happul3

I was not able to test "the fix" yet, but I suppose there is nothing wrong with sharing something untested if there is interest. Please go ahead and check it out, carefully, that is. in MW2.3, IMU.cpp replace BaroPID -= constrain(conf.pid[PIDALT].D8 * alt.vario >>4, -150, 150); with BaroPI...

happul3

The problem is with implementation. Alt hold where "hover" is on "center stick" and moving it up or down controls rate of climb/descent. This is fail. Ok, so you do not like the basic premise of alt hold. You are certainly entitled to dislike whatever you like (pun intended). I'...

happul3

OK, that's OK. But there is still my problem with the Outputs. Every Pin (A0 to A4) I can configure as Input. And I can meassure the Voltage Levels. But I didn't get it work as an Output... Please help me out. Is there any way to debug this with trace messages? And if yes, how can I display these t...

happul3

Pardon my potential ignorance about the jargon, but what do you mean by "vario-based" altitude hold? To me, (sadly former) hang glider pilot, vario means an instrument measuring vertical velocity. The actual measurement is of course not of velocity itself, but of barometric altitude, follo...

happul3

imho the way to go is a cascaded pid controller like the one I implemented in Baseflight: m 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: m (not my copter) Hm...

happul3

Folks, There is something about algorithm of altitude hold that does not make much sense to me. When stick is "neutral", it seems to be proper - the P term (and I term) responds to altitude error as intended. The D term cleverly implements damping using mostly inertial input. That is actua...

Search found 44 matches