|
|
Post by Frisbone on Aug 25, 2015 7:18:29 GMT -5
This chip is an IMU (inertial measurement unit) but instead of just having an accelerometer it also has a gyro and a compass. With this and the library I found that drives it using Kalman filters I'm hoping to bypass all of the headaches of my past use of the other accelerometers (ot perhaps identify what I did wrong). The output is supposed to be a reference angle. Since my goal is to translate to joystick movements I'll want to ignore one of the axis (depending on how it is mounted) and then determine delta angle samples to convert to a movement vector.
So I was able to connect this to my board and run the calibration test. I had to remember to run in super-user mode as well as copy the ini file into the Output directory I was using. The INI file was changed to specify bus #1 first.
Not entirely sure I did the calibration correctly but I didn't get any errors.
Next step I suppose is to run the demo program.
|
|
|
|
Post by Frisbone on Aug 25, 2015 10:42:33 GMT -5
So I ran through RTIMULib build procedures (found I needed to install cmake first). Best option I had was to create a build directory underneath RTIMULib/RTIMULib-master/Linux and run there. Instructions were not clear on the proper place but it was pretty clear that a "txt" cmake list file needed to be one directory up from it and there weren't very many of those that made sense. I realized in the end that I should be using 'qmake/make/sudo make install' out of the RTIMULibDemo and RTIMULibDemoGL directories instead (I believe it installs the library in a global location somewhere).
To run the demo program (RTIMULibDemo) I needed to export my display (export DISPLAY=127.0.0.1:1.0) and allow all users to run x (xhost +localhost), then I could type "sudo ./RTIMULibDemo".
Seemed to run ok for a bit but then received a FIFO overflow error.
|
|
|
|
Post by Frisbone on Aug 25, 2015 13:27:53 GMT -5
Integrating this device is going to be more difficult than I originally thought. If indeed the library's purpose is to only produce absolute angles then some of the other actions dependant on the accelerometer (like jump & raise/lower weapon) will be left out. I'm hoping there is a way to get both. But in either case there is no simple driver substitute as much of the current code outside of the AMDriver is meant to translate AM data into angles (which would not be needed for the RTIMULib library use). Need to find a clever way to integrate this.
|
|
|
|
Post by Frisbone on Aug 25, 2015 15:24:51 GMT -5
I couldn't get the graphical version of the demo to run because it said X11 lacked openGL (I assumed that was what the error message meant anyway) so I updated raspbian in the hopes that a later version of X11 was available with OpenGL compat. After the OS update my I2C device disappeared and I went to this URL: www.raspberrypi.org/forums/viewtopic.php?t=97314Hoping this does the trick to get it back. |
|
|
|
Post by Frisbone on Aug 30, 2015 12:03:40 GMT -5
So I was able to get my code running and I've dwindled the actions regarding the device down to what I thought was exactly what the demo program RTIMULibDrive was doing but I'm not getting the same results using the RTIMULib.ini file. The Driver seems to react immediately to my changes in pose whereas my program has a 1-2 second delayed reaction and then it swings, then swings back almost counteracting the original displacement.
Seems like something else I'm doing must be interfering with the device. Will probably have to eliminate things one by one to track it down.
|
|
|
|
Post by Frisbone on Aug 31, 2015 14:46:45 GMT -5
Looking into it further it seems as though it is a timing thing. Polling too slow will cause it to hang while polling too fast will cause it to generate queer data. Not thinking now it is an issue with my code interfering rather than the timing of polling just not being right (or perhaps consistent enough). Seems as though a true ISR would be helpful (instead of a simulated one) - but not sure the RTIMULib supports it.
|
|
|
|
Post by Frisbone on Aug 31, 2015 17:44:01 GMT -5
Leaving things as a simulated ISR I focused in on 50Hz sampling of the AM/Gyro and making sure my software was sampling at no faster (and not slower). What I saw as a result was seemingly accurate data but slow to respond to movement in the output data (which is outputting at about 5 times per second.
The bigger issue is that eventually (after anywhere from 15 seconds to 1 minute) the data goes sour and not representative at all of actual position. Each axis goes haywire by tens of degrees (constantly changing) and no longer responds correctly to relative movement (it responds, but then kind of bounces back to its preferred values). During one run it seemed to pull itself out of the state and return to normal behavior. Another instance seemed to indicate that moving the device triggered the problem.
Strange. Looking like I'm going to have to delve into the IMU code more. But I definitely should get the latest from the repository since what I started with was from last december. UPDATE: I did this, and it made no difference in this particular problem I'm seeing. At least I'm up to date now.
Its also possible I think that there is something amiss with the wiring to the board and that it is causing poor readings. I already know that something is causing it (the board) to simply not be recognized sometimes - perhaps that issue is an intermittent one that is related to this issue as well? One thing arguing against this is that resetting the software corrects the problem - if it were a wiring problem you would think that it would continue upon reset.
|
|
|
|
Post by Frisbone on Aug 31, 2015 18:01:58 GMT -5
Some notes about axis behavior: Roll (based on mounting the board lengthwise along the gun (long side along length of gun - Y axis arrow pointing to gun tip) with the top of the board facing up:
- Clockwise rotation results in Z increasing in value (yaw)
- Lifting the edge of the board that the Y arrow points to results in an increasing Y (roll)
|
|
|
|
Post by Frisbone on Sept 1, 2015 16:35:17 GMT -5
Well after changing a number of things I finally figured out some of the issues:
1. PWM processing was introducing a variable causing the IMU not to be read on time. I created a separate software ISR thread that operates at a higher priority that I think solves this problem.
2. The ellipsoid was never configured properly. You need to copy the RTEllipsoidData directory to be parallel to your running directory and have "octave" installed on the system in order to calibrate it.
3. I upgraded to the latest RTIMULib - there were definitely a number of changes to the 9150 in it (who knows how important.
4. But the big item was that even though I was polling at the same rate as the sampling there would be some times where multiple samples were already waiting to be read (perhaps due to my delays in reading the samples). This creates a FIFO overflow situation that creates the weirdness (my "haywire" comment).
With all the PWM code commented out I can duplicate the RTIMULibDrive program now and get smooth results. Now its a matter of figuring out what exactly to do with this data in the context of ITC and slowly re-introducing things I commented out.
|
|
