minimu9-ahrs icon indicating copy to clipboard operation
minimu9-ahrs copied to clipboard

typo?: pacer::set_period_ns ignores its nanoseconds

Open steverpalmer opened this issue 7 years ago • 3 comments

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

steverpalmer avatar May 07 '17 08:05 steverpalmer

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?

DavidEGrayson avatar May 07 '17 15:05 DavidEGrayson

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?

steverpalmer avatar May 07 '17 15:05 steverpalmer

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.

DavidEGrayson avatar May 07 '17 16:05 DavidEGrayson