Jason, Are you having any vibration problems with the itg-3200 gyros?
I am getting problems with the gyros. The accelerometer and compass are showing minor/no impact but the gyro is affected badly, see the attached chart, its a plot of the gyro/acc/compass outputs for each axis as I start up one of the motors. All the motors have similar effects.
I am going to be trying to isolate the gyros more from the frame but I was wondering if you have seen similar problems.
I haven't looked at the data much. The 3200 does have a bunch of settings to control the internal filter, sampling rate, and digital filter. It would probably be worth playing with those a bunch to see how that affects the results.
My previous iteration on this thing, using a different gyro, was pretty sensitive to motor noise. Isolating the gyro physically helped a lot. I expect similar problems with this one, but I couldn't say for sure at this point.
My results were comparable - I played with it a bit this evening, and turning up the internal LPF certainly seemed to improve the stability. The low-pass shouldn't really affect responsiveness by a whole lot. It'll be very rare for anything to affect the thing THAT quickly. I set the internal filter to 98Hz, the digital filter to 0 (1x). I meant (but forgot) to set the oscillator to the MEMS X gyro, too. Doubt that'll help much, but who knows.
With the above settings I was able to hover in my kitchen (pretty tight space) for 30 seconds with no problem.
I ended up with the filter at 98Hz as well, but with 4x sample and the osc to X as well, this filtered the noise out and I found that using more filtering meant I had to change the IMU coefficents - the IMU wouldnt converge with higher levels of filtering.
Even without the digital sample enabled mine was quite stable. With it turned on it seemed slightly better, but it was hard to tell for sure. I want to add a data logger so I can just fly the thing and then view the inputs, gyro values, PID values, and outputs on a graph. So much coding still to do, but alas, day job. [noparse]:)[/noparse]
I send the sensors, pids, etc to a PC where it logged and used to display a cross for the quad, a the right orientation with arrows for the motor speeds. It makes it much easier to understand whats going on. The app also allows me to change the pid settings, sensor orientation, rc channels, etc.
That's pretty cool It'd be overkill for me at this point - so far the only sensor I have is the gyro. [noparse]:)[/noparse]
I just bought a $200 netbook, which I plan to use for, among other things, "field programming", so that'll make it a little better. I'm also seriously thinking of getting a couple XBee modules, so I can transmit real time data instead of logging, or being tethered.
It's quite stable now - I set the digital filter to 5x (200hz) which matches my internal update rate, and set the clock to the X-axis osc. Even in a decent wind it was pretty solid. I need to monkey with my PIDs now (they're just P so far) and see how much more solid I can get it before adding the next sensor, which is a digital accelerometer. Once I do that, I'm probably going to re-write the ITG-3200 module I have to be PASM, and read both the gyro and accel in one cog.
I also have to build a better frame for the thing. I'm using round tubes for the arms, which means my props aren't necessarily perfectly level, which affects everything. I have some square carbon on the way, which should be a marked improvement.
@Timmore I really like your interface, that makes debugging pretty easy.
@JasonDorie I just got a couple of the Xbee pros yesterday, and in 10 min I had a Parallax GPS sending me NMEA data to a terminal from across the house. Pretty awesome and easy to use!
@Adam, I thought it was probably an overkill when I did it but it looked interesting to do it but now I have done it, it keeps finding bugs, it makes it pretty obvious when you have a problem - the picture rotates to an unexpect position and often goes wild. Its spotted problems in my IMU code that I haven't noticed before. Makes axis mismatches very obvious, etc., vibration problems.
It doesn't help debug them, just makes it really obvious you have a problem, you still need to go through the logs to try and see whats the cause and often the logs I have are not enough. e.g. I have a problem curenttly that sometimes the IMU output jumps for a very short time and then goes back to the expected value. Its very obvious when it happens and looking through the logs I can also see it but I never noticed it in the logs with the amount of over stuff in it but I can't see why its happening even from the log files - the logs have all the sensor readings, the inputs into the kalman filters and the outputs but I can't see why from those
It uses a few serial commands
Dump the internal variables you can config
Updates an internal variable
Dumps sensor/imu/motor state
Save config to eprom, Load config from eeprom, reboot
The picture is drawn from the sensor/imu/motor output
The config variables allow me to enable/disable the IMU or motors, change hte pid values, change sensor axis, etc.. e.g. I can do a lot of testing by enabling the IMU, disabling the motors, then use the RC receiver to "turn on the motors" and then pick up and move the quad and see what the response is. e.g. put the quad into "hover", pick the quad over and change the motors change to stablize the quad, the final PID tuning still needs to done on the real system but its good for getting a lot of quicks out of the system.
I've got mine pretty stable now - Still want to play with the PIDs once I get the new body on it, but I had the thing 30 feet off the ground on the weekend without issues, and still just using the ITG-3200 with straight proportional response. I'll try to get some video of it this week.
Tim: Here's the pin definitions (some may move during final layout, but you will get the idea)
P0-7:···· RC Receiver input
P8-11:·· microSD (optional plugin pcb)
P12-13: GPS (optional external module)
P14-15: Ping sensor (uses 1 pin only, other spare)
P16-23: ESC/Servos output
P24-25: I2C #1 \\ for gyro/accel/compass/pressure-temp chips
P26-27: I2C #2 //
P28-29: EEPROM (can be extended for external I2C)
P30-31: PropPlug (could also be used for something else)
Of course, any unused Receiver or EC/Servo pins can be used elsewhere. Note also, the Receiver & ESC/Servos could be interchanged, or even mixed. After all, it's only software (maybe different series resistors, but they could be the same I think)
You will note I have only defined 2 I2C interfaces for the sensors. I hope to be able to jumper each sensor to·one of the 2 I2C interfaces. This may allow us to get faster info from the sensors by placing them on different I2C buses. Might even put the pressure/temp sensors on the EEPROM I2C yet.
Perhaps someone who has the code running may care to comment on the mix of gyro/accel/compass split on 1 or 2 I2C and how they should be split?
PS. I have had a real dilema in trying to fit the parts on a small pcb that would fit into a standard box to protect the unit. I have finally found/chosen one that fits the requirements. However, the microSD will need to be a daughter pcb if required.
I was·very interested with the links that Richard gave. Using WiFi or ZigBee instead of an RC unit could be nice, although I already have my DX6i. I was hoping to fly my quad in a similar fashion to the way they use the iPhone (of course using sticks). I have the US mode (whichever that is although I am in Oz) because I wanted elevation/throttle on 1 stick and pitch and yaw roll on the other. So I want my code to be a bit different to the usual flyers. BTW it is silly there isn't an internal spring/ratchet adjustment and software to change·from mode 1 to 2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I am running the ESCs without resistors without problem and I am updating them at 200Hz.
I have the sensors all together on a 2nd I2C bus (not the eeprom connections) though I use the 2nd 32K of the eeprom for config and plan to store waypoints there as well.
I will check my log files for how long it takes to read the sensors, I do it all in spin and last time I looked it was around 20ms. Doing it in assembler would be much faster but would take another cog - though I have 2 spare. All the sensors can run at 400Khz and only the bmp085 can go faster, at a rough calculation probably can read them all in a few ms but reading the sensors at more than ~50Hz isn't probably worth it, I set the filters on the gyro to 98Hz, the hmc5843 and adxl345 to 50Hz. So I would have said 1 I2c, we can write a pasm driver to read the sensors well above 50/sec if we need.
Another thing to think about is some leds for status, it is very useful knowing when the gps is locked, when the IMU is iniitialized and ready to do, etc. I ended up added a I2C blinkm led which gives me 3 leds without needing more pins and the leds give status of the gps, imu and whether altitude hold is on/off. I have it mounted on the front leg so I also get an indication of where is the front.
I have my tx setup with left as throttle/yaw and right as pitch and roll. i.e. right joystick moves the quad forward/back and sizeways, the left does altitude and rotation but you can change the channel mapping from the PC config app.
Tim: Sorry, I meant pitch & roll on right stick and throttle (which really acts as elevation) on the left stick. I don't believe yaw is required??? If it is, what does it do & how???
I had not thought about LEDs but these could be connected to the unused servo pins without the need for another IC and the pcb has provision for a series resistor. The footprint is SMT pads for 0805/1206 and has holes in the centres for a thruhole resistor (vertical 0.1" spacing).
So maybe the 2 x I2Cs I run are 1 seperate and the other combined with the EEPROM ? That then gives me a spare 2 pins for something else. I don't have much room on the pcb. The 2 sets of 3x8 pins takes up a lot of pcb space but I prefer this to requiring the RC Receiver to be modified to output a combined 1 pin stream like some other interfaces.
Do you log the sensor readings to EEPROM? Would a 128KB EEPROM be better? If so, then it would be better for the EEPROM to be on it's own I2C. I had thought to use a microSD card for data logging and the decision results (ESC drive). With a WiFi or ZigBee interface we could transmit to the ground and a PC could display graphs dynamically. I saw this on one of the other forums - looked fantastic!
Of course, an iPad controlled 'copter would be even better
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yaw is rotation around the center of the quad. Since 2 motors are speeding CW and 2 CCW if you slow the CCW pair down and speed up the CW pair you will rotate CW. Only really use I can think of is if you add a camera. Since you have directional control of the Quad you dont have to add it to the camera mount.
The sensors values are logged on a PC, I currently do it over the debug port for debugging but I want to add Xbee or bluetooth (probably bluetooth since its smaller except its also on 2.4GHz the same as the RC receiver I have) so I can do it in the air. I can reconfig the system but also get the sensor values, IMU inputs and outputs, motor values, etc.
I can disable the motor from running but monitor on the PC what the quad would do with various RC receiver inputs and positions of the quad, i.e. enable IMU control, set the RC receiver to hover, then pick and manuver the quad and make sure the IMU is trying to set the quad back to hover.
What is in the eeprom are GPS waypoints and configuration variables - no of motors, sensor axis, pid values, etc.
There is a #define for PPM or separate RC receiver inputs, a #define for SCP1000 or BMP085 and a few others to enable things like camera, telemetry, etc.
After that config is via variables, the prop pins and I2c addresses are in tables but not configurable from the PC, the motors/RC channels, etc are configurable from the PC.
Tim: To move the 'copter forward, don't you keep the side motors at the same speed, decrease the forward motor and increase the rear motor. This would mean that the craft should not rotate (yaw)??? as we still have ultimate cw = ccw ???
BTW Bluetooth, WiFi, Xbee (and my RC) all use the 2.4GHz band. I am unsure how they don't (or do??) interfere with one another.
I have a ZipIt2 which has WiFi and a *nix OS and cost $50. I am sure this could log data and display on its small lcd screen if WiFi was used to transmit the data. Initially I think it may just be easier to log to a microSD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes to move forward, leave sides the same and decrease in the direction you want so the torque cancels, similar for sideways. but for yaw you make sure you dont cancel the torques out, then the quad will spin.
Wifi sits on a piece of the 2.4GHz, depending on what you config on the access point. Bluetooth hops around all the band, when it lands on the wifi piece it interfers unless the bluetooth has 802.11 collision detection (basically it checks and modifies its hopping pattern to avoid the 802.11).
My RC (its a flysky) checks on start up and moves if there is interference but doesn't move after that. I expect bluetooth will interfer whenever it lands on top of the RC frequency but 802.11 will probably be ok as long as 802.11 is up and working before turning on the RC receiver.
Some of the more expensive 2.4 RC receivers hop or use DSSS so they may cause problems with 802.11.
XBee or 802.15.4 was designed to work with bluetooth but i dont remember about 802.11. The 1mw version is probably ok the 63ms probably will cause interference.
Everything will really depend on how close the antennas are on the quad, close will cause problems. I may end up having to move the RC receivers out to the end of the arms and put the telemetry tx/rx on the end of another arm.
New here. Great project! Great thread! Lots of talent here! I've wanted to build one of these for a while but it will have to wait for a few home renovation projects to be completed.
I've only read the first half of the thread so far but wanted to post this suggestion. Has anyone considered DGPS yet? I would love to have precise navigation, stable/repeatable waypoints for video/photos, and an automatic 'return to pad' feature.
Most/all of the modern GPS recevers support WAAS (or the european/japanese versions). This gives you the equivalent of DGPS without the extra receiver.
Welcome Don. DGPS is dying. IIRC EGNOS is used in Australia and surrounds. Anyway, nowadays, GPS is mainly accurate to within a few meters, so your copter should be fine. If in doubt, start at a known point with respect to the other defined points and have the craft do an adjustment for the error between the known starting point and what it is reading for the starting point.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Timmoore said...
Most/all of the modern GPS recevers support WAAS (or the european/japanese versions). This gives you the equivalent of DGPS without the extra receiver.
Unless you have no WAAS visibility (Welcome to Western Australia)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
This is still done with just a single ITG-3200 gyro and simple proportional response to the gyro readings. I balanced the propeller blades so they don't vibrate any more (that's what the red tape is for). I still haven't physically isolated the gyro, but it's pretty stable as is.
I also graphed the outputs of the ITG-3200 at rest, but with varying temperatures (hair dryer) in the hope that I could figure out a correlation between the zero point and the temperature to compensate for drift. Check out the attached image - it's a straight line on all 3 axis, which is good news.
Jason
Post Edited (JasonDorie) : 6/30/2010 5:31:03 PM GMT
Comments
I am getting problems with the gyros. The accelerometer and compass are showing minor/no impact but the gyro is affected badly, see the attached chart, its a plot of the gyro/acc/compass outputs for each axis as I start up one of the motors. All the motors have similar effects.
I am going to be trying to isolate the gyros more from the frame but I was wondering if you have seen similar problems.
My previous iteration on this thing, using a different gyro, was pretty sensitive to motor noise. Isolating the gyro physically helped a lot. I expect similar problems with this one, but I couldn't say for sure at this point.
reg 15 set to $07 and 16 to $18.
The attached chart is with reg 15 set to $1F and 16 to $1C - the filtering is turned fairly high.
Neither of the charts is with any post filtering - straight from the sensors. The accelerometers have more noise than the gyro's in the latest plot.
Now to find if it reacts fast enough.
With the above settings I was able to hover in my kitchen (pretty tight space) for 30 seconds with no problem.
Jason
I just bought a $200 netbook, which I plan to use for, among other things, "field programming", so that'll make it a little better. I'm also seriously thinking of getting a couple XBee modules, so I can transmit real time data instead of logging, or being tethered.
It's quite stable now - I set the digital filter to 5x (200hz) which matches my internal update rate, and set the clock to the X-axis osc. Even in a decent wind it was pretty solid. I need to monkey with my PIDs now (they're just P so far) and see how much more solid I can get it before adding the next sensor, which is a digital accelerometer. Once I do that, I'm probably going to re-write the ITG-3200 module I have to be PASM, and read both the gyro and accel in one cog.
I also have to build a better frame for the thing. I'm using round tubes for the arms, which means my props aren't necessarily perfectly level, which affects everything. I have some square carbon on the way, which should be a marked improvement.
@JasonDorie I just got a couple of the Xbee pros yesterday, and in 10 min I had a Parallax GPS sending me NMEA data to a terminal from across the house. Pretty awesome and easy to use!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My website www.quigleyelectronics.com/
It doesn't help debug them, just makes it really obvious you have a problem, you still need to go through the logs to try and see whats the cause and often the logs I have are not enough. e.g. I have a problem curenttly that sometimes the IMU output jumps for a very short time and then goes back to the expected value. Its very obvious when it happens and looking through the logs I can also see it but I never noticed it in the logs with the amount of over stuff in it but I can't see why its happening even from the log files - the logs have all the sensor readings, the inputs into the kalman filters and the outputs but I can't see why from those
It uses a few serial commands
Dump the internal variables you can config
Updates an internal variable
Dumps sensor/imu/motor state
Save config to eprom, Load config from eeprom, reboot
The picture is drawn from the sensor/imu/motor output
The config variables allow me to enable/disable the IMU or motors, change hte pid values, change sensor axis, etc.. e.g. I can do a lot of testing by enabling the IMU, disabling the motors, then use the RC receiver to "turn on the motors" and then pick up and move the quad and see what the response is. e.g. put the quad into "hover", pick the quad over and change the motors change to stablize the quad, the final PID tuning still needs to done on the real system but its good for getting a lot of quicks out of the system.
Jason
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
http://www.geek.com/articles/gadgets/parrot-ar-iphone-drone-20100616/
http://ardrone.parrot.com/parrot-ar-drone/en
http://ardrone.parrot.com/parrot-ar-drone/dev/developers
iPhone or iPad Touch controlled...approx. $300.00
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Grants Pass, Oregon
The ultrasonic sensors look just like the Parallax ones used on robots which is a simple 1pin interface. And 2 cameras too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Does anyone interested have any comments?
After seeing Richard's link on the Parrot, I have wondered if a WiFi module or ZigBee module could be used in place of the Receiver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Are there any spare prop pins, connecting them to 0.1 header connections would be useful - allow things like xbee or bluetooth for telemetry.
Of course, any unused Receiver or EC/Servo pins can be used elsewhere. Note also, the Receiver & ESC/Servos could be interchanged, or even mixed. After all, it's only software (maybe different series resistors, but they could be the same I think)
You will note I have only defined 2 I2C interfaces for the sensors. I hope to be able to jumper each sensor to·one of the 2 I2C interfaces. This may allow us to get faster info from the sensors by placing them on different I2C buses. Might even put the pressure/temp sensors on the EEPROM I2C yet.
Perhaps someone who has the code running may care to comment on the mix of gyro/accel/compass split on 1 or 2 I2C and how they should be split?
PS. I have had a real dilema in trying to fit the parts on a small pcb that would fit into a standard box to protect the unit. I have finally found/chosen one that fits the requirements. However, the microSD will need to be a daughter pcb if required.
I was·very interested with the links that Richard gave. Using WiFi or ZigBee instead of an RC unit could be nice, although I already have my DX6i. I was hoping to fly my quad in a similar fashion to the way they use the iPhone (of course using sticks). I have the US mode (whichever that is although I am in Oz) because I wanted elevation/throttle on 1 stick and pitch and yaw roll on the other. So I want my code to be a bit different to the usual flyers. BTW it is silly there isn't an internal spring/ratchet adjustment and software to change·from mode 1 to 2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 6/19/2010 3:20:00 PM GMT
I have the sensors all together on a 2nd I2C bus (not the eeprom connections) though I use the 2nd 32K of the eeprom for config and plan to store waypoints there as well.
I will check my log files for how long it takes to read the sensors, I do it all in spin and last time I looked it was around 20ms. Doing it in assembler would be much faster but would take another cog - though I have 2 spare. All the sensors can run at 400Khz and only the bmp085 can go faster, at a rough calculation probably can read them all in a few ms but reading the sensors at more than ~50Hz isn't probably worth it, I set the filters on the gyro to 98Hz, the hmc5843 and adxl345 to 50Hz. So I would have said 1 I2c, we can write a pasm driver to read the sensors well above 50/sec if we need.
Another thing to think about is some leds for status, it is very useful knowing when the gps is locked, when the IMU is iniitialized and ready to do, etc. I ended up added a I2C blinkm led which gives me 3 leds without needing more pins and the leds give status of the gps, imu and whether altitude hold is on/off. I have it mounted on the front leg so I also get an indication of where is the front.
I have my tx setup with left as throttle/yaw and right as pitch and roll. i.e. right joystick moves the quad forward/back and sizeways, the left does altitude and rotation but you can change the channel mapping from the PC config app.
I had not thought about LEDs but these could be connected to the unused servo pins without the need for another IC and the pcb has provision for a series resistor. The footprint is SMT pads for 0805/1206 and has holes in the centres for a thruhole resistor (vertical 0.1" spacing).
So maybe the 2 x I2Cs I run are 1 seperate and the other combined with the EEPROM ? That then gives me a spare 2 pins for something else. I don't have much room on the pcb. The 2 sets of 3x8 pins takes up a lot of pcb space but I prefer this to requiring the RC Receiver to be modified to output a combined 1 pin stream like some other interfaces.
Do you log the sensor readings to EEPROM? Would a 128KB EEPROM be better? If so, then it would be better for the EEPROM to be on it's own I2C. I had thought to use a microSD card for data logging and the decision results (ESC drive). With a WiFi or ZigBee interface we could transmit to the ground and a PC could display graphs dynamically. I saw this on one of the other forums - looked fantastic!
Of course, an iPad controlled 'copter would be even better
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The sensors values are logged on a PC, I currently do it over the debug port for debugging but I want to add Xbee or bluetooth (probably bluetooth since its smaller except its also on 2.4GHz the same as the RC receiver I have) so I can do it in the air. I can reconfig the system but also get the sensor values, IMU inputs and outputs, motor values, etc.
I can disable the motor from running but monitor on the PC what the quad would do with various RC receiver inputs and positions of the quad, i.e. enable IMU control, set the RC receiver to hover, then pick and manuver the quad and make sure the IMU is trying to set the quad back to hover.
What is in the eeprom are GPS waypoints and configuration variables - no of motors, sensor axis, pid values, etc.
There is a #define for PPM or separate RC receiver inputs, a #define for SCP1000 or BMP085 and a few others to enable things like camera, telemetry, etc.
After that config is via variables, the prop pins and I2c addresses are in tables but not configurable from the PC, the motors/RC channels, etc are configurable from the PC.
BTW Bluetooth, WiFi, Xbee (and my RC) all use the 2.4GHz band. I am unsure how they don't (or do??) interfere with one another.
I have a ZipIt2 which has WiFi and a *nix OS and cost $50. I am sure this could log data and display on its small lcd screen if WiFi was used to transmit the data. Initially I think it may just be easier to log to a microSD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Wifi sits on a piece of the 2.4GHz, depending on what you config on the access point. Bluetooth hops around all the band, when it lands on the wifi piece it interfers unless the bluetooth has 802.11 collision detection (basically it checks and modifies its hopping pattern to avoid the 802.11).
My RC (its a flysky) checks on start up and moves if there is interference but doesn't move after that. I expect bluetooth will interfer whenever it lands on top of the RC frequency but 802.11 will probably be ok as long as 802.11 is up and working before turning on the RC receiver.
Some of the more expensive 2.4 RC receivers hop or use DSSS so they may cause problems with 802.11.
XBee or 802.15.4 was designed to work with bluetooth but i dont remember about 802.11. The 1mw version is probably ok the 63ms probably will cause interference.
Everything will really depend on how close the antennas are on the quad, close will cause problems. I may end up having to move the RC receivers out to the end of the arms and put the telemetry tx/rx on the end of another arm.
New here. Great project! Great thread! Lots of talent here! I've wanted to build one of these for a while but it will have to wait for a few home renovation projects to be completed.
I've only read the first half of the thread so far but wanted to post this suggestion. Has anyone considered DGPS yet? I would love to have precise navigation, stable/repeatable waypoints for video/photos, and an automatic 'return to pad' feature.
Thanks.
-Don
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Unless you have no WAAS visibility (Welcome to Western Australia)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
www.youtube.com/watch?v=k4TMhVGZvJc
This is still done with just a single ITG-3200 gyro and simple proportional response to the gyro readings. I balanced the propeller blades so they don't vibrate any more (that's what the red tape is for). I still haven't physically isolated the gyro, but it's pretty stable as is.
I also graphed the outputs of the ITG-3200 at rest, but with varying temperatures (hair dryer) in the hope that I could figure out a correlation between the zero point and the temperature to compensate for drift. Check out the attached image - it's a straight line on all 3 axis, which is good news.
Jason
Post Edited (JasonDorie) : 6/30/2010 5:31:03 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Looks like a brilliant machine. Thanks for the great video, very encouraging.
Please don't "spurn" this development. [noparse]:)[/noparse]
Spurn:
1. To reject disdainfully or contemptuously; scorn. See Synonyms at refuse1.
2. To kick at or tread on disdainfully.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
And yes Cluso, I've been flying r/c helis for a few years. I'm out of practice, but it comes back pretty quick.
Jason