Ausrobotics: Fusion power — combining data from diff sensors
ash
· 2 years ago
Hey Kym :)
I still don't fully understand the math behind them but could a Kalman filter be used in this instance to fuse the data?
As much as I understand they are often used to integrate multiple sensor readings with noise to produce an optimal output. As I said I don't fully understand the math yet but I originally became interested in them when I was looking into how to build a self-balancing robot. They are used to integrate the various gyro and accelerometer readings to produce output to move motors.
Is that what you meant about the formal underpinning?
Here are a couple of good docs on Kalman filters that got me started if you are interested :)
I didn't know they could consolidate several data streams, but I'll give them another look.
(But from Wiki I see there's a relationship to Baysean estimation, so it looks promising :).
From what I understand of other probabilistic schemes, usually quite a bit of real-world considerations are lost on such methods (e.g. assume either sensors are independent, or are dependent), or you need to have detailed info on the sensors involved (e.g. detailed cdf's).
One of the toy problems I was working on involved rangers on a moving toy tank. The way the info needs to be handled when the robot is moving forward is different from the problem of moving backward, or sitting still. I.e. the speed of the motor needs to feed into the technique. Heaven knows what other "independent" data needs to feed in to get good modeling out.
And, finally, I have a small problem with my platform that I've already run into -- only 256 bytes of RAM. :( Makes doing things like sorting (to calculate medians) or moving-point averages a bit tricky. :)
rolandgpainter
· 2 years ago
I think you need a larger processor... 256 bytes of ram is very limiting. Been there.
What are you currently using?
Anonymous
· 2 years ago
The tank runs on an AX-11 controller from Inex (Thailand).
Fairly old discrete technology (spin-olgy would call this "tried and true"), it's based on the MIT "Handyboard" with a couple of extra things glued to it. Processor is an 8-bit 68HC11E1 presently running IC4.
Maybe some problems can be overcome by re-casting some of the s/w in assembler. "Interactive C" makes that fairly painless.
Apart from the small ram size and 8MHz processor, the board has lots of inputs (16 analog, 8 digital), outputs (8 digital outputs with <en>faily high current, 4 DC motors with separate fwd/rec polarity, and 6 servos), and a few specialised things for controlling IR/sonar rangers, magnetic compasses, gyros, etc. It even has a built-in 9600 baud IR link.
It's not a bad platform for messing with, but it may just be a bit underpowered for anything adventurous.</en>
All Comments
Hey Kym :)
I still don't fully understand the math behind them but could a Kalman filter be used in this instance to fuse the data?
As much as I understand they are often used to integrate multiple sensor readings with noise to produce an optimal output. As I said I don't fully understand the math yet but I originally became interested in them when I was looking into how to build a self-balancing robot. They are used to integrate the various gyro and accelerometer readings to produce output to move motors.
Is that what you meant about the formal underpinning?
Here are a couple of good docs on Kalman filters that got me started if you are interested :)
<ul>
<li>http://en.wikipedia.org/wiki/Kalman_filter</li>
<li>(PDF) http://www.cs.unc.edu/~welch/media/pdf/maybeck_...>
</ul>
(But from Wiki I see there's a relationship to Baysean estimation, so it looks promising :).
From what I understand of other probabilistic schemes, usually quite a bit of real-world considerations are lost on such methods (e.g. assume either sensors are independent, or are dependent), or you need to have detailed info on the sensors involved (e.g. detailed cdf's).
One of the toy problems I was working on involved rangers on a moving toy tank. The way the info needs to be handled when the robot is moving forward is different from the problem of moving backward, or sitting still. I.e. the speed of the motor needs to feed into the technique. Heaven knows what other "independent" data needs to feed in to get good modeling out.
And, finally, I have a small problem with my platform that I've already run into -- only 256 bytes of RAM. :( Makes doing things like sorting (to calculate medians) or moving-point averages a bit tricky. :)
I think you need a larger processor... 256 bytes of ram is very limiting. Been there.
What are you currently using?
Fairly old discrete technology (spin-olgy would call this "tried and true"), it's based on the MIT "Handyboard" with a couple of extra things glued to it. Processor is an 8-bit 68HC11E1 presently running IC4.
Maybe some problems can be overcome by re-casting some of the s/w in assembler. "Interactive C" makes that fairly painless.
Apart from the small ram size and 8MHz processor, the board has lots of inputs (16 analog, 8 digital), outputs (8 digital outputs with <en>faily high current, 4 DC motors with separate fwd/rec polarity, and 6 servos), and a few specialised things for controlling IR/sonar rangers, magnetic compasses, gyros, etc. It even has a built-in 9600 baud IR link.
It's not a bad platform for messing with, but it may just be a bit underpowered for anything adventurous.</en>