Hello Propeller Heads, I'm curious as to how many people have tried this Object and had success with it. Also ... what are you using it for and what do you plan to use it for. Currently I'm using it for a balancing robot (reverse pendulum). I’m 99% finished with this bot and will post all it’s fun shortly. Next I'm going to make a 4 prop UAV helicopter. I’m planning on taking a 6DOF circuit and GPS reading to get a much closer positioning. I want to use odometer and the rate of change from the 6DOF fused with a Kalman Filter to get a VERY accurate 3D positioning on our planet. I’ve read and hared of such a thing … just need to program it. After that I plan on making the ultimate JANGA board. It would be a self stabilizing platform that will remove all vibrations and tilt from the surface. That leaves only your skill at the game. This platform could be used for many other purposes but JANGA is something people can grasp. Any way … I was hopping to steal a few good ideas from the crowd to keep me driving forward. ·It’s also good fun to dream and think outside the box. Forum Open:
Glad to see I'm not alone - my whole reason for being so excited about your Kalman Filter is because I want to create a QCopter (4-prop helicopter) - as are a number of others on this forum.
I figured that'll be slightly easier than my unltimate aim of getting a scale Sea King to hover automatically whilst I lower/raise a winch-man (does that make me a bit geeky? LOL)
BTW: Thanks again for the help you've given. I'm so embarrassed about not using floats for my output . I'm getting recognisable angles now - but still having hassles with the yRate IMU output (re-soldered twice now without much luck - it's OK sometimes, but then the readings decay to zero until I press down on one corner!)
I'm currently playing with the 'dt' value in the hope it'll reduce the angle jitter. I was wondering if it's possible to get the object to work this out for itself using the CNT?
Anyways; keep up the excellent work, and I can't wait to see your balance bot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Regarding PID, remember that D (the derivative control action) is predictive in nature, predicting the required control effort (motor response) based on its calculation of the derivative of your error signal. However, the estimation of a derivative in (low end) digital systems is nearly universally recommended against by control engineers due to it's wild fluctuation based on sampled data and noisy sensors. Many digital PID routines leave out the D portion entirely. D action can be implemented if the system uses very clean (low noise) sensors, very high sampling rates, or proper filtering (hardware is best), or a combination of those factors.
While the I (integration) action operates in a lagging fashion, it is stable. But be careful, I believe the existing PID routine does not have an anti-windup protection fo the integral action. (It would not be hard to implement, but it would require a few more parameters passed to the PID method and more system-specific knowledge provided by the user.)
Jason, Thanks for the insight! I'm giving a few different techniques a go-round. I've been successful in balancing P, PI, PID and·PD closed loops … it’s just not as "tight" as I would like. The PID functions I'm using·have some anti-windup built in using high/low integral clamps. Just two more variables passed into the start of the PID loops. It seems to work rather decent in preventing the control output from staying saturated causing the system to act wildly. My burning question about PID loops. I want to use both the current Tilt Angle and tilt rate in degrees/sec to come up with my control output. This will help with people pushing on the bot.·So I did a little reading on other balancing bots and found this little code snip it. Kp * (current_angle - neutral) + Kd * current_rate This is obviously a PD loop and it’s using angle and rate. This is working rather well right now but I fear my derivative portion will cause crazy outburst of movement based on what you just told me. Would you suggest I don't use the derivative part and maybe use something else? Would running two PI loops be logical at all? What I mean is to use one PI loop (leaving out the derivative)·to get a control output based on tilt and sum that with a second PD loop based on tilt rate. I don't want to just use Tilt because it will always be compensating for the real world around it. If I could use the tilt rate to feel wind or people·pushing against ... I could easily and quickly adjust accordingly. Simon, I'm not getting noisy or jittery angles using the exact setup as you ... other than 10MHz Xtal·and mounting of device. I'm using Z, Y axis and X angle rate because I have my circuit mounted perpendicular to the ground. So my Z axis feels 0 g when the bot is standing straight up and Y feels 1 g. As you may have already assumed this removes my ability to have Pitch and Roll because my Y axis is vertical. I get Pitch and Yaw if I wanted it but don't have much need right now. I attached an image that shows my angle (red), rate (green), q_bias (blue)·outputs. My bot has a string attached so it will not fall over very far for my testing. So in that graph I just pushed the bot from one side of the rope to another. As you see my angle isn't noisy and fallows my movements quite well. I'm curious to see a·graph of what you’re getting.· I was using·cnt for my timing before but·I wasn't getting what I had expected. My angle wasn't following the bot fast enough or too fast creating "over steer" in my output. So I tweaked till I got a good working setup. I would love for someone to tell me why. I'm just playing here and I don't have much time to do that. So digging deep into the Propellers timing isn't something I want to do if it’s working. I'm sure you all understand this. It's why we have abstracted every possible computer system from the dawn of time. Those just playing and have wide ideas don’t need to develop their own MOSFET’s to make logic gates just to get started. Any event … I'm VERY happy to see it's working for you Simon. And yes it's geeky to want to save plastic solders from an imaginary battle using a self flying LARGE RC helicopter! [noparse];)[/noparse] But that’s exactly what drives me! So when you get your Sea King flying on it’s own I expect a video or two. I was watching a few videos of your group … very impressive flying. I can only imagine hovering a helicopter upside down!
· Sorry, I should have been more clear.· Derivative action should be avoided when you are calculating it by relatively simple means, e.g. estimating the derivative solely as a difference of two samples divided by time: (measurement1 - measurement2)/dt.·· However, in this particular case your sensor (gyro) input is the derivative (once you've corrected for bias) and is less susceptable to wild fluctations.· You might want to plot it and think about filtering it some, perhaps a short FIR filter.
· The tried and true PID tuning method is the Zeigler-Nichols method.· Google it, but here's the quick and dirty:
1. Turn off D & I portions, leaving only P
2.·Turn Kp down low, and run the system (if possible, not sure about your inverted pendulum).· I think the original derivation of ZN-method has the system run open-loop, but I think there's variations where you can run it closed loop.
3. Slowly bring up Kp, until the system becomes critically stable (system will oscillate but the oscillations will grow slowly or not at all (again, might be difficult for your system, not sure).
4. Note the gain (Kp) of critical stability, and also note the oscillation frequency (F).· You can think of these numbers as the system gain and resonant frequency.
5.· From these two numbers, you can calculate starting points to tune the remaining PID parameters Ki, and Kd.· I forget the equations, but if you google Ziegler-Nichols PID tuning you'll·find it.
I don't think running two loops will yield any benefit over 1 loop combining the·various parameters.· It may even·introduce timing issues -not sure.
Hmm; two Jasons now! Will have to address as JW & JE me thinks!
JW: OK - I'm a geek, LOL! (And I'll be sure to post the video evidence if I get my Sea King )
So you have yAxis pointing down, xAxis left, and zAxis 'forward'?
I'll do a similar set-up this evening and see what my graph shows (BTW: I D/L'd your graphing S/W, used the top button, set it to Com1, but got nothing - what's it expecting as a data-stream?)
Soon as I've got the hang of this IMU I plan to get me some brushless motors and build my QCopter(TM) - tethered, of course LOL!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
First, many thanks for your great work on the Kalman-filter.
You asked for feedback how we are using and adopting your code.
just want to share some ideas on how to implement the hardware.
I designed a small PCB for the MCP3208, that fits on the 'backside'
of the sparkfun IMU. This PCB has it's own pinheader, that fits into
the ProtoBoard.
Just hooked it up and it seems to work, at least i get the same
'strange reading' as 'Simon L' since i'm currently·just dumping the float.point
result as decimal on a serial LCD.
My plans for Kalman are several, initially i will use the IMU for a balancing bot,
I have lots of hardvare from my robotic lawnmover project, the RoboCut. http://www.youtube.com/watch?v=Orz-18MyBPQ
I've been studying Kalman and filter thery for some time, so in the long run i plan to use
KF and EKF in several applikationes to get maximum data out of sensor system...
Jason!
The MathGrap software you are linking to, have you created your IMU·screen-dumps
with this ?· I need som graphic tool to display the tilt-angle, and compare with
values from acc and gyro.
Hello robocut, ·That’s nice work you did. I was thinking of doing something similar but I just haven’t taken the time. I like this approach because it saves me from needing to solder my MCP3208 to the proto board or something else equally painful. ·Yes robotcut I’m using that MathGraph tool I’m linking to. I wrote it in fact but didn’t spend much time on it. So don’t expect too much out of it. I may, here soon, make it a 100 times better but I have other things in front of it. ·I’ve seen your lawnmower before while searching the forums. That’s a neat project and one I would like to take on some time. You already took the hard work out of it so it would be just for fun and knowledge. ·To get the angle and gyro rate from the Kalman filter you can do one of two things. First you can use the FloatString object to convert the floating points to a string with the FloatToString function and print that to your LCD. Or using the FloatMath object to convert the floating points to decimals with the FRound function and print that to your LCD.
simonl, ·Yes that is correct … I have my yAxis pointing down, xAxis left and zAxis forward. I can’t wait to see your QCopter in action.
Now i have had some time for further testing and i works just great. I get the angle as well as rate and bias.
I have 'noise' at about 1/10·of a degree what is your experience. Putting my hand close to the sensor increases the noise
slightly.
The sensor seems quite 'aligned' at 'horisontal' position giving me a zero degrees readout, but at upright position (90 degree)
it looks like i have a small offset error, what is your experience ?
I have to read more about the inversense-sensor, technique and specs to see if offseterrors like this is to·be expected
Again, thank you for the IMU-code, this will open up new opportunities (how do you spell that...) and makes it som much more fun
to continue to work on KALMAN filters! ·
robocut, ·With the way that I have mounted my unit I never see 0 degree. 90 degree is my bot upright and it holds tried and true over the life of my test runs. I have rotated my unit 360 degree and it gave me the full range of output that appeared to hold very true to the unit. Obviously any minor movement of the unit on your board will cause many degrees of offset error. So if you’re turning the proto board and your unit’s weight causes it to shift slightly, that will cause your error. ·I haven’t used any tools to see how accurate the angles are other than a small float level I got from a vendor. It’s close enough for my needs but maybe not yours depending on the application. As I’m sure you know about Kalman filters extended or not, it’s picky about the timing of your state updates. So maybe using a more optimal timing technique will decrease any errors that may come up. This I’m sure could be achieved by re-writing it in assembly and being conscious about your timing. I didn’t need that step yet and may never need it. I’ll do some playing with it tonight at the 0 degree orientation and let you know if I see the same noise in the angle. ·As for the noise increasing when you get closer could be from the pens you have protruding from the unit. Using the driver written by parallax for the MCP3208 is very fast and I’m sure a little static at the input pens could throw a few extra degrees of noise in the system. I’ll also give this a try later. Would you take a few screen shots of your measurements in a graph for us to see? That would help me debug your problems. ·I would love to see an Extended Kalman Filter (EKF) implemented for some need. It sounds like you may have the drive to do it. So if you ever post an EKF please let me know. I’m going to try and make an easy to use framework. It will allow anyone to use this Kalman filter for other applications. Such as the famous water level experiments just without the need to re-write any of the code.
Good Day
Jason ··· Wood
@robocut: I get similar issues with my IMU. I even found I could get significantly high readings (4094!) if my finger got within 1mm of the pins.
@JWood: Excellent! A framework would be of huge help to those like me who don't understand the intricacies of KFs. I'm looking forward to it already (so no pressure then, LOL)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Jason, Simon and all of you kalman/IMU-interested.
I have my IMU mounted on a simple motrized chassie, and just started to experiment
with two-wheel balancing
I use a 24 V system, the IMU is mounted in a stripped version af my robotic-lawnmover controller
bord. this board has a two channel MOS-FET H-bridge motorcontroller. The original BASIC S´tamp has been
replaced with a SPIN-Stamp. The SPIN stamp runs the IMU/kalman code an generates PWM-signals to the H-bridge.
Attached are a few video-clip, sorry for the poor cell-phone quality, but it should give you some ideas of
how the systems behaves.
I can get the system balancing for long times, but it has serious difficulties in handling bigger 'disturbances'.
If the systems starts to move, there is a risk that the the velocity increases until the system 'falls over'
This seems fully logic, since it can speed up in almost 'upright' position, so there is no incitament for the PID-loop to
increase the output...· I know that some of the coolest balancing bot's on the web also has encoders on the wheels, on the other
hand, i have some information about the speed from the PID-output...i also know the acceleration and could predict/calculate current
speed from Newtons laws...
Yes, i have tried to add a small amount of I (in the PID-loop) but this is critical since i get 'wind-up' effects and slow oscillating where the systems
run's forward and back forward back ...
However, i'm satisfied with the results from this first attempt, but any tips from experienced 'balancing-bot' builders are welcome
Hmmmm...the·discussion forum does'nt accept my cellphone .3GP video-files, i'll try to convert them tomorrow
Robocut,
Your experience is exactly what I have seen. What I’ve done is added wheel encoders just like you said to get a much closer torque output at the wheels based on my balance PID loop. Also to overcome the problem of outside disturbances, use the D portion of your PID loops. Pass the rate from the gyro to the D portion and it will respond very quickly to any outside pushing or pulling. This is my PID loop (Kp * (current_angle - neutral) + Kd * current_rate). I got this code from another balancing bot code. As you can see it’s not using the integral portion. It’s also using both Tilt Angle and Tilt Rate to get the best of both worlds. · I would give that a shot. It’s helped my bot handle pushing it. Also, you may want to make your bot more vertical. If you have more weight at the very top point than at your pivot point it’s easier to balance. Take a broom and balance it in your hand with the broom head in the air. Then flip it around and balance it from the broom head. It’s easier to balance with the weight at the top than the bottom. Just a suggestion you could try. · I love what your setup and it looks like you have access to a machine shop. I wish I get my hands on such things. I look forward to your videos. · Jason · Wood ·
<text color changed to black by Moderator>
Post Edited By Moderator (Paul Baker (Parallax)) : 2/5/2008 1:12:02 AM GMT
It generally helps to press the "answer" button
This is at least my way to reconstruct the funny indention of our "beginners in posting".
It is not a good idea when some has processed his code by Phil's pretty-printer
Maybe a spell checker and ability to copy from a word editor would make this easier. My apologies for my "beginners in posting" ... it seems easier not to. Where is my default color section after I paste my text? Either I select a color that will contrast with every other post or simply paste what I have from word and deal with it.
Thank you Paul .. I do appreciate your help ... but now I can not read it because I don't use your "out of the box colors". If that's·easier for every one ... I'll always make it black and select the text my self.
I'm currently·using Mr Andy Lindsay's PID object, but i'll try Jasons approach later.
JWood, what are you doing with the data from your encoders ?
Yes. i understand the 'broom-stick' analogy, but i just tock some junk from our robot-lawnmover
bin to get a quick start, and, i guess, if i can get this chassie behave nicely i have a good general
purpose algorithm...
I'll let you know when i make any progress.
Any other IMU users/balancing-bot-builders out there
By the way, on my youtube site you can also see me doing a few things for Swedish television.
My role is a sort of 'science-guy' showing scientific tricks. Yes, i understand that this has little to do
with propeller, parallax and computing, but there seems to be a correlation between tech-nerds like me
and getting amused by Cola & mentos fireworks, or pitching your voice down with SF6...as a coffebreak
So, please·DONT click on theese links AND complain over unrelevant postings on this forum... http://www.youtube.com/watch?v=-6eCHYumY1I··http://www.youtube.com/watch?v=gV1zXkMFYHc
robocut,
I'm getting RPM out of the encoder. This tells me if I'm turning the wheels as much as my balance PID thinks it should be. This gives a slightly quicker responce time to my balance PID loop.
An interesting experiment to do with my chassie is to 'hold the wheels' tight to the ground. This causes
the system to oscillates at high amplitude. i guess my system is to light and low (broomstick analogy). Some sort of encoding could help to determine what the motor output is actually creating, 'turning/rotating' the chassie or accelerating the whole system speed...
Would be interesting to take a look at your bot !
Graham!
Yes, there is some significant backlash· on the motors. To gettotally rid of backlash i wold neeed expensive motors or maybe an beltdrive arrangement. I find it interesting to get an acceptable result with fairly simple motors, balancing at one point is not the main target for my bot, more to move around.
Now i'm looking for a set of 'wheelchair' motors, let's se if i can find anything reasonable in sweden.
I understand that this question not should be in this thread, but it since we are using some floatMath...
Until now i have just stacked object, one after another, now it seems like my code is "running out of cogs"
So many of my objects 'starts' their own cog, and many of them also starts their own instanceof the·float32-object.
Is there any way to 'share' resources like the Float32
I understand that this is a newbie-propeller question, i have learned propeller the pragmatic way, but i can't find the solution in the manual, or more exactly, i don't know the 'search-word'
I've never used it, so if you get it working, I'd love to see some code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
I'm working on with my balancing bot, but there is a 'effect' i have noticed, and i want to check with you to see if that's normal, or if i have to look over my Kalman-loop.
I get a significant 'acceleration' effect added to the output angle_value.
If i mount my 5DOF sensor board on a small 'meccano-wagon' in horizontal position.
When i then push this small wagon forth anf back at rather low speed, at least lower than the speeds used by my balancing robot...the kalman output angle increases and decreases around 'zero' at + 3 and - 3 degrees... This must be enough to fully confuse the control algorithm of the balancing robot, with, let's say a 'P' faktor at 4 in a PD-loop...
Do you have similar measurements from your sensors/kalman software?·· Also, i get about 100 deg in a 90 degrees position and i cant get reliable values arounf the full 360 deg rotation...
Any tips
greetings from a sunny Gothenburg, we now, mid february, have a wonderful 'spring-day' !!??
Robocut; I found (without any real understanding of KF) that if you introduce a suitable amount of q_bias to your servo command (e.g. servo := 10*angle + 20*q_bias + 1500) you can reduce the effect of the dynamic acceleration to tolerable levels. I haven´t run any proper tests so this idea maybe falls flat in some other aspects; for instance I noticed that shaking the IMU along the z-axis threw the angle estimation way off. But it can work in 1-dimensional applications.Just my 5 öre.
Thanks for the tip. This is in the same lin as my own thoughts of putting more focus on the gyro-data which in my plots seems very reliable...
combined with rate_bias...still, after the more or less 'mythic description' of the Kalman filter, it's hard to belive one could improve the
'optimum filter' .
Well, i'll give it a try and let you know any progress...
Jaakko, ··· Your welcome and thanks! · robocut, ··· I believe this effect your speaking of is misalignment of the device. Only a few percent of a degree will cause output in the wrong direction. Now it's almost impractical for you to mount the device perfect. What I need to do is remove the other two vectors from my readings while I pass them into the KF. I've seen this done many times and wasn't sure if I really needed to do it but I see now I must. I'm experiencing a similar effect. It's keeping me from being able to maintain a perfect balance in·the same spot. ··· I have a demo application that I wrote to help explain this KF and how to use. So I'll add in a little better math to get the true pitch vector to the KF and post it with my demo. I'll try and get this done by the weekend but it's a busy week. ··· As for your readings not being reliable after a full 360 rotation ... I'm not sure. It's not entirety designed for a full 360 degree rotation and I haven't done many tests with that. What I need to do is increase my 2 state KF to a 3 state KF to incorporate roll. That would also eliminate the cross readings from misalignment. · I'm very excited this little bit of code has taken off so well. It looks like I really need to spend a little more time with this filter to make it more "production ready". I'll keep you all updated on my progress with this KF and the more to come. · in the mean time ... check out this wicked technology. http://youtube.com/watch?v=KhX_rLqhiaU· This is my next plan of projects.
Your piece of code is also valuable for us 'pragmatic guys' who like to learn even advanced theories in combination with real experimenting...
Another point of view i would like to share is this: Many years ago when i·studied static and dynamic physics, Newtons law's was more
or less boring stuff, just necessary to get the exams...but now, with all the parameters available from a tiny PCB with a few sensors
it's completely differnt. The beautiful simplicity of a few Newtonian equations·tells us that we know·almost 'everything', cool!
So you are fascinated of SLAM as well!, As you might know, i have designed a robotic lawnmover, and also managed to sell the platform
to a company. In this process we had meetings with several companies. Wherever we came, the first question was: Are you using a 'perimeter cable' to define the working area...'SLAM like' techniques has been a teorethical candidate for navigation a rover in a area as long as there has been robots...but now things are happening!
_______________________________________________________________________________________
robotcut,
using the 5DOF from sparkfun incorporates a very nice 3 axis accelerometer that's fast and accurate. It could easily be used for many things such as a Wii remote type system. It just wouldn't work by it's self for a balancing application or UAV applications.
I have looked at viewport but didn't like what I saw so I wrote my own graphing tool. It is as well unstable but I like the ability to have many graphs in the same window hooked to many different com ports in the same app.
I completely agree with you about Newtons law's! I found most advanced math to be a chore but now that I'm understanding it more and more .. it's the greatest thing I've come accrost. I'm looking for problems above my head just to gain the knowledge. That is why I'm looking at SLAM for my next project. It's a good deal above my current knowledge of matrix transformations and visual interpretations. I'm looking forward to the many painful nights beating my head against my keyboard.
I'm quite aware of your robotic lawnmower but I didn't know you sold it. That is great! I would love to get into this professionally and sell a great idea or working platform. So ... how do you control the mowing area of your robot?
Comments
I'm curious as to how many people have tried this Object and had success with it.
Also ... what are you using it for and what do you plan to use it for.
Currently I'm using it for a balancing robot (reverse pendulum). I’m 99% finished with this bot and will post all it’s fun shortly.
Next I'm going to make a 4 prop UAV helicopter. I’m planning on taking a 6DOF circuit and GPS reading to get a much closer positioning. I want to use odometer and the rate of change from the 6DOF fused with a Kalman Filter to get a VERY accurate 3D positioning on our planet. I’ve read and hared of such a thing … just need to program it.
After that I plan on making the ultimate JANGA board. It would be a self stabilizing platform that will remove all vibrations and tilt from the surface. That leaves only your skill at the game. This platform could be used for many other purposes but JANGA is something people can grasp.
Any way … I was hopping to steal a few good ideas from the crowd to keep me driving forward. ·It’s also good fun to dream and think outside the box.
Forum Open:
Glad to see I'm not alone - my whole reason for being so excited about your Kalman Filter is because I want to create a QCopter (4-prop helicopter) - as are a number of others on this forum.
I figured that'll be slightly easier than my unltimate aim of getting a scale Sea King to hover automatically whilst I lower/raise a winch-man (does that make me a bit geeky? LOL)
BTW: Thanks again for the help you've given. I'm so embarrassed about not using floats for my output
I'm currently playing with the 'dt' value in the hope it'll reduce the angle jitter. I was wondering if it's possible to get the object to work this out for itself using the CNT?
Anyways; keep up the excellent work, and I can't wait to see your balance bot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Regarding PID, remember that D (the derivative control action) is predictive in nature, predicting the required control effort (motor response) based on its calculation of the derivative of your error signal. However, the estimation of a derivative in (low end) digital systems is nearly universally recommended against by control engineers due to it's wild fluctuation based on sampled data and noisy sensors. Many digital PID routines leave out the D portion entirely. D action can be implemented if the system uses very clean (low noise) sensors, very high sampling rates, or proper filtering (hardware is best), or a combination of those factors.
While the I (integration) action operates in a lagging fashion, it is stable. But be careful, I believe the existing PID routine does not have an anti-windup protection fo the integral action. (It would not be hard to implement, but it would require a few more parameters passed to the PID method and more system-specific knowledge provided by the user.)
-JasonE
Thanks for the insight! I'm giving a few different techniques a go-round. I've been successful in balancing P, PI, PID and·PD closed loops … it’s just not as "tight" as I would like.
The PID functions I'm using·have some anti-windup built in using high/low integral clamps. Just two more variables passed into the start of the PID loops. It seems to work rather decent in preventing the control output from staying saturated causing the system to act wildly.
My burning question about PID loops. I want to use both the current Tilt Angle and tilt rate in degrees/sec to come up with my control output. This will help with people pushing on the bot.·So I did a little reading on other balancing bots and found this little code snip it.
Kp * (current_angle - neutral) + Kd * current_rate
This is obviously a PD loop and it’s using angle and rate. This is working rather well right now but I fear my derivative portion will cause crazy outburst of movement based on what you just told me. Would you suggest I don't use the derivative part and maybe use something else?
Would running two PI loops be logical at all? What I mean is to use one PI loop (leaving out the derivative)·to get a control output based on tilt and sum that with a second PD loop based on tilt rate. I don't want to just use Tilt because it will always be compensating for the real world around it. If I could use the tilt rate to feel wind or people·pushing against ... I could easily and quickly adjust accordingly.
Simon,
I'm not getting noisy or jittery angles using the exact setup as you ... other than 10MHz Xtal·and mounting of device. I'm using Z, Y axis and X angle rate because I have my circuit mounted perpendicular to the ground. So my Z axis feels 0 g when the bot is standing straight up and Y feels 1 g. As you may have already assumed this removes my ability to have Pitch and Roll because my Y axis is vertical. I get Pitch and Yaw if I wanted it but don't have much need right now.
I attached an image that shows my angle (red), rate (green), q_bias (blue)·outputs. My bot has a string attached so it will not fall over very far for my testing. So in that graph I just pushed the bot from one side of the rope to another. As you see my angle isn't noisy and fallows my movements quite well. I'm curious to see a·graph of what you’re getting.·
I was using·cnt for my timing before but·I wasn't getting what I had expected. My angle wasn't following the bot fast enough or too fast creating "over steer" in my output. So I tweaked till I got a good working setup. I would love for someone to tell me why. I'm just playing here and I don't have much time to do that. So digging deep into the Propellers timing isn't something I want to do if it’s working. I'm sure you all understand this. It's why we have abstracted every possible computer system from the dawn of time. Those just playing and have wide ideas don’t need to develop their own MOSFET’s to make logic gates just to get started.
Any event … I'm VERY happy to see it's working for you Simon. And yes it's geeky to want to save plastic solders from an imaginary battle using a self flying LARGE RC helicopter! [noparse];)[/noparse] But that’s exactly what drives me! So when you get your Sea King flying on it’s own I expect a video or two. I was watching a few videos of your group … very impressive flying. I can only imagine hovering a helicopter upside down!
Good Day!
Jason Wood
· Sorry, I should have been more clear.· Derivative action should be avoided when you are calculating it by relatively simple means, e.g. estimating the derivative solely as a difference of two samples divided by time: (measurement1 - measurement2)/dt.·· However, in this particular case your sensor (gyro) input is the derivative (once you've corrected for bias) and is less susceptable to wild fluctations.· You might want to plot it and think about filtering it some, perhaps a short FIR filter.
· The tried and true PID tuning method is the Zeigler-Nichols method.· Google it, but here's the quick and dirty:
1. Turn off D & I portions, leaving only P
2.·Turn Kp down low, and run the system (if possible, not sure about your inverted pendulum).· I think the original derivation of ZN-method has the system run open-loop, but I think there's variations where you can run it closed loop.
3. Slowly bring up Kp, until the system becomes critically stable (system will oscillate but the oscillations will grow slowly or not at all (again, might be difficult for your system, not sure).
4. Note the gain (Kp) of critical stability, and also note the oscillation frequency (F).· You can think of these numbers as the system gain and resonant frequency.
5.· From these two numbers, you can calculate starting points to tune the remaining PID parameters Ki, and Kd.· I forget the equations, but if you google Ziegler-Nichols PID tuning you'll·find it.
I don't think running two loops will yield any benefit over 1 loop combining the·various parameters.· It may even·introduce timing issues -not sure.
-JasonE
JW: OK - I'm a geek, LOL! (And I'll be sure to post the video evidence if I get my Sea King
So you have yAxis pointing down, xAxis left, and zAxis 'forward'?
I'll do a similar set-up this evening and see what my graph shows (BTW: I D/L'd your graphing S/W, used the top button, set it to Com1, but got nothing - what's it expecting as a data-stream?)
Soon as I've got the hang of this IMU I plan to get me some brushless motors and build my QCopter(TM) - tethered, of course LOL!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
First, many thanks for your great work on the Kalman-filter.
You asked for feedback how we are using and adopting your code.
just want to share some ideas on how to implement the hardware.
I designed a small PCB for the MCP3208, that fits on the 'backside'
of the sparkfun IMU. This PCB has it's own pinheader, that fits into
the ProtoBoard.
Just hooked it up and it seems to work, at least i get the same
'strange reading' as 'Simon L' since i'm currently·just dumping the float.point
result as decimal on a serial LCD.
My plans for Kalman are several, initially i will use the IMU for a balancing bot,
I have lots of hardvare from my robotic lawnmover project, the RoboCut.
http://www.youtube.com/watch?v=Orz-18MyBPQ
I've been studying Kalman and filter thery for some time, so in the long run i plan to use
KF and EKF in several applikationes to get maximum data out of sensor system...
Jason!
The MathGrap software you are linking to, have you created your IMU·screen-dumps
with this ?· I need som graphic tool to display the tilt-angle, and compare with
values from acc and gyro.
Once again, thanks for your great work.
·That’s nice work you did. I was thinking of doing something similar but I just haven’t taken the time. I like this approach because it saves me from needing to solder my MCP3208 to the proto board or something else equally painful.
·Yes robotcut I’m using that MathGraph tool I’m linking to. I wrote it in fact but didn’t spend much time on it. So don’t expect too much out of it. I may, here soon, make it a 100 times better but I have other things in front of it.
·I’ve seen your lawnmower before while searching the forums. That’s a neat project and one I would like to take on some time. You already took the hard work out of it so it would be just for fun and knowledge.
·To get the angle and gyro rate from the Kalman filter you can do one of two things. First you can use the FloatString object to convert the floating points to a string with the FloatToString function and print that to your LCD. Or using the FloatMath object to convert the floating points to decimals with the FRound function and print that to your LCD.
simonl,
·Yes that is correct … I have my yAxis pointing down, xAxis left and zAxis forward. I can’t wait to see your QCopter in action.
Now i have had some time for further testing and i works just great. I get the angle as well as rate and bias.
I have 'noise' at about 1/10·of a degree what is your experience. Putting my hand close to the sensor increases the noise
slightly.
The sensor seems quite 'aligned' at 'horisontal' position giving me a zero degrees readout, but at upright position (90 degree)
it looks like i have a small offset error, what is your experience ?
I have to read more about the inversense-sensor, technique and specs to see if offseterrors like this is to·be expected
Again, thank you for the IMU-code, this will open up new opportunities (how do you spell that...) and makes it som much more fun
to continue to work on KALMAN filters!
·
·With the way that I have mounted my unit I never see 0 degree. 90 degree is my bot upright and it holds tried and true over the life of my test runs. I have rotated my unit 360 degree and it gave me the full range of output that appeared to hold very true to the unit. Obviously any minor movement of the unit on your board will cause many degrees of offset error. So if you’re turning the proto board and your unit’s weight causes it to shift slightly, that will cause your error.
·I haven’t used any tools to see how accurate the angles are other than a small float level I got from a vendor. It’s close enough for my needs but maybe not yours depending on the application. As I’m sure you know about Kalman filters extended or not, it’s picky about the timing of your state updates. So maybe using a more optimal timing technique will decrease any errors that may come up. This I’m sure could be achieved by re-writing it in assembly and being conscious about your timing. I didn’t need that step yet and may never need it. I’ll do some playing with it tonight at the 0 degree orientation and let you know if I see the same noise in the angle.
·As for the noise increasing when you get closer could be from the pens you have protruding from the unit. Using the driver written by parallax for the MCP3208 is very fast and I’m sure a little static at the input pens could throw a few extra degrees of noise in the system. I’ll also give this a try later. Would you take a few screen shots of your measurements in a graph for us to see? That would help me debug your problems.
·I would love to see an Extended Kalman Filter (EKF) implemented for some need. It sounds like you may have the drive to do it. So if you ever post an EKF please let me know. I’m going to try and make an easy to use framework. It will allow anyone to use this Kalman filter for other applications. Such as the famous water level experiments just without the need to re-write any of the code.
Good Day
Jason
··· Wood
@JWood: Excellent! A framework would be of huge help to those like me who don't understand the intricacies of KFs. I'm looking forward to it already (so no pressure then, LOL)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Post Edited (simonl) : 2/1/2008 10:15:13 AM GMT
I have my IMU mounted on a simple motrized chassie, and just started to experiment
with two-wheel balancing
I use a 24 V system, the IMU is mounted in a stripped version af my robotic-lawnmover controller
bord. this board has a two channel MOS-FET H-bridge motorcontroller. The original BASIC S´tamp has been
replaced with a SPIN-Stamp. The SPIN stamp runs the IMU/kalman code an generates PWM-signals to the H-bridge.
Attached are a few video-clip, sorry for the poor cell-phone quality, but it should give you some ideas of
how the systems behaves.
I can get the system balancing for long times, but it has serious difficulties in handling bigger 'disturbances'.
If the systems starts to move, there is a risk that the the velocity increases until the system 'falls over'
This seems fully logic, since it can speed up in almost 'upright' position, so there is no incitament for the PID-loop to
increase the output...· I know that some of the coolest balancing bot's on the web also has encoders on the wheels, on the other
hand, i have some information about the speed from the PID-output...i also know the acceleration and could predict/calculate current
speed from Newtons laws...
Yes, i have tried to add a small amount of I (in the PID-loop) but this is critical since i get 'wind-up' effects and slow oscillating where the systems
run's forward and back forward back ...
However, i'm satisfied with the results from this first attempt, but any tips from experienced 'balancing-bot' builders are welcome
Hmmmm...the·discussion forum does'nt accept my cellphone .3GP video-files, i'll try to convert them tomorrow
Your experience is exactly what I have seen. What I’ve done is added wheel encoders just like you said to get a much closer torque output at the wheels based on my balance PID loop. Also to overcome the problem of outside disturbances, use the D portion of your PID loops. Pass the rate from the gyro to the D portion and it will respond very quickly to any outside pushing or pulling.
This is my PID loop (Kp * (current_angle - neutral) + Kd * current_rate). I got this code from another balancing bot code. As you can see it’s not using the integral portion. It’s also using both Tilt Angle and Tilt Rate to get the best of both worlds.
·
I would give that a shot. It’s helped my bot handle pushing it. Also, you may want to make your bot more vertical. If you have more weight at the very top point than at your pivot point it’s easier to balance. Take a broom and balance it in your hand with the broom head in the air. Then flip it around and balance it from the broom head. It’s easier to balance with the weight at the top than the bottom. Just a suggestion you could try.
·
I love what your setup and it looks like you have access to a machine shop. I wish I get my hands on such things. I look forward to your videos.
·
Jason
· Wood
·
<text color changed to black by Moderator>
Post Edited By Moderator (Paul Baker (Parallax)) : 2/5/2008 1:12:02 AM GMT
Any chance of removing the weird formatting, it makes it a devil to read and I have good eyes, not every forum member does.
Graham
This is at least my way to reconstruct the funny indention of our "beginners in posting".
It is not a good idea when some has processed his code by Phil's pretty-printer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Thank you Paul .. I do appreciate your help ... but now I can not read it because I don't use your "out of the box colors". If that's·easier for every one ... I'll always make it black and select the text my self.
Jason
http://www.youtube.com/watch?v=6filE6PimKo
http://www.youtube.com/watch?v=QVWJ-ZtZQTY
I'm currently·using Mr Andy Lindsay's PID object, but i'll try Jasons approach later.
JWood, what are you doing with the data from your encoders ?
Yes. i understand the 'broom-stick' analogy, but i just tock some junk from our robot-lawnmover
bin to get a quick start, and, i guess, if i can get this chassie behave nicely i have a good general
purpose algorithm...
I'll let you know when i make any progress.
Any other IMU users/balancing-bot-builders out there
By the way, on my youtube site you can also see me doing a few things for Swedish television.
My role is a sort of 'science-guy' showing scientific tricks. Yes, i understand that this has little to do
with propeller, parallax and computing, but there seems to be a correlation between tech-nerds like me
and getting amused by Cola & mentos fireworks, or pitching your voice down with SF6...as a coffebreak
So, please·DONT click on theese links AND complain over unrelevant postings on this forum...
http://www.youtube.com/watch?v=-6eCHYumY1I·· http://www.youtube.com/watch?v=gV1zXkMFYHc
I'm getting RPM out of the encoder. This tells me if I'm turning the wheels as much as my balance PID thinks it should be. This gives a slightly quicker responce time to my balance PID loop.
I have some motors/gearboxes like that and it sounds like the motor is oscillating due to backlash.
Graham
the system to oscillates at high amplitude. i guess my system is to light and low (broomstick analogy). Some sort of encoding could help to determine what the motor output is actually creating, 'turning/rotating' the chassie or accelerating the whole system speed...
Would be interesting to take a look at your bot !
Graham!
Yes, there is some significant backlash· on the motors. To gettotally rid of backlash i wold neeed expensive motors or maybe an beltdrive arrangement. I find it interesting to get an acceptable result with fairly simple motors, balancing at one point is not the main target for my bot, more to move around.
Now i'm looking for a set of 'wheelchair' motors, let's se if i can find anything reasonable in sweden.
Hans
Friction drive onto those big ole wheels would also be a cheap option.
Graham
I understand that this question not should be in this thread, but it since we are using some floatMath...
Until now i have just stacked object, one after another, now it seems like my code is "running out of cogs"
So many of my objects 'starts' their own cog, and many of them also starts their own instanceof the·float32-object.
Is there any way to 'share' resources like the Float32
I understand that this is a newbie-propeller question, i have learned propeller the pragmatic way, but i can't find the solution in the manual, or more exactly, i don't know the 'search-word'
Thanks!
Hans
I've never used it, so if you get it working, I'd love to see some code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
@SimonL
I'm working on with my balancing bot, but there is a 'effect' i have noticed, and i want to check with you to see if that's normal, or if i have to look over my Kalman-loop.
I get a significant 'acceleration' effect added to the output angle_value.
If i mount my 5DOF sensor board on a small 'meccano-wagon' in horizontal position.
When i then push this small wagon forth anf back at rather low speed, at least lower than the speeds used by my balancing robot...the kalman output angle increases and decreases around 'zero' at + 3 and - 3 degrees... This must be enough to fully confuse the control algorithm of the balancing robot, with, let's say a 'P' faktor at 4 in a PD-loop...
Do you have similar measurements from your sensors/kalman software?·· Also, i get about 100 deg in a 90 degrees position and i cant get reliable values arounf the full 360 deg rotation...
Any tips
greetings from a sunny Gothenburg, we now, mid february, have a wonderful 'spring-day' !!??
THANK YOU JWood for the filter!
Robocut; I found (without any real understanding of KF) that if you introduce a suitable amount of q_bias to your servo command (e.g. servo := 10*angle + 20*q_bias + 1500) you can reduce the effect of the dynamic acceleration to tolerable levels. I haven´t run any proper tests so this idea maybe falls flat in some other aspects; for instance I noticed that shaking the IMU along the z-axis threw the angle estimation way off. But it can work in 1-dimensional applications.Just my 5 öre.
Thank you chaps
Jaakko
Thanks for the tip. This is in the same lin as my own thoughts of putting more focus on the gyro-data which in my plots seems very reliable...
combined with rate_bias...still, after the more or less 'mythic description' of the Kalman filter, it's hard to belive one could improve the
'optimum filter' .
Well, i'll give it a try and let you know any progress...
Greetings
Hans
··· Your welcome and thanks!
·
robocut,
··· I believe this effect your speaking of is misalignment of the device. Only a few percent of a degree will cause output in the wrong direction. Now it's almost impractical for you to mount the device perfect. What I need to do is remove the other two vectors from my readings while I pass them into the KF. I've seen this done many times and wasn't sure if I really needed to do it but I see now I must. I'm experiencing a similar effect. It's keeping me from being able to maintain a perfect balance in·the same spot.
··· I have a demo application that I wrote to help explain this KF and how to use. So I'll add in a little better math to get the true pitch vector to the KF and post it with my demo. I'll try and get this done by the weekend but it's a busy week.
··· As for your readings not being reliable after a full 360 rotation ... I'm not sure. It's not entirety designed for a full 360 degree rotation and I haven't done many tests with that. What I need to do is increase my 2 state KF to a 3 state KF to incorporate roll. That would also eliminate the cross readings from misalignment.
·
I'm very excited this little bit of code has taken off so well. It looks like I really need to spend a little more time with this filter to make it more "production ready". I'll keep you all updated on my progress with this KF and the more to come.
·
in the mean time ... check out this wicked technology. http://youtube.com/watch?v=KhX_rLqhiaU· This is my next plan of projects.
I'm also doing some experiments with the three acc-axis. and i·let you know if im getting something useful out of it.
I'm using the 'viewport' software to plot data and parameters, i found it useful, but a little unstable.
Greetings
Hans
________________________________________________________________________________
Yes, its a interesting piece of code you came up with, also, it seems like gyro/acc systems are popping up in many applications right now, so it's kind of hot tech! (e.g. the motus game controller http://www.engadget.com/2008/02/04/motus-darwin-controller-to-being-that-wii-feeling-to-the-pc/·)
Your piece of code is also valuable for us 'pragmatic guys' who like to learn even advanced theories in combination with real experimenting...
Another point of view i would like to share is this: Many years ago when i·studied static and dynamic physics, Newtons law's was more
or less boring stuff, just necessary to get the exams...but now, with all the parameters available from a tiny PCB with a few sensors
it's completely differnt. The beautiful simplicity of a few Newtonian equations·tells us that we know·almost 'everything', cool!
So you are fascinated of SLAM as well!, As you might know, i have designed a robotic lawnmover, and also managed to sell the platform
to a company. In this process we had meetings with several companies. Wherever we came, the first question was: Are you using a 'perimeter cable' to define the working area...'SLAM like' techniques has been a teorethical candidate for navigation a rover in a area as long as there has been robots...but now things are happening!
_______________________________________________________________________________________
using the 5DOF from sparkfun incorporates a very nice 3 axis accelerometer that's fast and accurate. It could easily be used for many things such as a Wii remote type system. It just wouldn't work by it's self for a balancing application or UAV applications.
I have looked at viewport but didn't like what I saw so I wrote my own graphing tool. It is as well unstable but I like the ability to have many graphs in the same window hooked to many different com ports in the same app.
I completely agree with you about Newtons law's! I found most advanced math to be a chore but now that I'm understanding it more and more .. it's the greatest thing I've come accrost. I'm looking for problems above my head just to gain the knowledge. That is why I'm looking at SLAM for my next project. It's a good deal above my current knowledge of matrix transformations and visual interpretations. I'm looking forward to the many painful nights beating my head against my keyboard.
I'm quite aware of your robotic lawnmower but I didn't know you sold it. That is great! I would love to get into this professionally and sell a great idea or working platform. So ... how do you control the mowing area of your robot?