I started with the same imu but added the 3rd axis and removed the need to use float32full and its 2 cogs and the adc cog, so it went from 2 to 3 axis and from 4 to 1 cog. and got a fair bit of optimization on the way. I think there is still some optimization left but not 5x. If you dont need the 3rd axis removing that would help. perhaps reduce to 2 axis and split then into 2 cogs, then we will get ~144 Hz. and we still reduced the cogs from 4 to 2.
Cluso - The plastic is HDPE, so it's quite strong (plastic cutting board material).· I think I made it 1/8th of an inch thick (might've been 1/16"...).· The first one I did made it 1/4", and it was larger (about 10" across).· I could stand on it without it flexing, but it was too heavy.· This one is much lighter - I don't have an actual weight for you, but I can put it on a scale later.
I'm making them on my DIY CNC machine, so I can cut any shape I can model.· I have considered doing cutouts in the top & bottom to lighten it, but I doubt it'll be necessary - The piece was pretty light as it was.· Motors & battery are by far the bulk of the weight.
I've also thought of doing an arrangement of interlocking plywood or fiberglass pieces, kind of like this one: http://www.rcgroups.com/forums/showpost.php?p=8546317&postcount=34
...but the contoured plastic just looks so cool.· [noparse]:)[/noparse]· I also cut it the shape I did so I could tell where the front was more easily. ·
Cluso99 - be careful with transparent or translucent case, the pressure sensor - scp1000 and bmp085 are light sensitive and from playing with the scp1000 its very sensitive - change the light conditions is the same as 10's feet.
You might be interested in the attached object. Its a modified version of·Beau's pwm object which I use in all my bots. It supports pwm and servo output for upto 32 pins, there are 2 differences
1. Since it can control upto 32 pins, there is no need for multiple objects e.g. drive esc and control a camera pan/tilt servos. This object only starts a single cog even if used multiple times.
2. I added a ServoFast routine which allows you to set the servo period e.g. if the last parameter is 5000 then the servo output will update at 200Hz. The resolution of the pulses is 8.15us.
I use this object for controling servo pan/tilt, steering servos, esc, HB25·and pwm for motor drivers such as L293D.
The servofast routine is new but just replaces a constant with a parameter.
Yeah, the aluminum one looks pricey, but I was thinking of doing something with roughly the same visual look, but cut from light plywood instead. I think I prefer the current plastic shell.
I checked - it's 1/8th of an inch thick, and weighs 177 grams. It's very strong - if I stand on it I can bow in the top, and I can flex it some by hand. I think I could cut the thickness in half and still have it be perfectly useable.
Cluso99, I have been playing with the scp1000 and bmp085 and it looks like the scp1000 is better for this purpose. The variablity of the output is much lower with the scp1000 than the bmp085. If you leave them both on the bench and reading them, the output varies, the variance for the scp1000 is much lower than the bmp085 - the bmp085 is looking like 5x the variance than the scp1000. This translates into approx +-5cm for the scp1000 and +-25cm for bmp085. I am running them both in the fastest read method for each and applying a small amount of filtering to the output. I havn't tried the other read options for each at the moment. The bmp085 can be read faster than the scp1000 so I will try using one of the slower methods for the bmp085 and see if I can better results. the other option is to use more filtering with the bmp085 since I can get more readings in the same time interval this would also work.
Any idea how often we want results from these sensors, the scp1000 is limited to 1.8 times/sec, the bmp085 I should be able to read at 50 times/sec depending on what other sensors are read, with the itg3200, hmc5843 and adxl345 we are prob talking about reading all the sensors in ~20ms with the current code I have (spin). though I have only timed the scp1000, bmp085 and bmp085 so far (~6.5ms for all 3). So we are talking about 50 time/sec for sensor updates.
So I can see all sensor reading in 1 cog, rc receiver reading in 1 cog, esc output 1 cog, imu 1 cog, main loop (rc -> imu, imu -> esc) in 1 cog. So thats 5 Cogs. If the rc receiver outputs ppm I might be able to read that on the main cog since I use counters for ppm input, taking it to 4 Cogs.
Yes Tim, that is what I expected from the specs of the chips. That is why initially I wanted to use the SCP1000-D11 (I2C version). However, it is listed as obsolete on the manufacturers website and they failed to reply to this question when I emailed them. So, my choice is BMP085 unless anyone can assure me it will remain available.
Your update speed indicates that on landing, the BMP085 is faster and hence will be better even tho' the range is less. If we really want proper ground detection the parallax ultrasonic sensor could be plugged into a spare RX channel to do this.
I am actually not concerned about having enough cogs as I can always redo anything in pasm if stuck. The prop will outperform the Atmega32 which is being used by the quad group (sorry, forget their website at present).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Do you mean the AeroQuad? I took a quick look at it and it their update rates are anything to go by we may be rewriting quite a lot in pasm, e.g. they read the sensors at 500 times/sec, though our sensors dont work that fast.
I also noticed they dont use a kalman filter in their imu, they use a much simpler filter and they have exceptions built in for some cases my and other imu code dont handle e.g. ignoring effect of acceleration on accelerators, banking effects, etc.
The object I posted above - pwm_32_sv2.spin works with faster update rates. I tested with an esc at 200Hz update rate and it works without problem. I used this esc http://www.hobbycity.com/hobbyking/store/uh_viewitem.asp?idproduct=4218. The object can control upto 32 escs with one cog. I tested it controlling 4 escs at 200Hz. The resolution of the pulses is 8.15us, its based on Beau's original pwm object.
I guess I have been bitten, I have mostly finished building a quad, the frames done, the motors/escs are running, some of the sensors are working, the receivers next.
That’s very impressive. Looks almost like CGI, it’s so smooth.
I wonder what kind of horsepower, (CPU), they are using. Also, is a canned, (programmed), move, or do they do it with sensors?
Jim
Edit: Nevermind. Not that impressive. I just caught the audio and they are using a 20 camera system for navagation/feedback? . How would that work in the real world?
What are people doing about software for a quad?
Since I decided to put a quad together, I have been modifying that code I use on my bots to the quad. Its only got pieces tested and it hasn't flown but it supports
4/6/8 motor configurations with + and x (only 4+ test so far)
receiver RC servo and PPM input (only PPM tested)
GPS NMEA (object tested but not tested as part of system)
sensors ITG3200, bmp085, adxl345, hmc5843 (object tested but not tested as part of system)
IMU (object tested with other sensors)
Stablization (not tested and not working)
pan/tilt for camera (object tested but not tested as part of system)
video overlay for wireless camera (overlay system from prop backpack - based on backpak object)
Some of the system config - rc channel usage, gps type, motor config is held in eeprom config and can be changed from debug port (partly tested)
I am sure its got lots of bugs but I can post it so far if it might help someone get going, or I can wait until I have more working and tested.
Since it doesn't have stablization working I dont recommend trying to fly with it but it might be helpful for testing
The other question is what other support is needed, the obvious one after stablization is gps waypoint flying but anything else? I have part support for battery monitoring and ping but they are not connected to anything.
Tim: That's a nice quad. What are the motors (you have probably said previously)?
I have not done any software yet but there are a few including Jason and Cessnapilot·that have some prop software running. My plan was to try the stabilisation while having the copter tethered by short string so the copter could not crash.
The frame is different, I used the 10mm x 10mm tubes from hobbyking but I used http://hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=5136·with the side cut from the square mount·so they would mount on the end of the square tubes and glued them on. It meant I didn't have to drill the carbon fiber to mount the motors.
The motors are fairly small but the quad weighs 800gr complete including battery so it should be ok. I have both the GWS 8040 3 blade prop and the EPP8045 2 blade prop so I will see which is better.
I will be tethering it down this weekend and working on stablization.
I looked at Cessnapilot IMU but I am going to try mine first.
Great work Tim. Your mounting box for the electronics looks interesting. Is it metal??? and if so how much does it weigh?
How stable/flexible are the carbon fibre arms? I presume they are the ones with a round hole through the center.
What LiPo are you using? 1500kV seems a bit high for 3S so I am presuimg it is a 2S.
Cunning method of mounting. My motor came with that mounting bracket so I could put it to good use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The box is carbon fiber, the rc receiver is underneath and the gps is on top so they are not affected. The top/sides come off as 1 piece, the bottom stiffens the arms. I haven't weighed the top but I will. I am hoping the top will also act as a ground plane for the gps as well.
Yes the arms are the ones with the round hole, they seem ok, they are 8" long from center, so the motors are ~9" from center with the mounts, so with the current props they could be a bit shorter. I did it as 1 length 16" and 2 pieces 7.8". They take a bit to bend them but dont squash them they split lengthways fairly easily.
I am using 3S so yes the motors may be a bit fast. Some of the comments I have seen about the motors say they ran with 8" props with 3S and got ~300gr thrust so in theory I have 400gr of lift but I will find out soon.
I did see somewhere where they glued a rod inside the hole to add to the strength of the 10x10mm cf arms.
I am unsure whether there is any interest in making a pcb for the mounting arms. We could just drill a cf plate(s) as you have done. Anyone ???
I am trying to make my pcb and sensors fit into a hammond box for protection. Of course, what I want on the pcb does not quite fit of course and I am trying various ways to solve this problem.
Do you have the GPS working (reading values into the prop)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have several test programs that test the drivers separately
1. ESC/ITG3200/ADXL345/HMC5843/BMP085
2. PPM RC receiver
3. servo style RC receiver - dont have a way to test this since I use PPM input
4. GPS
1,2,4 are currently working.
I have the full program with them all integrated, with the IMU off the RC receiver controls the ESCs. The IMU is running but I haven't had a chance to check its output nor is it using the IMU to stablize the quad. The GPS is being read into the prop but isn't doing anything with the data apart from being parsed and translated into numbers. Checking the IMU and using it to stablize the quad is the next stage.
Excellent Tim. I have not tried any of (1,2,3 or 4) except I have driven the ESC and motor successfully. I expect the GPS to be easy as I have already done this with my boat's GPS although this is for later anyway.
What I intended to do was to use the PC via the propplug to give comands to the prop while trying the tethering. Obviously you will need to see how much power is required to get the motors to lift the copter. Then you can use the gyro/accelerometer to stabilise the copter. Next you can use the compass for heading. Lastly will come the pressure as for now the craft is tethered so you will not see any altitude variations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I am trying the stablization differently, the RC inputs normally affect the rate of change - throttle rate of altitude change, forward pitch change, etc. So I have the IMU tracking rate of change of pitch/roll/yaw using the accelerometer/gyro/compass.
Then I have 4 pids one each for pitch/roll/yaw/alititude, the RC input sets the pids setpoint using the 2 joysticks, the IMU/pressure sensor outputs are the pids actual values and the pids output controls the motors through a mapping function that maps pitch/roll/yaw/altitude to motor speeds. The mapping function changes depending on how many motors and + or x config but the IMU/PIDs shouldn't change except perhaps the PID constants.
If all RC receiver inputs are 0, i.e. center the 2 joysticks, then the quad hovers in one position.
This means the IMU/stablization can first be tested by printing the motor values, not setting the motors, and move the quad and see how the motor IMU and motor values changes for different RC inputs.
I have a self-written SPIN object that'll read the ITG-3200 at roughly 250hz if you want it, and I've modded the standard RC-input code to only have 4 inputs (I have one for 6 as well). I've also modded the servo out object to update 8 servos at 200hz instead of 32 @ 50hz. You're welcome to any of that code.
I'm going to be hooking up a digital (I2C or SPI) accelerometer in the moderately near future, at which point I'll probably fold the ITG-3200 and digital accel into a single PASM object for speed and compactness. I'll post that too if I do it and you folks aren't there yet.
Tim's description of his flight model is exactly what I'm doing too - The PID is the "controller", and the RC inputs just place the set points for the PIDs. You'll need different gain settings for the rudder and the altitude, since they respond at different rates than the pitch and roll. I expect altitude control to be a VERY slow loop. If I understand right, altimeter readings are fairly inaccurate, so you'll probably want to do a short moving average of them, meaning the control will be somewhat soft.
You'll probably want to have some "feed forward" of the throttle (direct control), as sudden throttle changes should override the desire to hold an altitude, while a "steady" throttle position should maintain the current rate of change. If the current rate is close to zero, the user probably "intends" zero. It's all so picky.
Is it worth setting up a place so we can all put our code there while we sort out what we need?
I use Brad's BST to build so I can ifdef drivers in/out depending on whats required. So it shouldn't be difficult to allow #defines for the various sensors and other features and for each of us to build the right version.
For motor/frame config I have that stored in eeprom and over the debug port can change the config/pid constants etc. and then save in eeprom rather than rebuilding each time.
Couple of things, the configuration of motors/props I have used is enough to get off the ground for the weight I have (800gr), dont know yet how fast it will be but it lifts off somewhere 1/2-2/3 throttle buts its not stable yet so no real flying.
You can see a little vibration on the arms at about takeoff but I dont know how that translates to the IMU yet, nor have I tried balancing the props to see if that helps.
I've gotten mine off the ground this weekend just using the ITG-3200 and straight P (no I or D) loops. It's a handful, and needs a bunch of tuning, so I'm going to add an LCD display and some digital knobs so I don't have to keep reprogramming the EEPROM every time I want to change one of the gains. [noparse]:)[/noparse]
Yeah, I've been thinking of getting me one of those for exactly that reason, but it's actually pretty easy to just have a rotary encoder knob with a button to cycle through the gains and change the values. My last quad just used the transmitter for programming, and even that worked well. Push the elevator & aileron stick to the upper-right, and the throttle-rudder stick to the lower-left, and it'd enter program mode. Then from there you used the throttle stick to choose the parameter to set, and the aileron to increase / decrease the value. It was actually pretty intuitive, and nice because it was a proportional input, not digital. All the values were written back into the EEPROM locations for the init values I stored in the DAT section.
I may just have to copy that code across, now that I think about it... It was handy. I don't like flying the thing next to my PC. [noparse]:)[/noparse]
Comments
I'm making them on my DIY CNC machine, so I can cut any shape I can model.· I have considered doing cutouts in the top & bottom to lighten it, but I doubt it'll be necessary - The piece was pretty light as it was.· Motors & battery are by far the bulk of the weight.
I've also thought of doing an arrangement of interlocking plywood or fiberglass pieces, kind of like this one: http://www.rcgroups.com/forums/showpost.php?p=8546317&postcount=34
...but the contoured plastic just looks so cool.· [noparse]:)[/noparse]· I also cut it the shape I did so I could tell where the front was more easily.
·
1. Since it can control upto 32 pins, there is no need for multiple objects e.g. drive esc and control a camera pan/tilt servos. This object only starts a single cog even if used multiple times.
2. I added a ServoFast routine which allows you to set the servo period e.g. if the last parameter is 5000 then the servo output will update at 200Hz. The resolution of the pulses is 8.15us.
I use this object for controling servo pan/tilt, steering servos, esc, HB25·and pwm for motor drivers such as L293D.
The servofast routine is new but just replaces a constant with a parameter.
Tim: Thanks for the info about translucent cases affecting the pressure transducers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I checked - it's 1/8th of an inch thick, and weighs 177 grams. It's very strong - if I stand on it I can bow in the top, and I can flex it some by hand. I think I could cut the thickness in half and still have it be perfectly useable.
Any idea how often we want results from these sensors, the scp1000 is limited to 1.8 times/sec, the bmp085 I should be able to read at 50 times/sec depending on what other sensors are read, with the itg3200, hmc5843 and adxl345 we are prob talking about reading all the sensors in ~20ms with the current code I have (spin). though I have only timed the scp1000, bmp085 and bmp085 so far (~6.5ms for all 3). So we are talking about 50 time/sec for sensor updates.
So I can see all sensor reading in 1 cog, rc receiver reading in 1 cog, esc output 1 cog, imu 1 cog, main loop (rc -> imu, imu -> esc) in 1 cog. So thats 5 Cogs. If the rc receiver outputs ppm I might be able to read that on the main cog since I use counters for ppm input, taking it to 4 Cogs.
Post Edited (Timmoore) : 5/19/2010 5:20:56 PM GMT
Your update speed indicates that on landing, the BMP085 is faster and hence will be better even tho' the range is less. If we really want proper ground detection the parallax ultrasonic sensor could be plugged into a spare RX channel to do this.
I am actually not concerned about having enough cogs as I can always redo anything in pasm if stuck. The prop will outperform the Atmega32 which is being used by the quad group (sorry, forget their website at present).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I also noticed they dont use a kalman filter in their imu, they use a much simpler filter and they have exceptions built in for some cases my and other imu code dont handle e.g. ignoring effect of acceleration on accelerators, banking effects, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I guess I have been bitten, I have mostly finished building a quad, the frames done, the motors/escs are running, some of the sensors are working, the receivers next.
http://www.engadget.com/2010/05/28/autonomous-quadrocopter-flies-through-windows-straight-into-our/
I wonder what kind of horsepower, (CPU), they are using. Also, is a canned, (programmed), move, or do they do it with sensors?
Jim
Edit: Nevermind. Not that impressive. I just caught the audio and they are using a 20 camera system for navagation/feedback? . How would that work in the real world?
Post Edited (hover1) : 5/28/2010 10:10:08 PM GMT
Since I decided to put a quad together, I have been modifying that code I use on my bots to the quad. Its only got pieces tested and it hasn't flown but it supports
4/6/8 motor configurations with + and x (only 4+ test so far)
receiver RC servo and PPM input (only PPM tested)
GPS NMEA (object tested but not tested as part of system)
sensors ITG3200, bmp085, adxl345, hmc5843 (object tested but not tested as part of system)
IMU (object tested with other sensors)
Stablization (not tested and not working)
pan/tilt for camera (object tested but not tested as part of system)
video overlay for wireless camera (overlay system from prop backpack - based on backpak object)
Some of the system config - rc channel usage, gps type, motor config is held in eeprom config and can be changed from debug port (partly tested)
I am sure its got lots of bugs but I can post it so far if it might help someone get going, or I can wait until I have more working and tested.
Since it doesn't have stablization working I dont recommend trying to fly with it but it might be helpful for testing
The other question is what other support is needed, the obvious one after stablization is gps waypoint flying but anything else? I have part support for battery monitoring and ping but they are not connected to anything.
PS I attached a picture of my quad so far.
Post Edited (Timmoore) : 6/2/2010 4:27:16 AM GMT
I have not done any software yet but there are a few including Jason and Cessnapilot·that have some prop software running. My plan was to try the stabilisation while having the copter tethered by short string so the copter could not crash.
Cessnapilot has done some software http://forums.parallax.com/showthread.php?p=909093
I have been on a course for the past week so I haven't done anything including reading the forum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Motor: http://www.hobbycity.com/hobbyking/store/uh_viewitem.asp?idproduct=2049
ESC: http://www.hobbycity.com/hobbyking/store/uh_viewitem.asp?idproduct=4218
The frame is different, I used the 10mm x 10mm tubes from hobbyking but I used http://hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=5136·with the side cut from the square mount·so they would mount on the end of the square tubes and glued them on. It meant I didn't have to drill the carbon fiber to mount the motors.
The motors are fairly small but the quad weighs 800gr complete including battery so it should be ok. I have both the GWS 8040 3 blade prop and the EPP8045 2 blade prop so I will see which is better.
I will be tethering it down this weekend and working on stablization.
I looked at Cessnapilot IMU but I am going to try mine first.
How stable/flexible are the carbon fibre arms? I presume they are the ones with a round hole through the center.
What LiPo are you using? 1500kV seems a bit high for 3S so I am presuimg it is a 2S.
Cunning method of mounting. My motor came with that mounting bracket so I could put it to good use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Yes the arms are the ones with the round hole, they seem ok, they are 8" long from center, so the motors are ~9" from center with the mounts, so with the current props they could be a bit shorter. I did it as 1 length 16" and 2 pieces 7.8". They take a bit to bend them but dont squash them they split lengthways fairly easily.
I am using 3S so yes the motors may be a bit fast. Some of the comments I have seen about the motors say they ran with 8" props with 3S and got ~300gr thrust so in theory I have 400gr of lift but I will find out soon.
I did see somewhere where they glued a rod inside the hole to add to the strength of the 10x10mm cf arms.
I am unsure whether there is any interest in making a pcb for the mounting arms. We could just drill a cf plate(s) as you have done. Anyone ???
I am trying to make my pcb and sensors fit into a hammond box for protection. Of course, what I want on the pcb does not quite fit of course and I am trying various ways to solve this problem.
Do you have the GPS working (reading values into the prop)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
1. ESC/ITG3200/ADXL345/HMC5843/BMP085
2. PPM RC receiver
3. servo style RC receiver - dont have a way to test this since I use PPM input
4. GPS
1,2,4 are currently working.
I have the full program with them all integrated, with the IMU off the RC receiver controls the ESCs. The IMU is running but I haven't had a chance to check its output nor is it using the IMU to stablize the quad. The GPS is being read into the prop but isn't doing anything with the data apart from being parsed and translated into numbers. Checking the IMU and using it to stablize the quad is the next stage.
What I intended to do was to use the PC via the propplug to give comands to the prop while trying the tethering. Obviously you will need to see how much power is required to get the motors to lift the copter. Then you can use the gyro/accelerometer to stabilise the copter. Next you can use the compass for heading. Lastly will come the pressure as for now the craft is tethered so you will not see any altitude variations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Then I have 4 pids one each for pitch/roll/yaw/alititude, the RC input sets the pids setpoint using the 2 joysticks, the IMU/pressure sensor outputs are the pids actual values and the pids output controls the motors through a mapping function that maps pitch/roll/yaw/altitude to motor speeds. The mapping function changes depending on how many motors and + or x config but the IMU/PIDs shouldn't change except perhaps the PID constants.
If all RC receiver inputs are 0, i.e. center the 2 joysticks, then the quad hovers in one position.
This means the IMU/stablization can first be tested by printing the motor values, not setting the motors, and move the quad and see how the motor IMU and motor values changes for different RC inputs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I'm going to be hooking up a digital (I2C or SPI) accelerometer in the moderately near future, at which point I'll probably fold the ITG-3200 and digital accel into a single PASM object for speed and compactness. I'll post that too if I do it and you folks aren't there yet.
Tim's description of his flight model is exactly what I'm doing too - The PID is the "controller", and the RC inputs just place the set points for the PIDs. You'll need different gain settings for the rudder and the altitude, since they respond at different rates than the pitch and roll. I expect altitude control to be a VERY slow loop. If I understand right, altimeter readings are fairly inaccurate, so you'll probably want to do a short moving average of them, meaning the control will be somewhat soft.
You'll probably want to have some "feed forward" of the throttle (direct control), as sudden throttle changes should override the desire to hold an altitude, while a "steady" throttle position should maintain the current rate of change. If the current rate is close to zero, the user probably "intends" zero. It's all so picky.
Jason
I use Brad's BST to build so I can ifdef drivers in/out depending on whats required. So it shouldn't be difficult to allow #defines for the various sensors and other features and for each of us to build the right version.
For motor/frame config I have that stored in eeprom and over the debug port can change the config/pid constants etc. and then save in eeprom rather than rebuilding each time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
You can see a little vibration on the arms at about takeoff but I dont know how that translates to the IMU yet, nor have I tried balancing the props to see if that helps.
Also if you are using either 248 or 648 GPS then you might want to look at this thread http://forums.parallax.com/forums/default.aspx?f=36&m=459099 about configuring them to disable the filters they have.
I may just have to copy that code across, now that I think about it... It was handy. I don't like flying the thing next to my PC. [noparse]:)[/noparse]
Jason