Not that I'm aware of. You just need to increase the stack you assign at cog startup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
When you hit F8 from your top object, how much free space is shown?
Also, it may be a coincidence, but I note that your debug output has 1 2 3 4 5 6 etc vertically - are the numbers as you expect ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
After you said it might be memory and I didn't know how to add any more to the top object's run space I tried starting my method up in·a new cog and assigned 100 longs to it before I saw your tricky F8 (didn't know about that). Anyways, I've attached what it gave me, but don't really know what it means, is 4,000 longs enough space? I dunno?
Yeah the 123456 was in the correct order initially, but when things started getting mixed up they kind of got garbled up in the debug screen, there was usually something like 1= 27 37 47 5g 6a or something like that. Occasionally it's skip a few and one of the outputs would sneak in.
I figured out why my output wasn't changing, I was trying to do float math operations with non-float numbers, so I made sure they were floats and I started getting outputs that made sense.
The debug terminal was still a little funky though. I added a waitcnt for 1/2s and it came out clean, does that sound like a memory issue? or maybe just a speed issue? like, maybe the Prop is running faster than the COM port can actually take the data or something?
Does anybody know how many cogs Servo32v3 takes up? I believe I have 3 open cogs so I didn't think this would be an issue, but when I try to run Servo32v3.Set nothing happens.
Servo32 only takes one cog (plus the main cog for initializing and calling). If nothing happens, there must be something wrong with the way you're calling it. Please post your code or at least the code that has to do with Servo32.
Aha! I still keep missing those float gotcha's! Glad to see you got'em
Servo32 needs to be initialised before you start it:
PUB Servo32_DEMO | temp
repeat temp from 0 to 31 'Preset ALL servo's to center position
SERVO.Set(temp,1500)
'Note: Servo pins that will be used must be preset before running "SERVO.Start".
' This is because the I/O direction is set here and is only executed
' at the beginning of "SERVO.Start". Servo pins that aren't used will remain
' in their original direction state.
SERVO.Start 'Start Servo handler
I got that from within Servo32_demo.spin - hope it helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 did this by looking inside each object to see a) if it had subordinate objects; and b) if it, or a subordinate, had a 'cognew' command.
Unless I'm mistaken; even if a parent object has already loaded (say) FullDuplexSerial, if it has a cognew in any called routine (e.g. start) then it gets loaded into a new cog.
So; Hover2.spin is loading IMU, which in-turn is loading Float32Full, which in-turn is loading Float32A - so that's 4 cogs.
I guess you're right on the cog limit!
If you're needing any extra cogs, one option is to investigate Matteo Borri's dynamic math lib in obex - it dynamically starts/stops float-math cogs when required (but I've not used it myself yet).
As for the 1/2s delay fixing your debug - you're only running at 57600, so I'd expect any modern PC to be able to handle that, but the delay does seem to suggest otherwise! On the other hand, I wonder if the problem's down to overflow on the FullDuplexSerial buffer? What buffer size are you using?
4_000 longs would appear to be plenty, but I don't know what your whole code is doing - so I could be wrong!
HTH.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 think I'll try taking the debug stuff out of my code and using LEDs to see "where" it's at, that way I can free up one last cog to run the servos, that should do it, hopefully. I'll also check out that dynamic float thingy, sounds interesting.
Beau also told me about presetting the servos - didn't know that, I never read that part in the demo, usually I just read comments in the main code, oh well. What's weird is if you write a super simply code to just turn the servo back and forth back and forth you don't need to do the preset before servo.start, curious.
As for the garbly debugging - I was thinking maybe it wasn't the PC itself but the PropStick or something? I dunno. I'm not too worried about it though, as long as my outputs from PID are making sense and I can get one more cog to run servos I should be good to go, we'll see, I should know by Thursday whether or not I'm graduating anyways...
Hey everybody, I was just thinking this morning, and JWood this is mostly for you, would it be possible to use the KF simply using the 0-4096 coming from the ADC instead of converting it into float degress? If you got rid of all the floating math it'd clear up two or three more cogs overall I think. Plus, by the time you are sending PWM to the servos you've converted back to a dec anyways. Just a thought.
Re: your note about getting rid of the float stuff, I believe your thinking's good - we only need to convert to degrees if us monkeys need to read it; which of course we do when we're debugging :-(
That said; I see no reason why - with careful programming - we couldn't get it working (and sorta readable) using integer math, but that's beyond me at the moment...
Any chance you'll be posting all your code for other heli' propers?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 guess if altitude isn't really an issue you could skip using the back two servos when adjusting pitch, it would just also affect altitude. Then for roll you'd obviously just adjust the back two in opposite directions.
As for getting rid of all the float stuff, they only reason would be to free up cogs to be able to read in from the RX so that you could switch between stabilized and normal r/c flight. Although...that gives me an idea, I bet I could have it check the RX pins each go round of the PID loop...although that might be way way too slow, since you'd have to wait for an entire pulse before doing anything else. Hmmm...well, I'm not quite there yet, I need to just make it hover first, doing the rest will come later.
But...Jason, if you're reading this, please, please, us Heli guys (or at least me) would LOVE to see a version of the KF that doesn't use any float! By the way I was PMing with Brad (can't rember his user name) and he was saying your latest KF favors the accelerometers too much or something? I dunno, but I told him to post what he thought the problem was.
Now, keep in mind, this is a preliminary final code (if that makes sense), if you know what I mean.
Hopefully this will work to make the heli hover. I've had good luck with the servos by themselves so once the heli's batteries are charged I'm going to try it out on the stand with manual throttle and tailrotor. The servos on my particular heli are set up like the following:
front: ·larger PW, up (fly more backwards) ·smaller PW, down (fly more·forwards)
right: ·larger PW, up (fly more right) ·smaller PW, down (fly more left)
left: ·larger PW, down (fly more right) ·smaller PW, up (fly more left)
To adjust for your particular 120ccpm setup, first figure out which way your servos move depending on the PW you feed in, then adjust (in my code's nomenclature) the sign of pMul and/or rMul. Also adjust the sign in the lines rOut1 := rOut - (pOut - pOutp)/2 and rOut2 := rOut·+ (pOut - pOutp)/2.
This all assumes that 1500 is your "level" PW (on my heli, when all the servos are at 1500, the swashplate is level).
I almost forgot! Before doing all that, you have to figure out which way your IMU is reading. I wrote a quick code to figure that out called Angle.spin.
Furthermore. I was trying to figure out what the "level" angles of the IMU were so I wrote the code AverageAngles.spin. I've attached that code and an excel file with the outputs. JWood - do these outputs make sense? They seem to be sort of all over the place. I expected as the average of the average of the average was being taken that it'd converge on something but after 20,000,000 averages it still seems quite random. The pretty big drop in roll (down to 8.77) is worrisome. Could it be I'm trying to do too much? Any clues? Maybe a different approach would be a little faster (this took 1hr 9min)?
Oh, I guess you can't attach excels for some reason. Anyway, here's the data. I graphed it and fitted logrithmic curves to see if maybe it was going to a point, didn't really seem to though.
I tried running Hover2.spin with servos and it would work for awhile but then either restart or the servos would "get stuck." This happened with both my standard servos and my high torque digitals on the heli when I was using 5V coming from my breadboard.
Unfortunately I fried my voltage regulators so I can't run the servos off of the designated battery pack for awhile and so I can't tell if power is somehow the problem.
Any clues? The only reason I can think that the Prop would restart a program is if it "browned out" due to a current spike or something, which shouldn't be an issue once I'm running the servos off of the on-board battery pack.
I read all of the posts related to Sparkfun IMU 5 Degrees of Freedom that I brought a few weeks ago. Since you guys got some good experience on this module, I would to like to ask some info:
I connected this IMU to an internal ADC of a microprocessor, if I put IMU flat (Z axis points to ground) without movement， a 12-bit ADC (0 ~ 4095) reads:
Z-Acceleration = 2600 ~ 2620
X-Acceleration = 2180 ~ 2230
Y-Acceleration NOT connected
X Rate = 1950 ~ 1980
Y Rate = 2005 ~ 2028
If I put IMU vertically (X Acceleration axis points to ground) without movement, I got the reading:
X-Acceleration = 2600 ~ 2620
Z-Acceleration = 2180 ~ 2230
Y-Acceleration NOT connected
X Rate = 1950 ~ 1980
Y Rate = 2005 ~ 2028
Do those reading make sense to you? I never get X(or Z)-Acce ~= 2048 and Z(or X)-Acce ~= 2731 combination reading.
I got my implementation of Jwood's project working. I used a demo board and changed the pin assignments some so that i could put the 5DOF unit in the same rows as the DAC.
Here is a video with PID control in action:
For those of you using this solution in a wheeled robot, what kind of control loop timing do you run? Also, are you doing any averaging of the filtered values? Has anyone tried doing differential control with the rate output from the Kalman filter?
The obex Kalman.spin download has the covariants set as follows:
R_angle = 0.3
Q_angle = 0.3
Q_gyro = 0.001
But several months back in this forum in a dialog with simonl you posted/copied:
R_angle = 0.3
Q_angle = 0.001
Q_gyro = 0.003
'They are variables to tweak the kalman filter.
Which is correct.
The proportionality of Q_angle and Q_gyro in the kalman.spin (0.3 vs .003) leaves me puzzled about what tweaking them would entail. Do higher weights indicate positive bias? Is it logarithmic or linear bias?
I ask because when flying 5DOF (in a real airplane!) forward acceleration is read as pitch up and vertical acceleration (coordinated turn) causes roll to be damped to near-zero. Take those two factors out and all works well...but in real flight (scale or otherwise) acceleration is what the k-filter is all about. So before entering the trial-and-error mode, I thought I'd ask.
I also used the IDG300 + accelerometer combo from Sparkfun, great product at a affordable price!!...
Of course, the venerable Propeller and the related awesome Spin/ASM objects are behind the balancing magic act!
Well, this is the first attempt, so the code is pretty crude and simple, the robot can barely balance, and if I push it will fall, I have no provision in the code for that event yet.. :-(
I still don't have any feedback from the motors in the form of wheel encoders, that will be a future addition to the project. unfortunately one of the motors is kind of damaged and it keeps twitching for no apparent reason, adding to the instability of the robot, it is funny to look at it behaving erratically anyway..
Attached is the code with some simple explanations of the core components of the code...
I wanted to say a million thanks to JWood for such great effort behind the IMU.spin and all the contributors of this amazing forum!!... I always stood in awe watching many other great balancing robots, it is almost unbelievable how much hobbyists like me can accomplish right now......
Using this thread I have been able to integrate the the sparkfun IMU board and the IMU spin objects so that the output is displayed on an LCD display (using some modified LCD objects from Obex).
This is my first Propeller project (I went straight in at the deep end).
Needless to say I am very happy! The world's most expensive spirit-level is now up and running and even after an hour there doesn't appear to be any drift.
Hello fellow PropellerHeads!! I have been working on a balancing robot using the excellent IMU.spin object (thanks JWood!!), but I needed more cogs, so I started looking into the IMU and the KalmanFilter objects, trying to figure out a way to reduce the number of cogs, and I think I found a way to do it: if you look into the main IMU code loop, it constantly invokes the KalmanFilter routines state.update and kalman.update, but the KalmanFilter object does not have a main loop constantly running calculations, the KalmanFilter object only goes to work when invoked by IMU, so why not run the state.update and kalman.update internally in the IMU object instead? so I copied those routines into IMU, and it works!, also, the KalmanFilter object uses FloatMath.spin, created by Chip, these are a bunch of spin based Float routines, so I also copied them into the main IMU object in order to support the KalmanFilter routines, they fit nicely into IMU. Next, Float32Full is used by the IMU, and it takes two cogs (FLoat32Full uses Float32A), when you look into it, you notice that IMU uses ATan and ATan2 routines (present on Float32A), so I decided to create a limited version of Float32Full that included those routines, of course I had to remove a bunch of routines from Float32Full in order to be able to fit Atan and Atan2 + the associated routines into one cog. tricky, but I got it working.. so:
Original cog count as follows:
IMU.spin: 1 cog
KalmanFilter.spin: 1 cog for Pitch calculations, 1 cog for Roll calculations = 2 cogs
FloatMath.spin: 1 cog ( this object was invoked by the original KalmanFilter.spin)
Total number of cogs = 4 cogs, so this object saves 3 cogs...
The Limited version of Float32Full running on one cog saves another cog by eliminating the need for Float32A.spin for a total savings of 4 cogs.
Please email me if this information is not correct at joebotics@gmail.com
Attached are the IMU+KF object and the limited version of Float32Full....
I haven't been able to test all the routines on IMU+KF, but when I use these objects on my balancing robot it works. So I would like to validate that:
If these objects are a logical and practical approach to reducing the number of cogs on the IMU Object
If the objects really work as intended
Then for us to get together and test all the routines and fix the bugs and/or improve the objects
I hope this helps... Thanks.. Joebotics
Post Edited (JoeBotics) : 1/15/2009 5:14:40 AM GMT
Alright, I've committed to learning assembly, mainly because I want to fit all the IMU functions into one cog, but the original MCP3208 driver code is what is giving me the hardest time. Does anyone have a version that doesn't have any of the PWM functions and is more heavily commented? Or better yet, a less optimized version with a few lines of code for just sampling one of the pins?
Jay, I'm not sure which driver you are using but the MPC3208_fast is fairly staight forward and does not have the pwm code. It has enough coments that I can understand it. You could delete the average functiions to simplify it more. It is included in the IMU archive set.
@JWood: FYI, your delta-clock glitch is the same identical one as in the Windows 49.7 day bug. Windows provides a 32-bit free-running clock, but a few utilities use it improperly, causing it to crash. The FAA requires that all computers running Windows for their installations must be rebooted every 30 days.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Also, any clue as to why my output is always 1500 despite changes in the error? Maybe another memory issue?
When you hit F8 from your top object, how much free space is shown?
Also, it may be a coincidence, but I note that your debug output has 1 2 3 4 5 6 etc vertically - are the numbers as you expect ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Yeah the 123456 was in the correct order initially, but when things started getting mixed up they kind of got garbled up in the debug screen, there was usually something like 1= 27 37 47 5g 6a or something like that. Occasionally it's skip a few and one of the outputs would sneak in.
The debug terminal was still a little funky though. I added a waitcnt for 1/2s and it came out clean, does that sound like a memory issue? or maybe just a speed issue? like, maybe the Prop is running faster than the COM port can actually take the data or something?
Aha! I still keep missing those float gotcha's! Glad to see you got'em
Servo32 needs to be initialised before you start it:
PUB Servo32_DEMO | temp repeat temp from 0 to 31 'Preset ALL servo's to center position SERVO.Set(temp,1500) 'Note: Servo pins that will be used must be preset before running "SERVO.Start". ' This is because the I/O direction is set here and is only executed ' at the beginning of "SERVO.Start". Servo pins that aren't used will remain ' in their original direction state. SERVO.Start 'Start Servo handlerI got that from within Servo32_demo.spin - hope it helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hover2 = 1 FullDuplexSerial = 1 IMU = 1 MCP3208 = 1 Float32Full = 1 Float32A = 1 FloatString = 0 PID = 0 FullDuplexSerial = 1 (but unused) FloatString = 0 FloatMath = 0 Servo32v3 = 1 PID = 0 Float32 = 1I did this by looking inside each object to see a) if it had subordinate objects; and b) if it, or a subordinate, had a 'cognew' command.
Unless I'm mistaken; even if a parent object has already loaded (say) FullDuplexSerial, if it has a cognew in any called routine (e.g. start) then it gets loaded into a new cog.
So; Hover2.spin is loading IMU, which in-turn is loading Float32Full, which in-turn is loading Float32A - so that's 4 cogs.
I guess you're right on the cog limit!
If you're needing any extra cogs, one option is to investigate Matteo Borri's dynamic math lib in obex - it dynamically starts/stops float-math cogs when required (but I've not used it myself yet).
As for the 1/2s delay fixing your debug - you're only running at 57600, so I'd expect any modern PC to be able to handle that, but the delay does seem to suggest otherwise! On the other hand, I wonder if the problem's down to overflow on the FullDuplexSerial buffer? What buffer size are you using?
4_000 longs would appear to be plenty, but I don't know what your whole code is doing - so I could be wrong!
HTH.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 5/11/2008 10:33:28 AM GMT
I think I'll try taking the debug stuff out of my code and using LEDs to see "where" it's at, that way I can free up one last cog to run the servos, that should do it, hopefully. I'll also check out that dynamic float thingy, sounds interesting.
Beau also told me about presetting the servos - didn't know that, I never read that part in the demo, usually I just read comments in the main code, oh well. What's weird is if you write a super simply code to just turn the servo back and forth back and forth you don't need to do the preset before servo.start, curious.
As for the garbly debugging - I was thinking maybe it wasn't the PC itself but the PropStick or something? I dunno. I'm not too worried about it though, as long as my outputs from PID are making sense and I can get one more cog to run servos I should be good to go, we'll see, I should know by Thursday whether or not I'm graduating anyways...
Re: your note about getting rid of the float stuff, I believe your thinking's good - we only need to convert to degrees if us monkeys need to read it; which of course we do when we're debugging :-(
That said; I see no reason why - with careful programming - we couldn't get it working (and sorta readable) using integer math, but that's beyond me at the moment...
Any chance you'll be posting all your code for other heli' propers?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Yeah I'll post all of my code when it's done. I still need to work out the "mixing" I guess, which will probably look something like this:
PID
PID
pOut
rOut
rOut1 := rOut + (pOut - pOutp)/2
rOut2 := rOut - (pOut - pOutp)/2
pOutp := pOut
rOutp := rOut
servo.set(pPin, pOut)
servo.set(rPin1, rOut1)
servo.set(rPin2, rOut2)
repeat
I guess if altitude isn't really an issue you could skip using the back two servos when adjusting pitch, it would just also affect altitude. Then for roll you'd obviously just adjust the back two in opposite directions.
As for getting rid of all the float stuff, they only reason would be to free up cogs to be able to read in from the RX so that you could switch between stabilized and normal r/c flight. Although...that gives me an idea, I bet I could have it check the RX pins each go round of the PID loop...although that might be way way too slow, since you'd have to wait for an entire pulse before doing anything else. Hmmm...well, I'm not quite there yet, I need to just make it hover first, doing the rest will come later.
But...Jason, if you're reading this, please, please, us Heli guys (or at least me) would LOVE to see a version of the KF that doesn't use any float! By the way I was PMing with Brad (can't rember his user name) and he was saying your latest KF favors the accelerometers too much or something? I dunno, but I told him to post what he thought the problem was.
Hopefully this will work to make the heli hover. I've had good luck with the servos by themselves so once the heli's batteries are charged I'm going to try it out on the stand with manual throttle and tailrotor. The servos on my particular heli are set up like the following:
front:
·larger PW, up (fly more backwards)
·smaller PW, down (fly more·forwards)
right:
·larger PW, up (fly more right)
·smaller PW, down (fly more left)
left:
·larger PW, down (fly more right)
·smaller PW, up (fly more left)
To adjust for your particular 120ccpm setup, first figure out which way your servos move depending on the PW you feed in, then adjust (in my code's nomenclature) the sign of pMul and/or rMul. Also adjust the sign in the lines rOut1 := rOut - (pOut - pOutp)/2 and rOut2 := rOut·+ (pOut - pOutp)/2.
This all assumes that 1500 is your "level" PW (on my heli, when all the servos are at 1500, the swashplate is level).
I almost forgot! Before doing all that, you have to figure out which way your IMU is reading. I wrote a quick code to figure that out called Angle.spin.
Furthermore. I was trying to figure out what the "level" angles of the IMU were so I wrote the code AverageAngles.spin. I've attached that code and an excel file with the outputs. JWood - do these outputs make sense? They seem to be sort of all over the place. I expected as the average of the average of the average was being taken that it'd converge on something but after 20,000,000 averages it still seems quite random. The pretty big drop in roll (down to 8.77) is worrisome. Could it be I'm trying to do too much? Any clues? Maybe a different approach would be a little faster (this took 1hr 9min)?
I tried running Hover2.spin with servos and it would work for awhile but then either restart or the servos would "get stuck." This happened with both my standard servos and my high torque digitals on the heli when I was using 5V coming from my breadboard.
Unfortunately I fried my voltage regulators so I can't run the servos off of the designated battery pack for awhile and so I can't tell if power is somehow the problem.
Any clues? The only reason I can think that the Prop would restart a program is if it "browned out" due to a current spike or something, which shouldn't be an issue once I'm running the servos off of the on-board battery pack.
I read all of the posts related to Sparkfun IMU 5 Degrees of Freedom that I brought a few weeks ago. Since you guys got some good experience on this module, I would to like to ask some info:
I connected this IMU to an internal ADC of a microprocessor, if I put IMU flat (Z axis points to ground) without movement， a 12-bit ADC (0 ~ 4095) reads:
Z-Acceleration = 2600 ~ 2620
X-Acceleration = 2180 ~ 2230
Y-Acceleration NOT connected
X Rate = 1950 ~ 1980
Y Rate = 2005 ~ 2028
If I put IMU vertically (X Acceleration axis points to ground) without movement, I got the reading:
X-Acceleration = 2600 ~ 2620
Z-Acceleration = 2180 ~ 2230
Y-Acceleration NOT connected
X Rate = 1950 ~ 1980
Y Rate = 2005 ~ 2028
Do those reading make sense to you? I never get X(or Z)-Acce ~= 2048 and Z(or X)-Acce ~= 2731 combination reading.
Thank you for any input in advance.
David
I got my implementation of Jwood's project working. I used a demo board and changed the pin assignments some so that i could put the 5DOF unit in the same rows as the DAC.
Here is a video with PID control in action:
For those of you using this solution in a wheeled robot, what kind of control loop timing do you run? Also, are you doing any averaging of the filtered values? Has anyone tried doing differential control with the rate output from the Kalman filter?
The obex Kalman.spin download has the covariants set as follows:
But several months back in this forum in a dialog with simonl you posted/copied:
Which is correct.
The proportionality of Q_angle and Q_gyro in the kalman.spin (0.3 vs .003) leaves me puzzled about what tweaking them would entail. Do higher weights indicate positive bias? Is it logarithmic or linear bias?
I ask because when flying 5DOF (in a real airplane!) forward acceleration is read as pitch up and vertical acceleration (coordinated turn) causes roll to be damped to near-zero. Take those two factors out and all works well...but in real flight (scale or otherwise) acceleration is what the k-filter is all about. So before entering the trial-and-error mode, I thought I'd ask.
Regards,
Paul Mace
I created a barely balancing robot based on the great IMU.spin and some other ideas from this very very interesting thread....
I used two giant servos (Hobbico CS-80 - Tower Hobbies TS-80) modified for continuous rotation. here is how I modified them:
http://joebotics.googlepages.com/continuousrotationservo-hobbicotowerhobb
I also used the IDG300 + accelerometer combo from Sparkfun, great product at a affordable price!!...
Of course, the venerable Propeller and the related awesome Spin/ASM objects are behind the balancing magic act!
Well, this is the first attempt, so the code is pretty crude and simple, the robot can barely balance, and if I push it will fall, I have no provision in the code for that event yet.. :-(
I still don't have any feedback from the motors in the form of wheel encoders, that will be a future addition to the project. unfortunately one of the motors is kind of damaged and it keeps twitching for no apparent reason, adding to the instability of the robot, it is funny to look at it behaving erratically anyway..
Here is short video of the poor thing in action:
http://www.youtube.com/watch?v=nC_SEczvqik
Attached is the code with some simple explanations of the core components of the code...
I wanted to say a million thanks to JWood for such great effort behind the IMU.spin and all the contributors of this amazing forum!!... I always stood in awe watching many other great balancing robots, it is almost unbelievable how much hobbyists like me can accomplish right now......
Post Edited (JoeBotics) : 9/9/2008 6:07:14 PM GMT
I have a big grin on my face. Thank you all!
Using this thread I have been able to integrate the the sparkfun IMU board and the IMU spin objects so that the output is displayed on an LCD display (using some modified LCD objects from Obex).
This is my first Propeller project (I went straight in at the deep end).
Needless to say I am very happy! The world's most expensive spirit-level is now up and running and even after an hour there doesn't appear to be any drift.
Thankyou, thankyou, thankyou!
Original cog count as follows:
IMU.spin: 1 cog
KalmanFilter.spin: 1 cog for Pitch calculations, 1 cog for Roll calculations = 2 cogs
FloatMath.spin: 1 cog ( this object was invoked by the original KalmanFilter.spin)
Total number of cogs = 4 cogs, so this object saves 3 cogs...
The Limited version of Float32Full running on one cog saves another cog by eliminating the need for Float32A.spin for a total savings of 4 cogs.
Please email me if this information is not correct at joebotics@gmail.com
Attached are the IMU+KF object and the limited version of Float32Full....
I haven't been able to test all the routines on IMU+KF, but when I use these objects on my balancing robot it works. So I would like to validate that:
If these objects are a logical and practical approach to reducing the number of cogs on the IMU Object
If the objects really work as intended
Then for us to get together and test all the routines and fix the bugs and/or improve the objects
I hope this helps... Thanks.. Joebotics
Post Edited (JoeBotics) : 1/15/2009 5:14:40 AM GMT
Donald
..... on line 334, although I have my doubts that all those FloatToStrings can be computetd in 100 ms....
Why all the converts? Is that because of an interface to LabView or some similar thing?
Jack
Filtered Rate: 4.20
Bias: -4.00
Raw Rate: 0.20
Jack