If you build a moving robot, it can have several inputs that measures position, speed or acceleration. Together they can give an accurate prediction of where the robot is, and where it will be in the near future. The difficult thing is to know what reading is the best. Do I have an accurate position ? Is the speed sensor showing the correct speed. Is my accelerometer accurate ? A Kalman filter handles combining several inputs and keeps track of how much you can trust each sensor. 

Is it better to use a Java Kalman filter library, or should it be implemened as a MRL service ?

I'm not sure about how to think about services or class libraries.

When is it better to use a class library ?

When is better wrapped in a service ?

 

GroG

9 years 2 months ago

Hi Mats,

Great questions - I've played with Kalman filters in OpenCV to do predictive tracking.
Similar to the video below. -

When is it better to use a class library ?

When is better wrapped in a service ?

If it does not have to manage state information nor threads - then its probably better to make it a library.

We went through a similar experience with PID.  Although its a pretty straight forward calculation, there are still quite a few configuration parameters.  So we made it a service.  And then, we came to the agreement that a service for a single PID calculation was over built.  So we came up with PID2.  PID2 is exactly like PID it can do many PID calculations - because it maintains configuration state based on a name.

For example the Tracking service previously required 2 PID services to run, now it only requires 1, and each calculation is computed with a "name"

Here the x axis:

pid.setPID("x", 5.0, 5.0, 0.1);
pid.setControllerDirection("x", PID.DIRECTION_DIRECT);
pid.setMode("x", PID.MODE_AUTOMATIC);
pid.setOutputRange("x", -10, 10); 
pid.setSampleTime("x", 30);
pid.setSetpoint("x", 0.5); // set center

double x = pid.getOutput("x")

and the y axis can have and maintain different configuration

pid.setPID("y", 7.0, 4.0, 0.25);
pid.setControllerDirection("y", PID.DIRECTION_DIRECT);
pid.setMode("y", PID.MODE_AUTOMATIC);
pid.setOutputRange("y", -90, 90);
pid.setSampleTime("y", 30);
pid.setSetpoint("y", 0.5); // set center

double y = pid.getOutput("y")

 

Perhaps Kalman Filter can be implemented in the same way - were there is one service - and it acts more as a configuration service for the benefit of the Kalman consumers

Interestingly enough, we've been looking at some DSP style of libraries.  ( In particular TarsosDSP ) 

Getting good sensor data is important.  There are some re-writes and updates to how MRL handles analog streams of data,  (also known as audio.)

I would like to be able to create something like a MA AR filter,  (Moving Average Auto Regressive) as a general class of filters that we should be able to implement.

Creating more complicated signal flows really requires creating a graph of components that implement certain functions, sumation of signals, multiplcation of signals, (integration? differentiation?)  

This sort of architecture is usually implemented in hardware DSPs, however, I think CPUs are more than fast enough to handle data that is sampled at reasonably rates  ( sub 10kHz ? )  

Currently there is the start of an AudioProcessing pipeline that is modeled similar to how OpenCV does it in MyRobotLab, however,  This only provides a linear sort of approach to processing.  In reality, there is feedback in most useful signal flows.

...  Ok, so, what does all of this mean?  I suppose, I'd like to see if we could extend the concept of a pipeline for audio processing to something that is more "graph" in nature..  One of the key elements fo the building blocks of this Audio Signal Graph , would be a delay element, which could delay the signal before publishing it by N samples.  This "delay" is key for feedback in digitial signal processing...

what do ya think?  Personally,  I love that we're starting to deal with some of these topics here.  My memory of my EE DSP classes in college is getting a little foggy, so some additional help on the details is very welcome!  

The feedback can be done in OpenCV with BlockingQueueGrabber - but it all could be refactored to make feedback easier.  Its true linear pipeline is by far the easiest processing path at the moment.  

How much of a delay?  

@Mats what sensor inputs do you currently have ?  

@Kwatters - I thought it would be fun to do localization with the micro-soft kinect microphone array - but the drives have always been a big pita - curious to see what TarsosDSP has.. played around with the real-time pitch-bending which was fun.

Currently I only have the Rapberry PI camera and a microphone as inputs. And the keyboard. And Internet....

I will build the full InMoov robot, but it takes time to print all the parts. And even more when redesigning things. I have more scrap parts, than parts that I use.... Not that the prints fail, but alsmost every time I print something, I see details that I want to improve. 

My question about Kalman filters is currently just thinking ahead, At some stage, wnen the robot can move around, I guess that the Kinect sensors will be several more inputs. Pressure sensors in the feet and perhaps on other parts of the robot. I think that I also will need to measure the angles in each joint to be able to have a software model of the robot. And at least one gyro, perhaps more. I also assume that measuring the power consumption of each servo could help in avoiding to burn then out, and also as an easy way of measuring how much force they apply. 

cyberhedz

9 years 2 months ago

This is a great idea, considering the human brain relies on multiple inputs for processing as well.  I should be back to testing the ACU design in a few weeks, and can easily expand it to have duplicate or triplicate sensors to account for drift or anomolies. 

 

Mats

9 years 2 months ago

Talking about audio signal processing, mimicing what the human ears and brain is doing is really challenging. As humans we can hear from what direction a sound comes from, if the frequency of the sound is high enough. We also filter away all the internal sound from the body, like the heartbeat and the flow of blood. If you find a very quiet place or sometimes when you are ill, you can hear your own hartbeat, but it's rare.

Good filtering requires "training".  Just as we need "training" to unlearn our natural filters - and listen to our heartbeat.

Just as kwatters mentioned, a feedback loop is usually required - so that the algorithm can "see" the cause and effect of changing different parameters.

Will you be making a Kalman service Mats ?

I will try. It will be a good excercise to learn how to build a MRL service.

I will base it on this open source kalman filter JKalmanand try to wrap it in a service.

Suggestion Box