I understand that a Kalman filter is the optmal way to combine several (noisy)
signal ( after reading kalman tutorials over and over again, i almost dare saying
that i also understand why)
Still, im thinking over a few things.
We have some more information that i'm not sure the kalman-filter ´knows'
We know that the rate-gyros detect 'rotation' and nothing else. This means,
This means that any measured acceleration MUST have som corresponding
measurement from gyros tob be 'tilt-related', otherwise, the measured acceleration
in the vectorial result of eatrhgravity(g) AND eventually, acceleration or retardation
with constant tilt-angles...
In my specific problem, +/- 3 degrees kalman-output-tilt-angle at moderate acc./ret
of my balancing bot, i have NO output from the gyro.
Maybe, the Kalman-filter could be combined with some softlevel truth table condition ?
About my lawnmover. Yes, all the potential investors asked: Are you using a perimeter Wire?
And my answer was yes! And my thoughts were: If i had·inveted a reliable, lowcost, outdoor/anyweather working, 1/2inch tolerance, navigating system, i'd·been somewhere else ;-)
The robocut perimeter/buried wire fence is a simple sytem of a oscillating signal in a
buried wire loop, picked up by tuned coils·on the robocut mainboard.
______________________________________________________________________
Greetings
JWood-
Looking forward to the 3 state KF. I would like to port this to the mFPU 3.1, which is also available from SparkFun. A 5DOF with an additional Gryo will match their 6DOF at a much lower cost point. I am interested in UAV applications but am not made of money, much to my wife's disbelief... I am working with a friend that designs R/C Heli's (eaglesviewaerial.com) for aerial photo and we would like to integrate a auto-hover. Getting a working KF would be a great boost for my project.
Thanks again for all of your hard work.
-John
Yay, so I'm not the only one eagerly awaiting the 3 state KF for UAV heli' then!
I wasn't going to bother with the 3rd gyro - thinking I'd just rely on a standard heli' heading-hold gyro - but maybe I'll need to re-think?
Let us know how you progress.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
JWood: I agree, SLAM is really worth looking at, and could be very useful also for UAV stabilization. You might even make precise automatic takeoff and landing a possibility then.
JWood: I've been experimenting with your kalman filter, and it works really well!
Is it possible to modify the object to read the tilt angles on both the x and y axis ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The faster you crash.. The bigger the mess...
This is something every one has wanted. So I just updated my Object on·obex that includes the MIT license and both X and Y angles. I'm also experimenting with handling when you take the unit 360 degree's and your angles jump back and forth between 180 and -180. What I'm trying to do is maintain how many times the the unit spins 360 and just add that to the current angle. So you would get 181, 182, ..., 1000's of degrees in both directions. To get the current actual angle you just need to know the total number of rotations. This is commented out in this current version.
If you write a driver for the mFPU 3.1 that would rock! I was thinking about doing that my self to off load 2 cogs and not do the float math on the propeller. But what's really nice about the propeller is currently you only need the 3DOF unit, ADC and propeller to get this working. Adding a 4th object is a considerable increase of external components. Although having those two extra cogs could end up being a winner if your running out of resources in an application.
I'll see about writing the firmware to get that mFPU 3.1 up and running. You know anyone that has already written a driver for it on another platform? Could be a good jumping off point.
Is the data you reference produced by real world signals? Or are you simulating the accelerometer input?
If you are showing results from real signals, have you examined the power supply to your transducer? Or power supply to the entire circuit?
Have you eliminated the possibility spurious RF energy is affecting your system? Are you shielding the accelerometer signal leads and/or the entire development system?
woodrowg,
I'm not real sure what your referring to here. I'm using the actual measurements from a 3DOF accelerometer being read in by a 12 bit ADC.
I don't have any noise in the system causing harm. Accelerometers produce very noisy measurements as a standard. So I'm cleaning it up and merging gyro measurements·with the Kalman Filter. My power supply produces a decently clean output for all my general purposes. People have reported that by putting there fingers close to the 5DOF circuit slightly alters the output. I haven't been able to do this unless I start actually·touching the pens of the ADC.
I'm not shielding anything from anything at this point. My unit doesn't need to be water proof and as far as I can tell it's not affected from RF. Every speaker in my house goes off when I get a call on my Black Berry but·I don't see it affecting the system.
are you referring to a previous post before the previous two I just did?
robotcut,
You wouldn't want to make me 3 of those printed boards you designed would you? For a fee of course. It would save me a good deal of time hooking these up.
Jason-
I have just ordered a uMFPU and 5Dof from Sparkfun. I am in the process of converting part of the Kalman filter object to function calls in the uMFPU. I can only convert part of it due to the way that the uMFPU handles functions. Once I have the system up and running I will send you the code and some stats.
-John Butterfield
Jason-
I have not seen the SPI interface to the uMFPU but will be using it for the communications part. I am taking the Kalman Filter code and transferring as much as possible to the uMFPU as a set of Functions. I will then embed the SPI code and required spin code in your object. Should be getting my hardware on Wed Apr 2, so I can start transferring code and testing some time after that.
-John
I'm a senior Mechanical Engineer at CSUF.
They are trying to get us in touch with EE type stuff for controls, etc.
I'm supposed to have an Ion-X helicopter flying on its own with GPS and a camera by the end of the semester.
Totally new to all of this, I learned some C and then used a BASIC Stamp for simple stuff.
I understand the concept of how all the hardware is supposed to work together (the Propeller, IMU, and ADC), I have all of it all wired up, and the software concepts, just not the nitty gritty.
To get the point - I guess my question is, what does IMU.spin give me?
I thought with a 5dof IMU I'm supposed to be able to get 5 things, but what I see it putting out is only Angle and Q_Bias. I've seen in the forum Rate as well.
What are Angle, Rate, and Q_bias relative to the IMU itself? I think if I understand these I can probably·write a simple program to control the servos and keep it level or keep it traveling in a certain direction, etc.
Luckily we built a gimble stand for it so it can rock around and go up and down without going kaboom (see Mechanical - that's what I understand, haha). Let me know if you'd like to see any picks of it, it's really nice for learning to fly or testing these types of programs.
PS Congrats to all of you who have succesfully utilized all this stuff, I'm still trying to understand dira, outa, and ina, haha. ·
I'm sure JWood will chime in at some point - and is MUCH better placed than me to explain thing - but I'll have a go:
The raw output of the IMU (that's x,y,z accelerations and x,y rates of turn) are highly likely to be very noisy (read: 'understatement'!). You'll also find that gyros tend to 'drift' a lot too.
The IMU.spin implements a Kalman Filter (KF) that's apparently the best way of getting much more stable readings.
Importantly, the KF also fuses the readings of acceleration and rate-of-turn, to give you (in this case) the angles (attitude) of the IMU board.
HTH, and yes, please post pic's etc. I'm waaay behind you in ability I suspect, but I'm also going to try and get my heli' to hover...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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've since seen the NEW IMU.spin that, to me anyways, makes much for sense with all the PUBs. So now I'm trying to figure out how to test it before I strap it on the heli. I was thinking of using a graph or some sort of value return to the monitor. I downloaded JWood's graphing program but couldn't really figure out how to use it. I think I just need to spend some more time in the Prop manual, I'm only up to page 117 and am still trying to figure out how to do simple things that I used to know in BASIC.
Next time I'm in the lab at school I'll take some pics of the training stand and post them.
JWood - to answer your question about applications in more depth - we have a Miniature Aircraft Ion-X that the Prof wants to do all kinds of stuff. We will have two modes - flight stabilization mode that severely limits the motion of the copter to make it easier to fly/learn (limits roll and pitch to a preset, say +/- 5deg). In this mode the radio talks to the receiver which sends PWM to the Prop, the Prop (at least this is the plan) then sends modified PWM to the servos (based on info from the IMU and your fancy KF). The eigth channel on our radio is used to switch to GPS mode. In this mode, the GPS talks to the Prop (not really sure how yet though, that's not my section of the project) and, again, with info from the IMU keeps it flying steady and goes to a specified GP. Once it arrives the camera goes through a preset pan/tilt/zoom. At any point during GPS mode though the channels on the radio that were for the servos now control pan/tilt/zoom of the camera, so you can point and shoot while the Prop does all the flying!
The goal is to show this off to local high-school kids to get them interested in engineering.
Hello again all. I think I'm starting to get this stuff!
I figured before I fly all over and take pictures and all of that, how about just hovering, while ignoring altitude and yaw even (I don't if it goes up and down or spins, I just don't want it to drag a blade). So I wrote a program that I think should get it to hover on our stand.
Any feedback/criticism/etc. would be GREATLY appreciated as I really don't know what the heck I'm doing, haha. Especially in regards to my CON section and some of my variables in reference to others' objects.
I attached the file but I'll also give the text below.
Thanks again! - Matt Coppler
''
''Hover.spin by Matt Coppler, 04/06/08
{{This object is designed to hover a helicopter while still allowing pilot to control altitude and yaw.
Unfortunately it should only work for 90deg CCPM, not 120deg CCPM - that's one of things I've got to
figure out to modify this program for. Just looking for concept's right now though.}}
{{I use Jason Wood's IMU.spin (which uses Chip Gracey's MCP3208.spin and Cam Thompson's Float32Full.spin)
and Beau Schwabe's Servo32v3}}
{{Throttle and Yaw Channels should be connected to servos as normal. Pitch and Roll channels should be left
disconnected. Pitch and Roll servos should be connected to pins of choice.}}
CON · _CLKMODE = XTAL1 + PLL16x···························· 'Set to external crystal, 16x PLL · _XINFREQ = 5_000_000···································· 'Frequency on XI pin is 5MHz
· {I'm not really sure if this CON section is necessary or even compatible with Servo32v3, I haven't · tested this program yet as you may already know if you are reading this}
VAR · word StackPitch[noparse][[/noparse]9]··································· 'Stack space for Pitch Control Cog · word StackRolll[noparse][[/noparse]9]···································· 'Stack space for Roll Control Cog · PinPitch := 16··········································'Plug Pitch Control Servo into Pin 16 · PinRoll := 17···········································'Plug Roll Control Servo into Pin 17
· {I'm not sure how much stack space I need for the cogs. Is 9 words enough? Also, do I need to define · variables for other objects? See "width" from Servo32v3 below}
PUB CogAssign · COGNEW(HoverPitch, @StackPitch)······················ 'Starts PUB HoverPitch in a new cog · COGNEW(HoverRoll, @StackRoll)························· 'Starts PUB HoverRoll in a new cog
· {I wanted each one in it's own dedicated cog so that there isn't any "misses" I guess. I'm think · a single cog could handle it, but I don't know since I didn't write the other OBJs, safer to just · dedicate I guess}
PUB HoverPitch · REPEAT···················································· 'Infinite Loop ··· IMU.get_angle_Pitch································ 'Returns Pitch Angle from Kalman Filter ··· IF get_angle_Pitch = 0····························· 'If the heli is level Pitch-wise ····· NEXT··················································· 'Start the iteration over ··· IF get_angle_Pitch < 0····························· 'If the heli is tilted forward ····· Width := Width + 10······························ 'Increment PW by 10us ····· SERVO.Set(PinPitch, Width)······················'Control Pitch Servo, tilt heli backwards ··· ELSE······················································ 'If the heli is tilted backwards ····· Width := Width - 10······························ 'Decrement PW by 10us ····· SERVO.Set(PinPitch, Width)·······················'Control Pitch Servo, tilt heli forwards
· {I'm not sure if get_angle_Pitch is the variable that IMU.spin is going to return. Also, I'm not · sure if what I did with Width is going to work} ·
PUB HoverRoll · REPEAT··················································· 'Infinite Loop ··· IMU.get_angle_Roll································· 'Returns Roll Angle from Kalman Filter ··· IF get_angle_Roll = 0······························ 'If the heli is level Roll-wise ····· NEXT··················································· 'Start the iteration over ··· IF get_angle_Roll < 0······························ 'If the heli is tilted left ····· Width := Width + 10······························'Increment PW by 10us ····· SERVO.Set(PinRoll, Width)·······················'Control Roll Servo, tilt heli right ··· ELSE······················································ 'If the heli is tilted right ····· Width := Width - 10······························ 'Decrement PW by 10us ····· SERVO.Set(PinRoll, Width)·······················'Control Roll Servo, tilt heli left
· {I'm not sure if get_angle_Roll is the variable that IMU.spin is going to return. Also, I'm not · sure if what I did with Width is going to work}
1. Your CON section looks OK to me - as this is the top object, it's the right place to have those declarations; and they should work fine with the other objects.
2. You've taught me something! I'd not realised you could use 'NEXT' in that way - neat!
3. I suspect you're going to have to do some trial-n-error to see if +/-10us is acceptable. Don't forget that whatever value you arrive at in the lab will most likely be far different when you get out to the field, unless you simulate gusting wind conditions... In fact I believe you'll actually need to implement PID to get stability anyway.
4. I don't see any failsafe code - GASP - I'd strongly advise that you at least check for valid values coming back from IMU.
5. PUB CogAssign (being your start object) should be where you have your main loop. I guess you've not put anything here yet, as you've been concentrating on the pitch & roll bits; but CogAssign would be where you'd have your 'supervisor / master' control code. What I'm trying (badly) to get at is: I'd put a 'repeat' loop here that has checks for: pilot/auto hover/GPS mode (e.g. checking the pulse-width of the appropriate Rx channel); code dependent on currently selected mode; more failsafe checking; etc.
6. I'm pretty sure you're correct in using 'get_angle_xxx'.
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
3. I figured as much for the value. Doesn't the Kalman filter use PID though? How would that be implemented?
4. I wasn't too worried about a failsafe right now since we have the test stand. What would it look like though? Checking to see if get_angle_xxx is >360 or something?
Eventually I'll have to pass all the servo PWM from the receiver, through the Prop, and to the servos. I plan on limiting pilot input though (so if you yard over left or just barely touch it either way it initiates, say, 5deg left). So I want to read an input to see if the radio is giving anything at all, but with PWM the majority of the time the pin will be low, so how could I even tell if·the pilot is giving a command·or not?
3. No, KF doesn't use PID (I once thought the same, but was told otherwise). I've not implemented a PID yet, but I think there's an object in the object exchange (written by Paul Baker I think), and there's a good discussion of PID in Parallax's 'Industrial control' education kit too.
4. Ever since I've been flying heli's - and seeing first-hand how much damage they can do when things go wrong - I've tried to keep safety at the highest priority
I think JWood said the IMU outputs +/-180, so you'd be watching for that range on IMU output. You'll also need to decide what's 'normal' for your mode channel. In this case we know that a normal pulse range would be about 1000ms to 2000ms, so those would be our outer limits, but don't forget about the pulse ranges between too - if you're using a 3-position switch, and it's set out output (say) 1000ms for pilot control; 1500ms for auto hover; and 2000ms for GPS; what mode would you want failsafe to go to if the Prop suddenly sees >2000ms or <1000ms?
I'm not sure you're correct about PWM output being low most of the time. As I understand it, a properly functioning Rx will output a regular 'stream' of pulses to the servos, in order for them to stay in position. Now, I know that PCM will output the last 'good' pulse received (until after a set time, when it kicks into its failsafe mode), but I'm not sure what PWM Rxs do. I believe they always output whatever pulse they receive - which is why they're more susceptible to RFI, and that's exactly why you should build-in failsafe yourself
As for you intention of limiting output to +/-5deg; there's something in the back of my mind that's worrying about that. I'll have to snooze on it, but I'm wondering if that might limit the pilot's ability to stabilize the heli' if it starts to get a bit too 'wild'? I'm probably worrying unduly, but it might be an issue if the Ion-X is light, and susceptible to windy conditions?
As an aside, have you trawled through the DIY Drones site? It's mostly for UAV 'planks', but there's at least one heli' UAV being done there.
Regarding CCPM: I was trying to avoid it for my autopilot but I couldn't find an MPM-based heli' at a decent price. I've ended-up with a 120deg CCPM also, and still haven't figured the math for servo movements - that's not to say it's complex, just that I haven't figured it yet I think that for x-deg of pitch the front servo moves +/-y and the back two servos would move -/+(y/2). Roll is much simpler, requiring the back two servos to move equal - but opposite - amounts. If there's anyone out there that can supply me with the math for this I'd love to hear from you
BTW: What batteries will you be using, and how long do your flights last? I've got a Century Swift 16, and I can't get the battery (LiPo 4S1P) to last more than about 8mins :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
3. I found, "PID Routines.spin" by Craig Weber on OBEX that simply returns, "get_set_point" - not really sure what to do with that, haha, couldn't find anything by Paul Baker either. I have the education kit, couldn't find a discussion on PID or Industrial Control in it or on the website. I did find the forum though: http://forums.parallax.com/showthread.php?p=529609.
4. Definitely, I planned on·implementing a failsafe like some sort of switch to flip the thing back in to regular old fly mode and just landing it by hand, although if it'd be me landing it I think I trust a freqedout (like that BS2 ref?) prop better.
New 5. (Freqs) Prop shouldn't ever SEE >2000 or <1000 coming from the receiver right? But they might OUTPUT >2000 or <1000, so if that happened, um, jump out of the OBJ and go into standard flight somehow? I dunno? Anybody got any suggestions on failsafes?
New 6. (PWM) Yeah I think you're right, I was thinking of 1ms to 2ms pulses with 20ms refresh rates. But for digital servos (which I have) it's only 5ms refresh, but it doesn't HAVE to wait that long, the downtime (I think) can be minimal as long as the pulse is the right width. I found "BS2 Functions.spin" on OBEX that allows the old BS2 command FREQIN, so I might be able to use that to read what the receiver is sending to the Prop. None of this should really matter in GPS mode though since the PWM is generated from data from the GPS module, not the receiver.
New 7. (Stabilization) Point well taken, I'm not a helicopter guru, I can't even fly one in RealFlight. +/-5deg was only an example though, we'll play with it to find a good preset value that allows the pilot to move the thing around but not do loopty-loops or dumpt the thing. Once it's in GPS mode though it will have a broader range to keep it stable - once it's out of the hands of inexperienced pilots like myself .
Saw the DIY Drones Arduino project - pretty cool that they used a Wii Nunchcuk, cheap compared to SparkFun's 5dof IMU I guess.
New 8. (CCPM) I'll have to do somemore reading on this too, hopefully somebody out there can find some math.
New 9. (Batteries) I don't know what batteries we have actually, the previous group woring with the heli tested flight time and payload. I believe with a payload of 9lb (in addition to the battery) it was able to run safely for 14min but I'm not certain. Really, we wanted a Nitro copter, it'd be way easier to deal with (and no exploding LiPols...) but our school couldn't comprehend that GAS would be safer than BATTERIES - typical beuacracy, welcome to America, we should go back to the way you Brits do it, the King makes the rules! Sorry, off topic.
Just wondering (and Jason I'm sure you'd be the best to answer this) where does, "ST," from the IMU go to? In IMU.spin the wiring diagram just shows it going to nothing. Same thing with, "7," on the MCP3208. Thanks!
The IMU's "ST" is for self-test. Unless you need to use it, it can be left unconnected. (If you do wish to use it, just connect it to a PChip output pin. I think it's active high; raising the PChip output will cause the IMU to output steady values - if the IMU is operating normally.)
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
Incidentally; I'm not sure why JWood has pin 6 connected to Vdd (JWood?)
Here's how I've connected (which means I've also changed the applicable parts of IMU.spin...)
┌────°─────┐
┐ 3.3V ─│0 16│─┬ +3.3V
│─ X Accl ────│1 15│─┘
│─ Y Accl ────│2 14│── GND
│─ Z Accl ────│3 13│── CLK:PIN
│─ ST │4 12│─┬ DIO:PIN
│─ Volt Ref ──│5 11│─┘
│─ Y Rate ────│6 10│── CS:PIN
│─ X Rate ────│7 9│── GND
│─ GND └──────────┘
│─ 3.3V
┘
I did it this way purely to keep wiring simple, but it does mean that ST is connected to Ch.4 of the 3208 (when on a breadboard) - but that just gets ignored
<edit>
Got pins & channels mixed-up - OK now tho'
</edit>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 finally got all of the wiring and stuff right but I'm having some trouble getting the IMU to work, hopefully I didn't fry it when I was soldering - can you do that?
I've attached a picture along with the object that I used to test and see if everything is working.
In the hyperterminal I was getting values of around -1022952491. These values didn't vary much even when I rocked the board around. Any ideas?
The test program uses IMU.sping, KalmanFilter.spin, FullDuplexSerial.spin, and all of their dependents.
I'd appreciate any help! The text for the object is below if that makes it any easier:
'' From Parallax Inc. Propeller Education Kit - Objects Lab v1.0
''HelloFullDuplexSerial.spin
''Test message to HyperTerminal.
''Modified by Matt Coppler on 04/13/08 to test Kalman Filter
CON ·· · _clkmode = xtal1 + pll16x · _xinfreq = 5_000_000 ··
OBJ ·· · Debug: "FullDuplexSerial" · IMU: "IMU"
PUB TestMessages · IMU.start(15,14,13) · ''Send test messages and to HyperTerminal.
· Debug.start(31, 30, 0, 57600) · repeat ··· Debug.str(string("This is a test message!", 10, 13)) ··· waitcnt(clkfreq + cnt) ··· Debug.dec(IMU.get_angle_pitch) ··· waitcnt(clkfreq + cnt)
·
MCoppler,
I'm so sorry for not responding until now. I must have turned off the notifications for this thread. I thought it was dead.
So .. You are trying to hover a Helicopter using the X and Y axis IMU.spin that I posted. As Jaakko has mentioned, All the outputs are floating points. You can use either use the floating point objects to convert the readings to DEC and send that·via the Serial or use the FloatToString to convert the floating points to a string pointer and send that via Serial. If you just send the readings from the object you will get some crazy numbers as you have seen.
As for wiring of the ADC: I believe I initially wired up the ST pen because the ease of mounting the two units close to one another. You do not need to wire up the Self Test (ST) pen at all.
I'm sure you could fry the unit while soldering but it's not too likely. I doubt you have fried the unit. To test your ADC and 5DOF units you can simply use the MCP3208 object found on Object exchange to get the analog readings in Decimal format. It would look something like this:
CON
xAxis = 0
yAxis = 1
zAxis = 2
VRef = 3
yRate = 4
xRate = 5
supply = 6
DIO = 15
CLK = 14
CS = 13
OBJ
ADC : "MCP3208"
Debug : "FullDuplexSerial"
PUB start
ADC.start(DIO, CLK, CS, %01111111)
Debug.start(31, 30, 0, 57600)
repeat
Debug.str(string("This is the xAxis Reading: "))
Debug.dec( ADC.in(xAxis) )
Debug.str(10, 13)
Debug.str(string("This is the yAxis Reading: "))
Debug.dec( ADC.in(yAxis) )
Debug.str(10, 13)
Debug.str(string("This is the zAxis Reading: "))
Debug.dec( ADC.in(zAxis) )
Debug.str(10, 13)
Debug.str(string("This is the yRate Reading: "))
Debug.dec( ADC.in(yRate) )
Debug.str(10, 13)
Debug.str(string("This is the xRate Reading: "))
Debug.dec( ADC.in(xRate) )
Debug.str(10, 13)
waitcnt(clkfreq + cnt)
This will validate that both your ADC and 5DOF units work. Every reading should be between·1 and 4096 (12 bits (0-4095)). This unit reads +/- 3G's so you can cut that 12 bit spread into 6 sections or about 683 units·per section. Based on the documentation of the accelerometer 0G's would equal 1/2 VDD or 2048 so +1G would be 2048 - 683 = 1765 and -1G would be 2048 + 683 = 2731. You can use that info to validate the correct working of your Accelerometer.
Once you have validated that your ADC and 5DOF units are both in the proper working order you can move on to the Kalman filter and it's Floating Points.
using the MCP8203 object returns Decimal numbers that are natively supported by the Propeller. Floating Points on the other hand require extra objects to pack and un-pack the bits held in a LONG. This is what makes doing a simple Debug.dec( IMU.get_angle_pitch ) go crazy. Like I had mentioned above you can use the FloatToString object also found in object exchange to do something like this
and that will print the correct values that you expect to see ...·in degrees. +/- 180 of them. After you implament the FloatToString object you will begin to see the actual Filter working.
Now .. On to the hard part! Making your Helicopter hover. This will be no easy task because just like simonl said you will have un-foreseen objects in your way. Such as wind, rain, people and plants. I have no doubt that you will need to use a PID (Proportional integral derivative)·routine to accomplish this task. What it does is compensate for the Error in your system. Meaning, if your tilting to far forward then·tilt the rotor to compensate but only compensate the different in how for forward your tilting and where you want to be tilting (error). Andy Lindsay has·a great article about it in these forums ... I just cant find it right now.
Potential issues. I have never used this filter on such a "noisy" platform. a Helicopter will generate enormous amount of vibrations·in X, Y and Z axis let alone the thrust being generated from the spinning of the rotor's. This may throw your angles off TOO much for the PID loops to compensate for. You could try·adjusting the Q_angle and Q_gyro covariant noise variables in the KalmanFilter.spin object·to also help compensate for that. Basically making it so you trust the Gyros more than Accelerometer. I'm working on removing such noise from the filter but it's turning out to be harder than originally though it to be.
With that all said please don't let that scare you away. It could work just fine and you could easily mount the unit on a material that could absorbed most of the vibrations. Work on getting your readings correct first then work on hovering your Helicopter.
Please let me know if you need any more help on getting your readings to come out correctly. I would be glad to help in any way. Also I have re-setup email notifications to this thread.
MCoppler,
One more thing. When dealing with Float Math you can not write code to compare a decimal with a float like below
PUB HoverPitch
REPEAT 'Infinite Loop
IMU.get_angle_Pitch 'Returns Pitch Angle from Kalman Filter
IF get_angle_Pitch = 0 'If the heli is level Pitch-wise
NEXT 'Start the iteration over
IF get_angle_Pitch < 0 'If the heli is tilted forward
Width := Width + 10 'Increment PW by 10us
SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli backwards
ELSE 'If the heli is tilted backwards
Width := Width - 10 'Decrement PW by 10us
SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli forwards
Instead you need to use floats to compare with like below
PUB HoverPitch
REPEAT 'Infinite Loop
IMU.get_angle_Pitch 'Returns Pitch Angle from Kalman Filter
IF get_angle_Pitch = 0.0 'If the heli is level Pitch-wise
NEXT 'Start the iteration over
IF get_angle_Pitch < 0.0 'If the heli is tilted forward
Width := Width + 10 'Increment PW by 10us
SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli backwards
ELSE 'If the heli is tilted backwards
Width := Width - 10 'Decrement PW by 10us
SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli forwards
Do you notice how I turned your·· " = 0 " and " < 0 " into· " = 0.0 " and " < 0.0 " ? That is how you compare floating points. You need to be very careful about not mixing Floats and Decimals up. It's caused me a few nights of pain!
Comments
I understand that a Kalman filter is the optmal way to combine several (noisy)
signal ( after reading kalman tutorials over and over again, i almost dare saying
that i also understand why)
Still, im thinking over a few things.
We have some more information that i'm not sure the kalman-filter ´knows'
We know that the rate-gyros detect 'rotation' and nothing else. This means,
This means that any measured acceleration MUST have som corresponding
measurement from gyros tob be 'tilt-related', otherwise, the measured acceleration
in the vectorial result of eatrhgravity(g) AND eventually, acceleration or retardation
with constant tilt-angles...
In my specific problem, +/- 3 degrees kalman-output-tilt-angle at moderate acc./ret
of my balancing bot, i have NO output from the gyro.
Maybe, the Kalman-filter could be combined with some softlevel truth table condition ?
Sounds to simple...whats wrong in my ideas ?
________________________________________________________________
JWood!
About my lawnmover. Yes, all the potential investors asked: Are you using a perimeter Wire?
And my answer was yes! And my thoughts were: If i had·inveted a reliable, lowcost, outdoor/anyweather working, 1/2inch tolerance, navigating system, i'd·been somewhere else ;-)
The robocut perimeter/buried wire fence is a simple sytem of a oscillating signal in a
buried wire loop, picked up by tuned coils·on the robocut mainboard.
______________________________________________________________________
Greetings
Looking forward to the 3 state KF. I would like to port this to the mFPU 3.1, which is also available from SparkFun. A 5DOF with an additional Gryo will match their 6DOF at a much lower cost point. I am interested in UAV applications but am not made of money, much to my wife's disbelief... I am working with a friend that designs R/C Heli's (eaglesviewaerial.com) for aerial photo and we would like to integrate a auto-hover. Getting a working KF would be a great boost for my project.
Thanks again for all of your hard work.
-John
Yay, so I'm not the only one eagerly awaiting the 3 state KF for UAV heli' then!
I wasn't going to bother with the 3rd gyro - thinking I'd just rely on a standard heli' heading-hold gyro - but maybe I'll need to re-think?
Let us know how you progress.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Is it possible to modify the object to read the tilt angles on both the x and y axis ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The faster you crash.. The bigger the mess...
This is something every one has wanted. So I just updated my Object on·obex that includes the MIT license and both X and Y angles. I'm also experimenting with handling when you take the unit 360 degree's and your angles jump back and forth between 180 and -180. What I'm trying to do is maintain how many times the the unit spins 360 and just add that to the current angle. So you would get 181, 182, ..., 1000's of degrees in both directions. To get the current actual angle you just need to know the total number of rotations. This is commented out in this current version.
Thanks for the support!
Jason
·· Wood
If you write a driver for the mFPU 3.1 that would rock! I was thinking about doing that my self to off load 2 cogs and not do the float math on the propeller. But what's really nice about the propeller is currently you only need the 3DOF unit, ADC and propeller to get this working. Adding a 4th object is a considerable increase of external components. Although having those two extra cogs could end up being a winner if your running out of resources in an application.
I'll see about writing the firmware to get that mFPU 3.1 up and running. You know anyone that has already written a driver for it on another platform? Could be a good jumping off point.
<!--a.wdlink { font-family: Arial, Helvetica, sans-serif; color: #666666; text-decoration: none;}a.wdlink:current { font-family: Arial, Helvetica, sans-serif; color: #666666; text-decoration: none;}a.wdlink:visited { font-family: Arial, Helvetica, sans-serif; color: #666666; text-decoration: none;}a.wdlink:active { font-family: Arial, Helvetica, sans-serif; color: #666666; text-decoration: none;}a.wdlink:hover { font-family: Arial, Helvetica, sans-serif; color: #666666; text-decoration: underline;}-->
Jason
[size=+0][/size]· Wood
EDIT: mFPU already has a BS2 example using both I2C and SPI. Should be easy from that point. I've got one on order. I'll keep you posted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (JWood) : 3/15/2008 12:51:17 AM GMT
If you are showing results from real signals, have you examined the power supply to your transducer? Or power supply to the entire circuit?
Have you eliminated the possibility spurious RF energy is affecting your system? Are you shielding the accelerometer signal leads and/or the entire development system?
Just a thought.
I'm not real sure what your referring to here. I'm using the actual measurements from a 3DOF accelerometer being read in by a 12 bit ADC.
I don't have any noise in the system causing harm. Accelerometers produce very noisy measurements as a standard. So I'm cleaning it up and merging gyro measurements·with the Kalman Filter. My power supply produces a decently clean output for all my general purposes. People have reported that by putting there fingers close to the 5DOF circuit slightly alters the output. I haven't been able to do this unless I start actually·touching the pens of the ADC.
I'm not shielding anything from anything at this point. My unit doesn't need to be water proof and as far as I can tell it's not affected from RF. Every speaker in my house goes off when I get a call on my Black Berry but·I don't see it affecting the system.
are you referring to a previous post before the previous two I just did?
Jason
·· Wood
The dual axis imu works very well, thank you for making this available on the obex!
To me the 180 to -180 jump doesn't really matter, it's easy to code around that.
Thank you again!
Raf
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The faster you crash.. The bigger the mess...
robotcut,
You wouldn't want to make me 3 of those printed boards you designed would you? For a fee of course. It would save me a good deal of time hooking these up.
Let me know.
Thanks!
Jason
·· Wood
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I have just ordered a uMFPU and 5Dof from Sparkfun. I am in the process of converting part of the Kalman filter object to function calls in the uMFPU. I can only convert part of it due to the way that the uMFPU handles functions. Once I have the system up and running I will send you the code and some stats.
-John Butterfield
I just realized that I.K
I have not seen the SPI interface to the uMFPU but will be using it for the communications part. I am taking the Kalman Filter code and transferring as much as possible to the uMFPU as a set of Functions. I will then embed the SPI code and required spin code in your object. Should be getting my hardware on Wed Apr 2, so I can start transferring code and testing some time after that.
-John
They are trying to get us in touch with EE type stuff for controls, etc.
I'm supposed to have an Ion-X helicopter flying on its own with GPS and a camera by the end of the semester.
Totally new to all of this, I learned some C and then used a BASIC Stamp for simple stuff.
I understand the concept of how all the hardware is supposed to work together (the Propeller, IMU, and ADC), I have all of it all wired up, and the software concepts, just not the nitty gritty.
To get the point - I guess my question is, what does IMU.spin give me?
I thought with a 5dof IMU I'm supposed to be able to get 5 things, but what I see it putting out is only Angle and Q_Bias. I've seen in the forum Rate as well.
What are Angle, Rate, and Q_bias relative to the IMU itself? I think if I understand these I can probably·write a simple program to control the servos and keep it level or keep it traveling in a certain direction, etc.
Luckily we built a gimble stand for it so it can rock around and go up and down without going kaboom (see Mechanical - that's what I understand, haha). Let me know if you'd like to see any picks of it, it's really nice for learning to fly or testing these types of programs.
PS Congrats to all of you who have succesfully utilized all this stuff, I'm still trying to understand dira, outa, and ina, haha.
·
I'm sure JWood will chime in at some point - and is MUCH better placed than me to explain thing - but I'll have a go:
The raw output of the IMU (that's x,y,z accelerations and x,y rates of turn) are highly likely to be very noisy (read: 'understatement'!). You'll also find that gyros tend to 'drift' a lot too.
The IMU.spin implements a Kalman Filter (KF) that's apparently the best way of getting much more stable readings.
Importantly, the KF also fuses the readings of acceleration and rate-of-turn, to give you (in this case) the angles (attitude) of the IMU board.
HTH, and yes, please post pic's etc. I'm waaay behind you in ability I suspect, but I'm also going to try and get my heli' to hover...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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've since seen the NEW IMU.spin that, to me anyways, makes much for sense with all the PUBs. So now I'm trying to figure out how to test it before I strap it on the heli. I was thinking of using a graph or some sort of value return to the monitor. I downloaded JWood's graphing program but couldn't really figure out how to use it. I think I just need to spend some more time in the Prop manual, I'm only up to page 117 and am still trying to figure out how to do simple things that I used to know in BASIC.
Next time I'm in the lab at school I'll take some pics of the training stand and post them.
JWood - to answer your question about applications in more depth - we have a Miniature Aircraft Ion-X that the Prof wants to do all kinds of stuff. We will have two modes - flight stabilization mode that severely limits the motion of the copter to make it easier to fly/learn (limits roll and pitch to a preset, say +/- 5deg). In this mode the radio talks to the receiver which sends PWM to the Prop, the Prop (at least this is the plan) then sends modified PWM to the servos (based on info from the IMU and your fancy KF). The eigth channel on our radio is used to switch to GPS mode. In this mode, the GPS talks to the Prop (not really sure how yet though, that's not my section of the project) and, again, with info from the IMU keeps it flying steady and goes to a specified GP. Once it arrives the camera goes through a preset pan/tilt/zoom. At any point during GPS mode though the channels on the radio that were for the servos now control pan/tilt/zoom of the camera, so you can point and shoot while the Prop does all the flying!
The goal is to show this off to local high-school kids to get them interested in engineering.
-Matt Coppler
I figured before I fly all over and take pictures and all of that, how about just hovering, while ignoring altitude and yaw even (I don't if it goes up and down or spins, I just don't want it to drag a blade). So I wrote a program that I think should get it to hover on our stand.
Any feedback/criticism/etc. would be GREATLY appreciated as I really don't know what the heck I'm doing, haha. Especially in regards to my CON section and some of my variables in reference to others' objects.
I attached the file but I'll also give the text below.
Thanks again! - Matt Coppler
''
''Hover.spin by Matt Coppler, 04/06/08
{{This object is designed to hover a helicopter while still allowing pilot to control altitude and yaw.
Unfortunately it should only work for 90deg CCPM, not 120deg CCPM - that's one of things I've got to
figure out to modify this program for. Just looking for concept's right now though.}}
{{I use Jason Wood's IMU.spin (which uses Chip Gracey's MCP3208.spin and Cam Thompson's Float32Full.spin)
and Beau Schwabe's Servo32v3}}
{{Throttle and Yaw Channels should be connected to servos as normal. Pitch and Roll channels should be left
disconnected. Pitch and Roll servos should be connected to pins of choice.}}
CON
· _CLKMODE = XTAL1 + PLL16x···························· 'Set to external crystal, 16x PLL
· _XINFREQ = 5_000_000···································· 'Frequency on XI pin is 5MHz
· {I'm not really sure if this CON section is necessary or even compatible with Servo32v3, I haven't
· tested this program yet as you may already know if you are reading this}
OBJ
· SERVO : "Servo32v3"·································· 'Reference's Servo Control object
· IMU : "IMU"·············································· 'Reference's Kalman Filter object
VAR
· word StackPitch[noparse][[/noparse]9]··································· 'Stack space for Pitch Control Cog
· word StackRolll[noparse][[/noparse]9]···································· 'Stack space for Roll Control Cog
· PinPitch := 16··········································'Plug Pitch Control Servo into Pin 16
· PinRoll := 17···········································'Plug Roll Control Servo into Pin 17
· {I'm not sure how much stack space I need for the cogs. Is 9 words enough? Also, do I need to define
· variables for other objects? See "width" from Servo32v3 below}
PUB CogAssign
· COGNEW(HoverPitch, @StackPitch)······················ 'Starts PUB HoverPitch in a new cog
· COGNEW(HoverRoll, @StackRoll)························· 'Starts PUB HoverRoll in a new cog
· {I wanted each one in it's own dedicated cog so that there isn't any "misses" I guess. I'm think
· a single cog could handle it, but I don't know since I didn't write the other OBJs, safer to just
· dedicate I guess}
PUB HoverPitch
· REPEAT···················································· 'Infinite Loop
··· IMU.get_angle_Pitch································ 'Returns Pitch Angle from Kalman Filter
··· IF get_angle_Pitch = 0····························· 'If the heli is level Pitch-wise
····· NEXT··················································· 'Start the iteration over
··· IF get_angle_Pitch < 0····························· 'If the heli is tilted forward
····· Width := Width + 10······························ 'Increment PW by 10us
····· SERVO.Set(PinPitch, Width)······················'Control Pitch Servo, tilt heli backwards
··· ELSE······················································ 'If the heli is tilted backwards
····· Width := Width - 10······························ 'Decrement PW by 10us
····· SERVO.Set(PinPitch, Width)·······················'Control Pitch Servo, tilt heli forwards
· {I'm not sure if get_angle_Pitch is the variable that IMU.spin is going to return. Also, I'm not
· sure if what I did with Width is going to work}
·
PUB HoverRoll
· REPEAT··················································· 'Infinite Loop
··· IMU.get_angle_Roll································· 'Returns Roll Angle from Kalman Filter
··· IF get_angle_Roll = 0······························ 'If the heli is level Roll-wise
····· NEXT··················································· 'Start the iteration over
··· IF get_angle_Roll < 0······························ 'If the heli is tilted left
····· Width := Width + 10······························'Increment PW by 10us
····· SERVO.Set(PinRoll, Width)·······················'Control Roll Servo, tilt heli right
··· ELSE······················································ 'If the heli is tilted right
····· Width := Width - 10······························ 'Decrement PW by 10us
····· SERVO.Set(PinRoll, Width)·······················'Control Roll Servo, tilt heli left
· {I'm not sure if get_angle_Roll is the variable that IMU.spin is going to return. Also, I'm not
· sure if what I did with Width is going to work}
Not sure if I'll be much help, but here goes:
1. Your CON section looks OK to me - as this is the top object, it's the right place to have those declarations; and they should work fine with the other objects.
2. You've taught me something! I'd not realised you could use 'NEXT' in that way - neat!
3. I suspect you're going to have to do some trial-n-error to see if +/-10us is acceptable. Don't forget that whatever value you arrive at in the lab will most likely be far different when you get out to the field, unless you simulate gusting wind conditions... In fact I believe you'll actually need to implement PID to get stability anyway.
4. I don't see any failsafe code - GASP - I'd strongly advise that you at least check for valid values coming back from IMU.
5. PUB CogAssign (being your start object) should be where you have your main loop. I guess you've not put anything here yet, as you've been concentrating on the pitch & roll bits; but CogAssign would be where you'd have your 'supervisor / master' control code. What I'm trying (badly) to get at is: I'd put a 'repeat' loop here that has checks for: pilot/auto hover/GPS mode (e.g. checking the pulse-width of the appropriate Rx channel); code dependent on currently selected mode; more failsafe checking; etc.
6. I'm pretty sure you're correct in using 'get_angle_xxx'.
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
3. I figured as much for the value. Doesn't the Kalman filter use PID though? How would that be implemented?
4. I wasn't too worried about a failsafe right now since we have the test stand. What would it look like though? Checking to see if get_angle_xxx is >360 or something?
Eventually I'll have to pass all the servo PWM from the receiver, through the Prop, and to the servos. I plan on limiting pilot input though (so if you yard over left or just barely touch it either way it initiates, say, 5deg left). So I want to read an input to see if the radio is giving anything at all, but with PWM the majority of the time the pin will be low, so how could I even tell if·the pilot is giving a command·or not?
3. No, KF doesn't use PID (I once thought the same, but was told otherwise). I've not implemented a PID yet, but I think there's an object in the object exchange (written by Paul Baker I think), and there's a good discussion of PID in Parallax's 'Industrial control' education kit too.
4. Ever since I've been flying heli's - and seeing first-hand how much damage they can do when things go wrong - I've tried to keep safety at the highest priority
I think JWood said the IMU outputs +/-180, so you'd be watching for that range on IMU output. You'll also need to decide what's 'normal' for your mode channel. In this case we know that a normal pulse range would be about 1000ms to 2000ms, so those would be our outer limits, but don't forget about the pulse ranges between too - if you're using a 3-position switch, and it's set out output (say) 1000ms for pilot control; 1500ms for auto hover; and 2000ms for GPS; what mode would you want failsafe to go to if the Prop suddenly sees >2000ms or <1000ms?
I'm not sure you're correct about PWM output being low most of the time. As I understand it, a properly functioning Rx will output a regular 'stream' of pulses to the servos, in order for them to stay in position. Now, I know that PCM will output the last 'good' pulse received (until after a set time, when it kicks into its failsafe mode), but I'm not sure what PWM Rxs do. I believe they always output whatever pulse they receive - which is why they're more susceptible to RFI, and that's exactly why you should build-in failsafe yourself
As for you intention of limiting output to +/-5deg; there's something in the back of my mind that's worrying about that. I'll have to snooze on it, but I'm wondering if that might limit the pilot's ability to stabilize the heli' if it starts to get a bit too 'wild'? I'm probably worrying unduly, but it might be an issue if the Ion-X is light, and susceptible to windy conditions?
As an aside, have you trawled through the DIY Drones site? It's mostly for UAV 'planks', but there's at least one heli' UAV being done there.
Regarding CCPM: I was trying to avoid it for my autopilot but I couldn't find an MPM-based heli' at a decent price. I've ended-up with a 120deg CCPM also, and still haven't figured the math for servo movements - that's not to say it's complex, just that I haven't figured it yet
BTW: What batteries will you be using, and how long do your flights last? I've got a Century Swift 16, and I can't get the battery (LiPo 4S1P) to last more than about 8mins :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
3. I found, "PID Routines.spin" by Craig Weber on OBEX that simply returns, "get_set_point" - not really sure what to do with that, haha, couldn't find anything by Paul Baker either. I have the education kit, couldn't find a discussion on PID or Industrial Control in it or on the website. I did find the forum though: http://forums.parallax.com/showthread.php?p=529609.
4. Definitely, I planned on·implementing a failsafe like some sort of switch to flip the thing back in to regular old fly mode and just landing it by hand, although if it'd be me landing it I think I trust a freqedout (like that BS2 ref?) prop better.
New 5. (Freqs) Prop shouldn't ever SEE >2000 or <1000 coming from the receiver right? But they might OUTPUT >2000 or <1000, so if that happened, um, jump out of the OBJ and go into standard flight somehow? I dunno? Anybody got any suggestions on failsafes?
New 6. (PWM) Yeah I think you're right, I was thinking of 1ms to 2ms pulses with 20ms refresh rates. But for digital servos (which I have) it's only 5ms refresh, but it doesn't HAVE to wait that long, the downtime (I think) can be minimal as long as the pulse is the right width. I found "BS2 Functions.spin" on OBEX that allows the old BS2 command FREQIN, so I might be able to use that to read what the receiver is sending to the Prop. None of this should really matter in GPS mode though since the PWM is generated from data from the GPS module, not the receiver.
New 7. (Stabilization) Point well taken, I'm not a helicopter guru, I can't even fly one in RealFlight. +/-5deg was only an example though, we'll play with it to find a good preset value that allows the pilot to move the thing around but not do loopty-loops or dumpt the thing. Once it's in GPS mode though it will have a broader range to keep it stable - once it's out of the hands of inexperienced pilots like myself
Saw the DIY Drones Arduino project - pretty cool that they used a Wii Nunchcuk, cheap compared to SparkFun's 5dof IMU I guess.
New 8. (CCPM) I'll have to do somemore reading on this too, hopefully somebody out there can find some math.
New 9. (Batteries) I don't know what batteries we have actually, the previous group woring with the heli tested flight time and payload. I believe with a payload of 9lb (in addition to the battery) it was able to run safely for 14min but I'm not certain. Really, we wanted a Nitro copter, it'd be way easier to deal with (and no exploding LiPols...) but our school couldn't comprehend that GAS would be safer than BATTERIES - typical beuacracy, welcome to America, we should go back to the way you Brits do it, the King makes the rules! Sorry, off topic.
Just wondering (and Jason I'm sure you'd be the best to answer this) where does, "ST," from the IMU go to? In IMU.spin the wiring diagram just shows it going to nothing. Same thing with, "7," on the MCP3208. Thanks!
The IMU's "ST" is for self-test. Unless you need to use it, it can be left unconnected. (If you do wish to use it, just connect it to a PChip output pin. I think it's active high; raising the PChip output will cause the IMU to output steady values - if the IMU is operating normally.)
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
What about pin7 on the MCP3208?
Pin 7 is not connected.
Incidentally; I'm not sure why JWood has pin 6 connected to Vdd (JWood?)
Here's how I've connected (which means I've also changed the applicable parts of IMU.spin...)
┌────°─────┐ ┐ 3.3V ─│0 16│─┬ +3.3V │─ X Accl ────│1 15│─┘ │─ Y Accl ────│2 14│── GND │─ Z Accl ────│3 13│── CLK:PIN │─ ST │4 12│─┬ DIO:PIN │─ Volt Ref ──│5 11│─┘ │─ Y Rate ────│6 10│── CS:PIN │─ X Rate ────│7 9│── GND │─ GND └──────────┘ │─ 3.3V ┘I did it this way purely to keep wiring simple, but it does mean that ST is connected to Ch.4 of the 3208 (when on a breadboard) - but that just gets ignored
<edit>
Got pins & channels mixed-up - OK now tho'
</edit>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 4/13/2008 7:57:22 PM GMT
I think I finally got all of the wiring and stuff right but I'm having some trouble getting the IMU to work, hopefully I didn't fry it when I was soldering - can you do that?
I've attached a picture along with the object that I used to test and see if everything is working.
In the hyperterminal I was getting values of around -1022952491. These values didn't vary much even when I rocked the board around. Any ideas?
The test program uses IMU.sping, KalmanFilter.spin, FullDuplexSerial.spin, and all of their dependents.
I'd appreciate any help! The text for the object is below if that makes it any easier:
'' From Parallax Inc. Propeller Education Kit - Objects Lab v1.0
''HelloFullDuplexSerial.spin
''Test message to HyperTerminal.
''Modified by Matt Coppler on 04/13/08 to test Kalman Filter
CON
··
· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000
··
OBJ
··
· Debug: "FullDuplexSerial"
· IMU: "IMU"
PUB TestMessages
· IMU.start(15,14,13)
· ''Send test messages and to HyperTerminal.
· Debug.start(31, 30, 0, 57600)
· repeat
··· Debug.str(string("This is a test message!", 10, 13))
··· waitcnt(clkfreq + cnt)
··· Debug.dec(IMU.get_angle_pitch)
··· waitcnt(clkfreq + cnt)
What you get from IMU.spin is a floating point number, you´ve got to round it.
best regards,
Jaakko
MCoppler,
I'm so sorry for not responding until now. I must have turned off the notifications for this thread. I thought it was dead.
So .. You are trying to hover a Helicopter using the X and Y axis IMU.spin that I posted. As Jaakko has mentioned, All the outputs are floating points. You can use either use the floating point objects to convert the readings to DEC and send that·via the Serial or use the FloatToString to convert the floating points to a string pointer and send that via Serial. If you just send the readings from the object you will get some crazy numbers as you have seen.
As for wiring of the ADC: I believe I initially wired up the ST pen because the ease of mounting the two units close to one another. You do not need to wire up the Self Test (ST) pen at all.
I'm sure you could fry the unit while soldering but it's not too likely. I doubt you have fried the unit. To test your ADC and 5DOF units you can simply use the MCP3208 object found on Object exchange to get the analog readings in Decimal format. It would look something like this:
CON xAxis = 0 yAxis = 1 zAxis = 2 VRef = 3 yRate = 4 xRate = 5 supply = 6 DIO = 15 CLK = 14 CS = 13 OBJ ADC : "MCP3208" Debug : "FullDuplexSerial" PUB start ADC.start(DIO, CLK, CS, %01111111) Debug.start(31, 30, 0, 57600) repeat Debug.str(string("This is the xAxis Reading: ")) Debug.dec( ADC.in(xAxis) ) Debug.str(10, 13) Debug.str(string("This is the yAxis Reading: ")) Debug.dec( ADC.in(yAxis) ) Debug.str(10, 13) Debug.str(string("This is the zAxis Reading: ")) Debug.dec( ADC.in(zAxis) ) Debug.str(10, 13) Debug.str(string("This is the yRate Reading: ")) Debug.dec( ADC.in(yRate) ) Debug.str(10, 13) Debug.str(string("This is the xRate Reading: ")) Debug.dec( ADC.in(xRate) ) Debug.str(10, 13) waitcnt(clkfreq + cnt)This will validate that both your ADC and 5DOF units work. Every reading should be between·1 and 4096 (12 bits (0-4095)). This unit reads +/- 3G's so you can cut that 12 bit spread into 6 sections or about 683 units·per section. Based on the documentation of the accelerometer 0G's would equal 1/2 VDD or 2048 so +1G would be 2048 - 683 = 1765 and -1G would be 2048 + 683 = 2731. You can use that info to validate the correct working of your Accelerometer.
Once you have validated that your ADC and 5DOF units are both in the proper working order you can move on to the Kalman filter and it's Floating Points.
using the MCP8203 object returns Decimal numbers that are natively supported by the Propeller. Floating Points on the other hand require extra objects to pack and un-pack the bits held in a LONG. This is what makes doing a simple Debug.dec( IMU.get_angle_pitch ) go crazy. Like I had mentioned above you can use the FloatToString object also found in object exchange to do something like this
and that will print the correct values that you expect to see ...·in degrees. +/- 180 of them. After you implament the FloatToString object you will begin to see the actual Filter working.
Now .. On to the hard part! Making your Helicopter hover. This will be no easy task because just like simonl said you will have un-foreseen objects in your way. Such as wind, rain, people and plants. I have no doubt that you will need to use a PID (Proportional integral derivative)·routine to accomplish this task. What it does is compensate for the Error in your system. Meaning, if your tilting to far forward then·tilt the rotor to compensate but only compensate the different in how for forward your tilting and where you want to be tilting (error). Andy Lindsay has·a great article about it in these forums ... I just cant find it right now.
Potential issues. I have never used this filter on such a "noisy" platform. a Helicopter will generate enormous amount of vibrations·in X, Y and Z axis let alone the thrust being generated from the spinning of the rotor's. This may throw your angles off TOO much for the PID loops to compensate for. You could try·adjusting the Q_angle and Q_gyro covariant noise variables in the KalmanFilter.spin object·to also help compensate for that. Basically making it so you trust the Gyros more than Accelerometer. I'm working on removing such noise from the filter but it's turning out to be harder than originally though it to be.
With that all said please don't let that scare you away. It could work just fine and you could easily mount the unit on a material that could absorbed most of the vibrations. Work on getting your readings correct first then work on hovering your Helicopter.
Please let me know if you need any more help on getting your readings to come out correctly. I would be glad to help in any way. Also I have re-setup email notifications to this thread.
Thanks
Jason
·· Wood
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
One more thing. When dealing with Float Math you can not write code to compare a decimal with a float like below
PUB HoverPitch REPEAT 'Infinite Loop IMU.get_angle_Pitch 'Returns Pitch Angle from Kalman Filter IF get_angle_Pitch = 0 'If the heli is level Pitch-wise NEXT 'Start the iteration over IF get_angle_Pitch < 0 'If the heli is tilted forward Width := Width + 10 'Increment PW by 10us SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli backwards ELSE 'If the heli is tilted backwards Width := Width - 10 'Decrement PW by 10us SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli forwardsInstead you need to use floats to compare with like below
PUB HoverPitch REPEAT 'Infinite Loop IMU.get_angle_Pitch 'Returns Pitch Angle from Kalman Filter IF get_angle_Pitch = 0.0 'If the heli is level Pitch-wise NEXT 'Start the iteration over IF get_angle_Pitch < 0.0 'If the heli is tilted forward Width := Width + 10 'Increment PW by 10us SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli backwards ELSE 'If the heli is tilted backwards Width := Width - 10 'Decrement PW by 10us SERVO.Set(PinPitch, Width) 'Control Pitch Servo, tilt heli forwardsDo you notice how I turned your·· " = 0 " and " < 0 " into· " = 0.0 " and " < 0.0 " ? That is how you compare floating points. You need to be very careful about not mixing Floats and Decimals up. It's caused me a few nights of pain!
Jason
·· Wood
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔