Woohoo! It works! The "on screen" Gizmocopter rotates the same as the real Gizmocopter.
There was a few week delay since I was caught up in doing a whole bunch of unrelated stuff, then trying to remember what all I had done and why when I did get back to it. I attached an 'idle' function to the gtk_main loop to handle reading the IMU and updating the model position. (for those who don't know - gtk is a windowing library built on the XWindow system for *nix - the idle routine is what the app does when there is nothing else to do - which is the vast majority of the time.) The IMU reading and initialization functions came straight out of the console based test app I wrote back when we got the IMU. There was something in it that caused a segmentation fault in the gtk library. Fortunately, it was in a "nice to have" bit of code rather than "must have" code, so commenting it out fixed the problem and did not introduce any other problems. It just took several hours and lots of hair pulling before I figured it out. The rotations are done using quaternions. I discovered that most of the example code on the web and in a certain book has fatal flaws. I went back to Kuiper's _Quaternions and Rotation Sequences_ and re-read several portions. Then I was able to immediately spot the mistakes in the example code, and correct the code I borrowed from the examples. Another place I got tripped up was that the math libraries do rotations in radians and OpenGL does it in degrees. No big deal, but had me scratching my head for a bit as I was looking for errors in the quaternion algorithms rather than the data I was passing into the quaternion routines and than passing to OpenGL. Next up is to add a routine to determine the exact gravity vector by taking a lot of samples from the IMU while motionless at the fixed frame origin. Right now the "on screen" vehicle drifts because the conference table the real Gizmo is sitting on is not level and will be more of a problem when it starts off from a parking lot or grass field. Also needing to be done is some profiling and optimization. I'm doing something terribly wrong, as the code works great on my high end workstation (dual Opteron and Quadro4 980 XGL graphics card), but isn't doing so well on my laptop, even though my laptop is no slouch either (2.0 Ghz Pentium4M, ATI FireGL graphics). Add in that 3D games are far more complex and have no problems at all on either machine. Dave -- David Masten <[EMAIL PROTECTED]> _______________________________________________ ERPS-list mailing list [EMAIL PROTECTED] http://lists.erps.org/mailman/listinfo/erps-list
