Search found 44 matches
- Thu Jun 02, 2016 2:53 pm
- Forum: Software development
- Topic: improving altitude hold
- Replies: 4
- Views: 2840
Re: improving altitude hold
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...
- Thu Jun 02, 2016 2:35 am
- Forum: Software development
- Topic: improving altitude hold
- Replies: 4
- Views: 2840
Re: improving altitude hold
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...
- Sun May 08, 2016 12:10 am
- Forum: Software development
- Topic: Altitude - accelerometr and baro
- Replies: 10
- Views: 4404
Re: Altitude - accelerometr and baro
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...
- Sat May 07, 2016 6:43 pm
- Forum: Software development
- Topic: Altitude - accelerometr and baro
- Replies: 10
- Views: 4404
Re: Altitude - accelerometr and baro
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).
- Sat May 07, 2016 12:30 am
- Forum: Software development
- Topic: Altitude - accelerometr and baro
- Replies: 10
- Views: 4404
Re: Altitude - accelerometr and baro
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...
- Fri May 06, 2016 11:55 pm
- Forum: Software development
- Topic: faster _atan2 - saves about 0.13 ms cycletime
- Replies: 2
- Views: 1837
Re: faster _atan2 - saves about 0.13 ms cycletime
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
If that's the case, I declare it pubic domain
- Fri May 06, 2016 2:23 am
- Forum: Software development
- Topic: faster _atan2 - saves about 0.13 ms cycletime
- Replies: 2
- Views: 1837
faster _atan2 - saves about 0.13 ms cycletime
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...
- Tue May 03, 2016 3:17 am
- Forum: Software development
- Topic: angle[PITCH] vs angle[ROLL]
- Replies: 0
- Views: 1339
angle[PITCH] vs angle[ROLL]
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...
- Wed Apr 13, 2016 5:20 am
- Forum: Software development
- Topic: gyro/acc calibration rounding disappears in 2.4?
- Replies: 0
- Views: 1527
gyro/acc calibration rounding disappears in 2.4?
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
- Sat Aug 29, 2015 11:52 pm
- Forum: Software development
- Topic: Multiwii 2.4 ALT Hold calibration
- Replies: 26
- Views: 9993
Re: Multiwii 2.4 ALT Hold calibration
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...
- Fri Aug 28, 2015 3:38 pm
- Forum: Software development
- Topic: Multiwii 2.4 ALT Hold calibration
- Replies: 26
- Views: 9993
Re: Multiwii 2.4 ALT Hold calibration
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...
- Tue May 12, 2015 2:58 am
- Forum: Software development
- Topic: Code redundancy?
- Replies: 1
- Views: 1594
Code redundancy?
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] = ...
- Thu Apr 16, 2015 6:56 pm
- Forum: Software development
- Topic: FRSKY telemetry integration into Multiwii 2.4 has started
- Replies: 71
- Views: 33056
Re: FRSKY telemetry integration into Multiwii 2.4 has starte
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...
- Thu Apr 16, 2015 12:00 am
- Forum: Software development
- Topic: Off-Center Installation
- Replies: 8
- Views: 2870
Re: Off-Center Installation
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 ...
- Wed Apr 15, 2015 5:28 am
- Forum: Software development
- Topic: Off-Center Installation
- Replies: 8
- Views: 2870
Re: Off-Center Installation
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...
- Wed Apr 15, 2015 1:22 am
- Forum: Software development
- Topic: Off-Center Installation
- Replies: 8
- Views: 2870
Re: Off-Center Installation
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...
- Tue Apr 14, 2015 4:46 am
- Forum: Software development
- Topic: FRSKY telemetry integration into Multiwii 2.4 has started
- Replies: 71
- Views: 33056
Re: FRSKY telemetry integration into Multiwii 2.4 has starte
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...
- Wed Apr 01, 2015 11:54 pm
- Forum: Software development
- Topic: Using controller as data logger
- Replies: 6
- Views: 2610
Re: Using controller as data logger
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...
- Wed Apr 01, 2015 8:45 pm
- Forum: Software development
- Topic: FRSKY telemetry integration into Multiwii 2.4 has started
- Replies: 71
- Views: 33056
Re: FRSKY telemetry integration into Multiwii 2.4 has starte
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...
- Thu Sep 18, 2014 6:41 pm
- Forum: Software development
- Topic: attitude lock mode?
- Replies: 8
- Views: 3546
Re: attitude lock mode?
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).
- Thu Jul 24, 2014 9:03 pm
- Forum: Ideas
- Topic: Different Yaw Speed for clockwise and counter clockwise
- Replies: 6
- Views: 3391
Re: Different Yaw Speed for clockwise and counter clockwise
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...
- Thu Jul 24, 2014 6:06 pm
- Forum: Ideas
- Topic: Different Yaw Speed for clockwise and counter clockwise
- Replies: 6
- Views: 3391
Re: Different Yaw Speed for clockwise and counter clockwise
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 ...
- Mon Jun 16, 2014 4:52 pm
- Forum: Software development
- Topic: Barometer drift with Temp
- Replies: 35
- Views: 12193
Re: Barometer drift with Temp
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...
- Sun Jun 15, 2014 12:17 am
- Forum: Software development
- Topic: Barometer drift with Temp
- Replies: 35
- Views: 12193
Re: Barometer drift with Temp
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...
- Fri Jun 13, 2014 7:39 pm
- Forum: Software development
- Topic: Altitude Hold improvement solution
- Replies: 580
- Views: 1579971
Re: Altitude Hold improvement solution
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...
- Thu Jun 12, 2014 6:56 pm
- Forum: Software development
- Topic: Altitude Hold improvement solution
- Replies: 580
- Views: 1579971
Re: Altitude Hold improvement solution
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...
- Thu Jun 12, 2014 5:01 pm
- Forum: Software development
- Topic: Altitude Hold improvement solution
- Replies: 580
- Views: 1579971
Re: Altitude Hold improvement solution
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.
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.
- Thu Jun 12, 2014 3:34 pm
- Forum: Software development
- Topic: Altitude Hold improvement solution
- Replies: 580
- Views: 1579971
Re: Altitude Hold improvement solution
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 ...
- Wed Jun 11, 2014 11:49 pm
- Forum: Software development
- Topic: Altitude Hold improvement solution
- Replies: 580
- Views: 1579971
Re: Altitude Hold improvement solution
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 ...
- Wed Jun 11, 2014 7:52 pm
- Forum: Software development
- Topic: Altitude Hold improvement solution
- Replies: 580
- Views: 1579971
Re: Altitude Hold improvement solution
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...
- Tue Jun 10, 2014 5:29 pm
- Forum: Software development
- Topic: Altitude Hold improvement solution
- Replies: 580
- Views: 1579971
Re: Altitude Hold improvement solution
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...
- Tue Jun 10, 2014 5:01 pm
- Forum: Software development
- Topic: brushed motors
- Replies: 11
- Views: 7940
Re: brushed motors
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...
- Wed Apr 30, 2014 6:46 pm
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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 ...
- Wed Apr 30, 2014 3:17 am
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
As promised, examples of althold pid values effects. Hopefully the attached images will help someone
- Wed Apr 30, 2014 12:03 am
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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...
- Mon Apr 28, 2014 10:55 pm
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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...
- Mon Apr 28, 2014 2:38 am
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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...
- Sat Apr 26, 2014 12:38 pm
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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...
- Sat Apr 26, 2014 12:09 am
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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...
- Fri Apr 25, 2014 5:17 am
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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'...
- Fri Apr 25, 2014 2:45 am
- Forum: Software development
- Topic: BUG_NANOWII: Use AUX1 and Buzzer OVERRIDE_BUZZERPIN_PINMODE
- Replies: 12
- Views: 4783
Re: BUG_NANOWII: Use AUX1 and Buzzer OVERRIDE_BUZZERPIN_PINM
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...
- Fri Apr 25, 2014 12:48 am
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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...
- Wed Apr 23, 2014 1:22 pm
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Re: Altitude hold agorithm
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...
- Wed Apr 23, 2014 2:31 am
- Forum: Software development
- Topic: Altitude hold agorithm
- Replies: 34
- Views: 11723
Altitude hold agorithm
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...