This is the LSM9DS1 on the Elev8 flight controller. I've had similar results with an ITG3200 in the past.
Thanks. I was thinking really hard about whether or not I should spring for the LSM9DS1... I guess I should have . I'll move forward with the L3G though and see where it gets me in terms of real-world stability. The upgrade to the LSM9DS1 shouldn't be hard in the future if I decide it's not good enough. Thank you for all your help!
I used an ITG3200 on a quad *without* an accelerometer or any auto-leveling and it was freakishly stable.
Watch around the 40 second mark:
That's just integer integration, and stabilizing each of the three axis independently, like having a heading-hold gyro on each axis.
Remember that you're integrating these values, so noise is fine as long as it's relatively low and not biased in a particular direction. Your orientation estimate will look more like a moving average of your numbers. I suspect it'll be fine.
Remember that you're integrating these values, so noise is fine as long as it's relatively low and not biased in a particular direction. Your orientation estimate will look more like a moving average of your numbers. I suspect it'll be fine.
Oh that's a very interesting point I hadn't thought of. The accelerometer is more important to be filtered/averaged (though at only 2% weight, maybe not?) but the gyro is inherently a rolling average filter.... so perhaps running a higher sampling rate (such as the 250Hz you're using) rather 100 Hz + averaging would be better.
The quad in the video above had a PASM loop running at 2KHz, accumulated samples at that rate, divided by 8, and passed the result to the main integration loop running at 250hz. Then I just made the sampling loop run at 250hz and don't think I could tell the difference.
The accelerometer is an interesting one - I use a median filter to remove spikes from the samples, but the complimentary filter handles the averaging. I adjust the weight of the accelerometer vector based on how long it is, too. If it's one G it gets filtered in at 1/512 per iteration. If it's longer or shorter than one G, the fraction is even smaller. That means that if it gets bumped, the accelerometer vector doesn't contribute to the orientation estimate for a couple updates, which helps keep the accuracy up. I also start the weighting at 1/64, and switch it to 1/512 after a second or two. That means that on startup (when it's at rest), the accelerometer pulls the IMU into the correct orientation really quickly, but then the gyro takes over after that.
Do you update the motor speeds at 250Hz, or only your angle? I was planning to do motor speed updates and angle sampling at the same rate, and figured any faster than 100 Hz was unnecessary due to mechanical limitations.... but perhaps they should be running out-of-sync. 100 Hz motor refresh but 250 Hz sampling rate.
I update the motors on my quad at 400Hz. On the balancer it was probably only 250. Probably excessive, but being too fast isn't really hurting anything. For a quad, I want the latency low, because small quads can be freakishly agile.
Wow, you guys have been busy while I was gone! Now that Robothon is done I am free to go back to working on my BOE-Balancer.
One big change though, it now has the new Feedback 360s servo on it.
Welcome back! Your bot is looking good, for sure. I had to put mine on hold, despite being very close. The day after I got back from initial testing, my wife and I decided to up and move from Omaha to St. Louis and change jobs. Needless to say, August and September were crazy months, and October will be to.
Hanno is also the guy who came up with 12blocks which about the same thing as blockyprop. This is about where I stopped working with electronics. I went through alot of trying and researching this. I wasnt good at all with spin code more fluent with stamp which isnt suitable for this. Its not an easy project. Itd be nice if someone else could do it with a propeller. You can find some done with an aurdino too. Which is something else parallax is trying to integrate coding for. Itd be nice if the engineers over there made it a personal challenge to get the project done so others could build it. Not only to get this bot balancing but driveable with the joystick gimbles even up an incline. Im gonna try getting back into some electronics again but I wouldnt hold your breath on me and this project.
While I still have 12blocks on an older computer it doesnt look like any of this stuff is even supported anymore. I cant even log into Hannoware forums. Sucks when you buy all this stuff and it just gets abandoned.
A few of us have tried to replicate Hannon's projects, but the parts listed are now longer available. While 12Blocks was great in the day, Parallax's BlockyProp is going to be supported for quite a while. Both are based on MIT Blockly. If you know 12Blocks, BlocklyProp should be quite familiar.
Comments
Thanks. I was thinking really hard about whether or not I should spring for the LSM9DS1... I guess I should have
Watch around the 40 second mark:
That's just integer integration, and stabilizing each of the three axis independently, like having a heading-hold gyro on each axis.
Remember that you're integrating these values, so noise is fine as long as it's relatively low and not biased in a particular direction. Your orientation estimate will look more like a moving average of your numbers. I suspect it'll be fine.
Oh that's a very interesting point I hadn't thought of. The accelerometer is more important to be filtered/averaged (though at only 2% weight, maybe not?) but the gyro is inherently a rolling average filter.... so perhaps running a higher sampling rate (such as the 250Hz you're using) rather 100 Hz + averaging would be better.
The accelerometer is an interesting one - I use a median filter to remove spikes from the samples, but the complimentary filter handles the averaging. I adjust the weight of the accelerometer vector based on how long it is, too. If it's one G it gets filtered in at 1/512 per iteration. If it's longer or shorter than one G, the fraction is even smaller. That means that if it gets bumped, the accelerometer vector doesn't contribute to the orientation estimate for a couple updates, which helps keep the accuracy up. I also start the weighting at 1/64, and switch it to 1/512 after a second or two. That means that on startup (when it's at rest), the accelerometer pulls the IMU into the correct orientation really quickly, but then the gyro takes over after that.
One big change though, it now has the new Feedback 360s servo on it.
http://www.smbaker.com/project-dancebot
https://forums.parallax.com/discussion/115423/hannos-video-and-notes-from-the-upene
Hanno talks about it in the Programming and customizing the multicore propeller book put out by Parallax.
ftp://ftp.propeller-chip.com/PCMProp/Chapter_06/Source/
Hanno is also the guy who came up with 12blocks which about the same thing as blockyprop. This is about where I stopped working with electronics. I went through alot of trying and researching this. I wasnt good at all with spin code more fluent with stamp which isnt suitable for this. Its not an easy project. Itd be nice if someone else could do it with a propeller. You can find some done with an aurdino too. Which is something else parallax is trying to integrate coding for. Itd be nice if the engineers over there made it a personal challenge to get the project done so others could build it. Not only to get this bot balancing but driveable with the joystick gimbles even up an incline. Im gonna try getting back into some electronics again but I wouldnt hold your breath on me and this project.