search

DavidEGrayson / minimu9-ahrs

Program for reading data from the Pololu MinIMU-9 over I²C. Works on the Raspberry Pi and other embedded ARM Linux boards.
Other
167 stars 68 forks source link

typo?: pacer::set_period_ns ignores its nanoseconds #24

Closed steverpalmer closed 1 year ago

steverpalmer commented 7 years ago

Thanks for this code David,

I'm still working my way through it, but I noticed that the function pacer::set_preiod_ns does not use the nanoseconds parameter when setting the spec variable. It doesn't matter since the use of this function in ahrs requests the same time, but I thought you might be interested.

Cheers, Steve

DavidEGrayson commented 7 years ago

Oops, you're right. I'll fix that the next time I'm working on the project (or I could accept a simple pull request if you are willing to make the change and test it yourself).

Thanks for the feedback, it's nice to know people are still using my project. Are you using the Pololu MinIMU-9 v5?

steverpalmer commented 7 years ago

Another time I would be happy to do a clone/tweak/pull request, but at the moment I'm really trying to understand what the MiniIMU-9-v5 is giving me, and how the code is working. I don't think the change is difficult, but would only want to do it if I could set up a test to show that it worked properly. I may get around to it later.

Yes, I am using the MiniIMU-9-v5 and had the code successfully running on my RaspberryPi 2B. My application is to help a Pi2Go robot travel in a straight line. I've fixed the MiniIMU-9-v5 on the robot and had it driving around collecting the IMU data. After looking at your code, and some other comments, I've got a reasonable looking magnetic calibration based on a curve fitted ellipse, though it is rather noisy of course. I'm now trying to figure out how to combine the magnetic data with the more stable Gyro data. The fuse_default function uses cross products on the magnetic heading and the last rotation, which I can see works in practice, but is twisting my head around. A cross product gives me a vector perpendicular to the two arguments right? Do you have any pointers for further reading on this aspect?

DavidEGrayson commented 7 years ago

Yeah, the cross product is on purpose. If you have two vectors and you want to rotate one of them to make it be closer to the other one, the axis about which you want to rotate is the cross product of those two vectors.

I think I made up that particular fusion algorithm you are looking at and there might be better ways.