Jump to content

Daniel Wee

Trusted Member
  • Content Count

    380
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Daniel Wee

  • Rank
    RC-Cam Mentor
  • Birthday 09/25/1967

Contact Methods

  • Website URL
    http://www.intelligentflight.com
  • ICQ
    0

Profile Information

  • Location
    Singapore
  1. Thanks Thomas, for the test. I believe the gain in performance comes directly from the reduced bandwidth. I am however, exploring some filters with far lower IL (typically 4-5dB) which would represent a 16dB improvement. Unfortunately these filters need to be custom made but it would be really interesting to see the results of such a filter. Daniel
  2. Hi anci3nt, Sorry for this late reply - I haven't been dropping by here too much lately. In answer to your question - yes the Pro version will also control the throttle channel as well as some others. It's got enough PWM channels to control pretty much everything - maybe even flaps. And yes, the idea (eventually) is that this thing will do auto-landing or at least assisted landing. We're still a ways off in terms of software development right now. Have to make sure that the hardware works first. Daniel
  3. Also to save you some trouble - I've attempted the same thing with an accelerometer in a supposedly stable hover. The way the accelerometer behaves with lateral acceleration makes it very difficult to use. It will hover for a second or two and the slightest lateral movement will avalanche into serious false data and cause the heli to flip over. So this is not just theory - it's actual test results, backed up by theory. Daniel
  4. I think your main problem will be deriving the attitude of the helicopter. Basically the same mechanism that controls your vertical thrust (that is your throttle and pitch) are directly coupled to your pitch and roll (that is the attitude). Furthermore, in order to control altitude, you will need to know your heli's attitude, so as to be able to know the thrust vector. In a sense you can think of your heli as a thrust unit with variable vector. So determining your vector relative to ground will be crucial. The accelerometer should, in theory, provide you with the attitude information. Unfortunately it is also affected by lateral accelerations and cannot be relied upon to provide attitude information on it's own under all circumstances. So, your primary challenge, is not in getting the altitude at a sufficient precision since even a 1 feet resolution will be pretty good. It will be working out the attitude, and basically keeping the heli level. Daniel
  5. 1. The system actually supports waypoints but right now only one waypoint is used - HOME. Unfortunately for this version (4.6) we've pretty much used up all available memory so under you start removing stuff, you won't be able to fit anything in. The next version will have more than enough memory for waypoints, maps, and so on. In fact it will have UAV capabilities. 2. See #1. Daniel
  6. Thomas, the info you want is in the datasheet. Daniel
  7. I'm hoping to be able to do that in a about a week or so. We're getting a small number of prototype boards made for me and a few beta testers. Once I get them, I'll be able to put the thing on a plane and tweak the performance until I'm happy with it. After that I'll incorporate it into the autopilot once I get a better feel of it's in-flight performance. Daniel
  8. My guess is that it sends a stream of serial commands to the PLL to generate the frequency. De-tuning would involve careful understanding of the PLL IC since the output is usually the product of a multiple of some fundamental crystal frequency so this isn't as easy as detuning a typical LC or even crystal oscillator. Probably the best way is to hack the firmware if possible, and you can probably get a few more channels out of that. The other problem with out of band frequencies would be the tuned circuit performance for both the transmitting amplifiers, transmission lines, and the receiver. The performance is likely to fall off a bit as you move away from the center of the tuned band. It's hard to say how much without actually looking at the circuit in question. As a last resort, it might be possible to intercept the serial commands to the PLL and inject your own commands. This way you can generate any frequency you want but it may not be reflected correctly by the controller display. Daniel
  9. One way would simply be to strap the unit to a test rig with known inclinations and test it that way. Another approach would simply be to see how well it works for the desired purpose - be it stabilization or artificial horizon. If it works, it works. Daniel
  10. In fact the systems equations aren't that complex. What is needed is to characterize the noise of the system and the covariance values. This can actually be empirically determined. In saying this, I'm also making some assumptions regarding the cross-axis influence and ignoring some other influences as negligible or linear. This allows us to keep the equations complexity manageable. As to whether this will outperform a simpler system, well that depends a lot on what that other system is. In fact by the time you tune up a PID loop to get it right, you might as well just use a Kalman EKF or better yet an SRUKF. The problem is that many people find the math a bit daunting even though the actual principle of the system is not that difficult to understand. But if math isn't a problem, the filter shouldn't be all that hard to implement. For lower powered controllers, there are a few tricks you can use to reduce the computing workload, although with the SRUKF - there's going to be quite a bit of floating point calculations so a fast MCU would be needed. The real advantage of using an alternative system, I think, is that it is more readily understood whereas the Kalman filter is initially very non-intuitive. I can't really see how those systems will in fact perform better than Kalman filter, especially when you are thinking of mass producing the units which may not allow for very precise characterization of the sensors. In the end, the proof is in the pudding. One reason I decided to pursue the EKF route (will try SRUKF later) is because so much has been said about it, and yet so little done. Everyone seems to know what it is but very few have actually put their apparent ideas to practice. The same can actually be said about alternative systems. It seems that almost every other person has a great idea of how to make a working system but I've not really seen any working models to go with those ideas. As such, one of my goals is to put an end to all the speculation and produce an actually working system. This now works although I would like to see faster convergence. Once I get the smaller prototype boards made, I'll be able to know how well it actually works on a plane. I would like to encourage those out there with ideas to actually put them to the hardware. That's what we really need right now - real world test results. Daniel
  11. In my case, I already have the Kalman filter working successfully, and working quite well too so no need for me to use less effective methods I think. Daniel
  12. Well, we could use a simpler scheme to correct for the drift but since we also use the IMU for stabilization of the plane, you will want the best estimator, and since the Kalman is a well suited optimal estimator - it is ideal for this sort of thing. Daniel
  13. Here's something to whet your appetites. Photos of the latest Dragon boards Daniel
  14. Over a period where good GPS reception is available, the GPS is within 4% of the barometric altitude, and in some cases more accurate than the barometric altitude. This may also be related to the poor implementation of barometric altitude sensors that are common, relying on single ported sensors when a proper implementation would actually call for a dual sensor arrangement. Those of you who want to know more, check out the research paper by J.D. Andrew Graham entitled "Raw GPS for Vertical Navigation". Here is a quote from that paper:- I submit to you that a lot of what's floating around as "common wisdom" regarding barometric sensors are somewhat anecdotal and uninformed by actual research. Daniel p.s. FWIW, the IMU board actually (optionally) carries an SCP-1000 barometric pressure sensor.
  15. Actually I found that even within the quarternion representation, there exists a discontinuity as you go from -180 to +180. One of the dimensions go from +1 to -1 and that will throw off the filter. Fortunately, there is a much simpler solution to this problem and I'm hoping that it will work. I've actually already written the code but a couple of wires broke off the IMU due to all the twisting while testing and I've not gotten round to actually re-soldering them just yet. Daniel
×
×
  • Create New...