I suggest that you use a third wheel.
You will not need to write complex coding and save a lot of coding space and parts.
![]()
![]()
I suggest that you use a third wheel.
You will not need to write complex coding and save a lot of coding space and parts.
![]()
![]()
Hi,
I've seen the IR-approach, there's a really cool working system here: www.balbot.com The thing is I'm not sure of the idea since the surface has to be flat - or atleast that's what I think. You can't run up or down a slope for example since the difference between the front and back sensor will be different. The same drawbacks would apply to the ultrasonic transducer approach. Besides, I already got the gyro and accelerometer.... ;-)
I seem to recall someone mentioning the NV article a while back. I may even have seen it and if I have I think they used the same kalman filter code I'm refering to but I may very well be wrong on that point.
I've been working on this on and off for the last 7-8 months, so I'm not gonna give up and put in that third wheel just yet but thanks anyway sayzer ;-)
Thanks guys! Please keep the ideas comming!
/Henrik Olsson.
Hi Henrik,
Don't know if this will help or not, but one of our members, Tom Igoe, has a routine that's supposedly "based" on a kalman filter.
http://www.tigoe.net/pcomp/code/arch...o/000710.shtml
Versions in C and picbasic.
Don't know enough about it to know if it's what you're looking for.
HTH,
DT
Using a inclinometer or clinometer is another option,though it might be expensive.I have used the Accustar(data sheet attached)with a serial connection to a Pic,but not for a balancing act.If you google clinometer you might find something useful.
Thank you for the link, Darrel. I'll read the code and the .pdf Tom says he based it on and see if may work. I'm not sure in what way it resembles the Kalman filter. Since I don't really understand how the Kalman filter works that may or may not make any difference.... ;-)
Arnie, thanks for the sugestion. However, reading the datasheet for the Accustar I came to the conclusion (from the description of how it works and please do correct me if I'm wrong here) that it will suffer from the same problem as the acceleromter. It would work when it's stationary and rotated around its own axis but as soon as it is exposed to a "another" acceleration (except gravity) (robot starts to move) the reading will no longer reflect the true angle of the platform.
The only one I've found that would work is the FAS-G from Microstrain (which contains an acceleromter, gyro and uC) but it's WAY to expensive.
Please keep the suggestions coming. I have some more reading to do.
Thanks!
/Henrik Olsson.
Hi again,
I read Tom's code and the pdf he based it on. Turns out that his code is not based on the Kalman filter but a "simpler" weighted average filter which is actually what I'm using. The pdf shows the code for the Kalman filter but it is again in C which doesn't make it very easy for me.....
What's that saying, it's the last 10% of the project that takes 90% of the time - the devil certanly IS in the details.
/Henrik Olsson.
Hi,
See the PDF file below.
Adjustable weight position, shock resistant.
Swiss Made! (This is a special note for Alain).
PDF doc:
http://leiwww.epfl.ch/publications/g...fer_mic_01.pdf
See the movies:
http://leiwww.epfl.ch/joe/
Best regards,
Luciano
Well,
interesting project, in fact i did that some years ago with stepper motors, hardware talking, you must combine both sensors accelerometer and gyro, aswell as obvious other sensors for not to mess with walls and other more complex obstacles. I applied kalman in C, in those times, I'll try to give myself a time to work in a PICBasic version to share it and adapt it to some new personal proyects I have in mind. Added also a digital compass to test gyro's Z response. Calibration and software compensation is the goal for this. Neural implementation for this, is the way to be taken.
Regards
Rodrigo,
RodSTAR
Hi Rodrigo,
I haven't worked on the robot for several months. I did get it to balance a bit with the two SHARP sensors but the goal is to use the gyro and acceleromter. I beleive the Kalman filter is an esential part of the equation to get that to work correctly. If you ever get to porting any of your Kalman code to PBP I'd very much appreciate if you'd share it.
Thanks!
/Henrik Olsson.
Found this track about Kalman, and it looks quite a Maths challenge!
http://fred.unis.no/Kalman/Master_Thesis_Mathieu.pdf
very well detailed, but still complex.
this looks a bit more accessible: KalmanFilterforDummies
http://bilgin.esme.org/BitsBytes/Kal...6/Default.aspx
Sorry to drag up an old thread, but did anyone ever manage to get a Kalman filter implemented successfully in PBP?
I'm hoping to apply a Kalman filter to accelerometer and gyroscope readings to obtain a tilt measurement and I figured I'd ask if someone has done this in PBP before attempting to port the C code full of floats and matrix multiplication into PBP.
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
Hi,
Not me.... But I'm sure it can be done with PBP, PBPL provides enough bits to get the resolution and but to be able to do it you need to actually understand how it works - which I don't :-(
If you understand the Kalman theory and/or how the C code works I'm sure that we, collectively, can work it out if we take it step by step.
I'd really like to see working Kalman filter in PBP as well.
/Henrik.
Bookmarks