Dave - The DCM code is a lot easier to follow, oddly enough. It's also a "whole problem" solution, as opposed to solving a single axis at a time, which is what the Prop based Kalman solutions I've seen do. All the Kalman stuff I've seen is really "academically dense", whereas the DCM stuff I found relatively intuitive.
DCM is also a bit of a misnomer - The Discrete Cosine Matrix is just a fancy name for a rotation matrix. The code uses a DCM to represent orientation, and uses a complimentary (or fusion) filter to adjust that matrix given inputs from a gyro, accelerometer, and optionally a compass.
In simple terms, a DCM is a frame of reference - it contains 3 vectors which represent the X, Y, and Z axis of an object oriented in space. You can rotate the matrix by using relatively simple math. If the rotations are small (incremental), then you can short-circuit some of the math because of the way the terms play out. Sin & Cos of a very small angle value end up being close enough to (value) and (1 - value) that you can just use those instead of bothering to compute Sin & Cos.
A small amount of error is introduced, but that gets fixed constantly by making sure that all the vectors in the matrix are all tangent to each other, and have a length of 1.0 (this is called and orthonormal matrix, IE it is orthogonal, and normalized)
After rotating it with the gyro values, you take the current accelerometer value and compare it to the "down" vector of your matrix. The difference between them is an estimate of how far off you are, but it's noisy. So you scale it down, and use that result as an amount to "nudge" the matrix on the next rotation pass. You do the same thing with the compass reading if you have one, comparing it to "forward".
Until a few days ago I didn't even know what DCM stood for. Now my head is really "spinning" with rotation matrixs. The computer display of the box representing the IMU seems very stable.
Thank you very much for explanation about Arctan values. I have asked these values to implement complementery filter without floating point math.
my older code was a complementery filter using floating point math (f32 object)
And Yes I want something self leveling
It would be great If you share DCM based flight code.
I know DCM is better than kalman / complementery filter etc. Did you add a magnetometer to DCM solution ? or planning ?
I haven't added the magnetometer to the code yet, but I do have one and I am planning to add it once I get my new frame built up. I have two different boards - one using the ITG/ADXL, and the other using the MinIMU-9 from Pololu, and both of them are working with the DCM code. The MinIMU-9 has a magnetometer, and I already have the driver reading the values from it, I just have to figure out how to interpret them properly.
Unfortunately we had a lot of Xmas and New Year visitors and I didnt get to actually fly my quad. I did go outside to perform a test and found that I had the axes mixed so I brought it inside to do some more work to ensure that when an arm of the quad dips, the software increases that motor.
Jason has really helped in simplifying my understanding of how it all works together. While I gathered what had to be done, I had no idea of how to apply the feedback.
Hello,
I am a little new to the propeller. I started in it a few years ago but got sidetracked. I have built a board with 2 props, a DS1307, USB and other chips on it for eventually driving a BA-609 model. I have a 9DOF from Sparkfun attached as well as an FPU from Micromega. I also have inputs for SRF05 Sonic. I have allowed 10 inputs form an RC receiver on the first prop and 24 servos on the second prop. The board also has an micro SD card and an MCP3208 A/D as well as an MAX7456 OSD chip. The board checks out ok for all the individual inputs but now I have to put them all together and try and make something fly. I am trying to use SerialMirror for communication between props but am not sure how to use it. I need to send the servo data from prop1 to prop2 and GPS/FPU from prop2 to prop1. I just don't know how to mix the ADXL345 and IGT3200 outputs to the servo data.
The BA-609 is much like the quad except with only 2 motors. I may not have enough cogs to do what I want. Any suggestions would be appreciated.
I also have some extra boards if someone wants them. They are 3" x 4".
I'm guessing you're the same Shanghai Fool that was hanging out on RCGroups a few years ago? It's been a while.
If 16 cogs isn't enough to do what you want, you must want something pretty impressive. What do you need 24 outputs and 10 inputs for? How many degrees of articulation are there on the motors themselves? (I'm guessing throttle, and rotate, but it could also be toe-in & pitch).
You could probably start with my code for the flight mixing basics, but the current published one just uses the gyro - no accelerometer. I have another version coming that does full IMU frame-of-reference calcs using the gyro and accelerometer, but I haven't released it yet.
Thanks for the fast reply. Yes, I am the same Shanghai_fool. I had a bout with the big C and had to go back to the US for a while. As far as the cogs are concerned, I have Main loop, ADC, Kalman, Receiver,OSD, IMU and SerialMirror on the first prop and Mian loop, SerialMirror,servo32, Fpu/GPS, and possibly RPM x2 on the second.
As far as channels are concerned, I have not yet decided on whether I can fixed pitch props or may need 3 servo + ESC on each motor in addition to 5 servos for gear/doors and possibly other things such as steering and elevator. So far, I count 17 possible servos + 2 ESC.
If I can use fixed pitch props, the I only need individual minor tilt on the engines + full 90° tilt as well as flaps.
I did look at the DCM and finally got it to work by getting one of the boards to use Com8. It works very well. I haven't looked at the flight code yet but will tonight.
OK, I tried the flight code and got nothing. I changed Gyro.start(10,11) in Line 95 and changed all ESC's to pins 6,7,8,9. Receiver inputs are still on 0-6. I did not get any pulses on any of the output pins.
I tried various serial devices (Prop Terminal,Parallax Serial Terminal, Hyperterminal) and only got special characters (7F) so I'm not sure what was being output.
The ESC code as published can only output to servos in the range of 8 to 15. I'll send you a version for bank zero (0-7), but if you're using mostly standard servos you'd be better off just using the standard servo object. Mine, if not configured correctly, will fry them because of the high output rate. And for the debug, I use a custom GroundStation app that does live graphing and configuration. It's in the same post / thread.
Hi Jason, Yes, I saw that after I sent the last reply. I then went back to the Prop Proto board and was able to use the servos as intended and everything worked. I cannot use the GS software as it uses Com5 and that com port is taken up already on my system. Maybe I'll breakdown and get Visual C. I wasn't actually connecting servos, just using scope until I get everything working. I now have the outputs connected to ESC's with 2 motors and will build up a demo with that later today. I will watch super bowl at 7:30AM first. If the wing leveling works, that will be half of the system.
I got the demo done but it doesn't seem to do anything to level the strip.
I tried sending 0xAA +0xA5, 0xAB, 0xAC to the unit. I also changedGyroOrientation to 0 and FrameConfiguration to 0 in the DAT section.
I think I really need the ground station software to look at what is happenning but I just don't want to spend $600 on VS. I just don't use it that much. I have VB 6.0 that I use infrequently. I had to use that to make some special characters for the MAX7456.
You can download Visual C# Express for free. If you tell me which com port you use I can make you a custom one. My flight code doesn't auto-level yet, but it will auto-stabilize.
It is completely free. You have to register it after a bit, but it's still free, and they haven't been spamming me or anything. To elaborate on the flight code a little, it's essentially a 3-axis heading hold gyro. It will resist orientation changes from outside forces, and will even remember where it was and try to go back there, but it has no idea where down is. That's what I mean when I say auto-stabilizing but not auto-leveling.
Depending on the gyro board you're using, you may need to change the device ID for the gyro in the ITG-3200-pasm.spin file. Mine is using the Sparkfun breakout board for that gyro, and they set the ID to $69 instead of the normal $68. Because of the way I2C works, I pre-shift the numbers up by one, so my gyro ID value is stored as $D2 ($69 << 1). Yours might need to be $D0 ($68<<1) for it to read properly.
By default, on startup it sends out gyro packets which are 0x7F, 0x7F, followed by GyroX, Y, and Z, two bytes each. (I can't remember if they're high or low). It'd be a simple thing to change that output code to spit out hex or decimal versions of those values instead, like this:
'Print in hex, 4 digits each
dbg.hex( gx, 4 )
dbg.tx( 32 ) 'print a space
dbg.hex( gy, 4 )
dbg.tx( 32 ) 'print a space
dbg.hex( gz, 4 )
dbg.tx( 13 ) 'next line
'OR
'Print in decimal - MIGHT overflow the transmit buffer
dbg.dec( gx )
dbg.tx( 32 ) 'print a space
dbg.dec( gy )
dbg.tx( 32 ) 'print a space
dbg.dec( gz )
dbg.tx( 13 ) 'next line
The transmit buffer in the serial object is 16 bytes long, so sending more than 16 bytes at once will block until the first few characters get sent and there's room in the buffer for the rest. If that happens, it might not be able to keep up to the 250Hz output rate, so it'll appear to hang. If that happens, you can just temporarily change the waitcnt at the end to be 200hz, 150, 100, or whatever it takes to make it happy again. I use the hex version because it can't overflow the buffer, but it's less intuitive to read.
I got the VC# and compiled the program with Com10, changed the address of the gyro to $D0, the ADXL to $A6 and the compass to $3C. The system works except it doesn't seem to level the wing and the RPM decreases after a few seconds. I also tried all orienations just to be sure. I have the 9DOF from Sparkfun which looks a little different from yours. I can't seem to load the EEPROM now. It gives me an error. Loading the RAM works except on reboot. This happens sometimes but I forgot what makes it happen.
I'll play around with this setup for a while and try and learn as much as I can from it. Thanks very much.
I may get the ELEV-8 in April when I go back to Los Angerles for my checkup. I just want to use my own hardware instead of the closed system supplied.
When you say "doesn't level the wing", do you mean you're expecting it to figure out what "level" is and go there? Or just that it's not correcting anything? It should fight you if you try to move the wing off it's starting orientation, but it won't find level for you. I have a new version coming that does, but it's not quite ready yet.
It doesn't try to level the wing even though the wing starts out level. It also does not seem to "fight" any force upon the wing. In my case, the "X" is left and right and I have the motors on position 1 and 3. In the PC application, the gyro reading changes seem to be mostly on the GY axis no matter which confifuration I use. I'm not sure what the Drift Calculation is trying to show. Gain (Gear) doesn't seem to do anything.
Anyway, I will play around with this until your new version.
Thanks so much for your help. Maybe I'll get to Rocklin on Apr. 14.
The drift tab is showing the gx/gy/gz values mapped on the Y axis with temperature mapped on the X axis. The idea is that you keep the thing really still and heat it with a hair dryer. The code then figures out how your gyro values change as the temperature changes, and computes numbers you can plug into the ITG-3200 driver to compensate for it.
For your configuration, since you only have the roll axis anyway, you should be able to strip out all the code for everything but roll and throttle until you have that part working. You can just comment it out using the single quote at the beginning of each line you want to remove. Depending on which version of the code you grabbed, you may have one that doesn't even support the multiple gyro orientations. The QuadX code should, but the code posted in the thread for the Elev-8 doesn't, because the HoverFly board that it's written for has the gyro mounted in a known orientation.
Keep playing with it, and if you have any questions about the code I'm happy to answer them.
I have tried the code several times now and after reducing the thru-put to 100 Hz or less at least the motors keep running. My ESC's are old and probably do not support the fast updates.
I would like to know if there is any code available for the ELEV-8 or is it just for the Hoverfly? I don't mind purchasing the Hoverfly but I really want to add my own sensors and other items.
Currently you can't buy just the Elev-8 body. The QuadX code I posted is "generic", not tailored to the HoverFly board. The HoverFly open is supposed to support that with a small prototyping area. I just use a Prop Protoboard with the ITG on it for my QuadX code and it works just fine.
Great to see all the work being done here. As I'm about to dive head first into the quad arena and am a fan of the prop, I have a couple of quick observations.
As I see it, there are three "levels" at which flight controllers can play:
1) Flying around: basic control & stabilization (gyro, accelerometer). Examples: Hoverfly sport, Quardrino, OpenPilot CopterControl
2) FPV platform: above plus altitude and/or attitude hold (i.e. add a barometer a/or magnetometer) with camera gimbal control/stabilization. Examples: DJI Naza, Quadrino Zoom, Hoverfly Pro
3) FPV w/ Autopilot: Examples: Hoverfly Pro w/GPS & Gimbal add ons, Ardupilot Mega, DJI WooKong
For me, quads get *very* interesting from level 2 and above. I really want the Superman experience of flying from a first person view. If you aren't familiar with this, have a peek at a video such as this: http://www.youtube.com/watch?v=v-B2yfmU89k
It seems to date, the incredible work that Jason Dorie has done has brought the open source Prop community to level 1. However, we all know that the Prop has the potential to really outshine other solutions as we move to levels 2 and 3.
For example, the Prop has the chops to do all stabilization and sensor integration *and* implement the nonlinear kinematics to properly stabilize a 2-axis camera gimbal, as proposed by DonBin Lee et al at Clemson (http://www.clemson.edu/ces/crb/publictn/CU-CRB-3-11-07-1.pdf)
The prop can also easily handle the PWM algos for motor speed control (as we all know). Why bother, given that ESCs are fairly cheap? Well, at $30 each, they do add $120 to the cost of a quad, plus they don't do anything to solve the wiring hassles inherent in a quad build. I'd love to see the "open" board that's being discussed have a socket where a daughterboard could be added that has the FETs for speed control as well as some handy screw down connectors that allow motors to be wired directly. Such cards could come in 4, 6, & 8 motor versions.
But my main wish for the Prop-based "open" board (and the point of this whole post) is that it starts at "level 2", and very seriously contemplates level 3. I see the main competitor right now as the Quadrino Zoom ($145 w/ gyro, accelerometer, magnetometer, & barometer). In addition to GPS & telemetry integration, getting to level 3 from there becomes mostly a software issue. The stuff the DIYdrones group has done there is quite impressive (waypoint flying, etc).
I look forward to seeing the Prop mature in the multi-rotor space. I really think it's an ideal application for the chip to strut its stuff, and believe there's no better chip for the application!
I'm getting close to level 2 - I actually have it functional without a compass, but it still needs a good amount of tuning and testing. It also has camera stabilization built in already. "Soon", depending on your definition of soon.
I was just about to say - you added the 1500 offset to the ThroMix value, not the Throttle.
In case it's not clear, that ThroMix value is just used a scale to apply to the mixing code so that a non-throttle stick input when it's at rest won't start the motors spinning. I smoothly mix the balance code back in over a very short throttle range that wouldn't be useful in flight anyway. It'd be easy enough to make it just switch on/off instead, but this seemed cleaner.
I like your limiting code - I was pretty sure those could be done on one line, but wasn't sure how. I may have to adopt that.
IE:
eFront := 1000 #> eFront <# 2000
I'll time them to see which is faster, but yours looks like it'd be fewer ops.
Hello Jason, my name is John, and I know this post is old, but I am desperate for propeller knowledge, and this code for the elev-8 quadx code. I think I have found the code that you posted onto one of the forums, but I'm not sure how to flash it to the hoverfly open board. I am sort of new to coding, I have been studying for about a year now, but I still cannot write my own code. I purchased an elev-8 and all of the sensors, including gps, accelerometer, compass and altimeter. I just don't know how to connect them to the board, or write code for them. I know that's the whole thing, but I do know the basics of it all, I just can't put it all together. If you could just give me a little help, I would appreciate it GREATLY. Thank you in advance. John
I have a list of some of the quadcopter threads in post #10 of my index. Including a link to Jason Dorie's HoverFly Sport code (I don't know how the Sport differs from the Open board).
Comments
DCM is also a bit of a misnomer - The Discrete Cosine Matrix is just a fancy name for a rotation matrix. The code uses a DCM to represent orientation, and uses a complimentary (or fusion) filter to adjust that matrix given inputs from a gyro, accelerometer, and optionally a compass.
In simple terms, a DCM is a frame of reference - it contains 3 vectors which represent the X, Y, and Z axis of an object oriented in space. You can rotate the matrix by using relatively simple math. If the rotations are small (incremental), then you can short-circuit some of the math because of the way the terms play out. Sin & Cos of a very small angle value end up being close enough to (value) and (1 - value) that you can just use those instead of bothering to compute Sin & Cos.
A small amount of error is introduced, but that gets fixed constantly by making sure that all the vectors in the matrix are all tangent to each other, and have a length of 1.0 (this is called and orthonormal matrix, IE it is orthogonal, and normalized)
After rotating it with the gyro values, you take the current accelerometer value and compare it to the "down" vector of your matrix. The difference between them is an estimate of how far off you are, but it's noisy. So you scale it down, and use that result as an amount to "nudge" the matrix on the next rotation pass. You do the same thing with the compass reading if you have one, comparing it to "forward".
Check out this post for the code, and a link to the paper that told me how to do it:
http://forums.parallax.com/showthread.php?131022-Propeller-DCM-Now-with-source
Thank you very much for explanation about Arctan values. I have asked these values to implement complementery filter without floating point math.
my older code was a complementery filter using floating point math (f32 object)
And Yes I want something self leveling
It would be great If you share DCM based flight code.
I know DCM is better than kalman / complementery filter etc. Did you add a magnetometer to DCM solution ? or planning ?
Unfortunately we had a lot of Xmas and New Year visitors and I didnt get to actually fly my quad. I did go outside to perform a test and found that I had the axes mixed so I brought it inside to do some more work to ensure that when an arm of the quad dips, the software increases that motor.
Jason has really helped in simplifying my understanding of how it all works together. While I gathered what had to be done, I had no idea of how to apply the feedback.
I am a little new to the propeller. I started in it a few years ago but got sidetracked. I have built a board with 2 props, a DS1307, USB and other chips on it for eventually driving a BA-609 model. I have a 9DOF from Sparkfun attached as well as an FPU from Micromega. I also have inputs for SRF05 Sonic. I have allowed 10 inputs form an RC receiver on the first prop and 24 servos on the second prop. The board also has an micro SD card and an MCP3208 A/D as well as an MAX7456 OSD chip. The board checks out ok for all the individual inputs but now I have to put them all together and try and make something fly. I am trying to use SerialMirror for communication between props but am not sure how to use it. I need to send the servo data from prop1 to prop2 and GPS/FPU from prop2 to prop1. I just don't know how to mix the ADXL345 and IGT3200 outputs to the servo data.
The BA-609 is much like the quad except with only 2 motors. I may not have enough cogs to do what I want. Any suggestions would be appreciated.
I also have some extra boards if someone wants them. They are 3" x 4".
Donald
If 16 cogs isn't enough to do what you want, you must want something pretty impressive. What do you need 24 outputs and 10 inputs for? How many degrees of articulation are there on the motors themselves? (I'm guessing throttle, and rotate, but it could also be toe-in & pitch).
You could probably start with my code for the flight mixing basics, but the current published one just uses the gyro - no accelerometer. I have another version coming that does full IMU frame-of-reference calcs using the gyro and accelerometer, but I haven't released it yet.
Check this thread for the currently published flight code:
http://forums.parallax.com/showthread.php?136787-QuadX-my-latest-Propeller-with-Propellers&p=1070923&viewfull=1#post1070923
And this thread for a demo of the full-stability thing that's only partially released:
http://forums.parallax.com/showthread.php?131022-Propeller-DCM-Now-with-source
Thanks for the fast reply. Yes, I am the same Shanghai_fool. I had a bout with the big C and had to go back to the US for a while. As far as the cogs are concerned, I have Main loop, ADC, Kalman, Receiver,OSD, IMU and SerialMirror on the first prop and Mian loop, SerialMirror,servo32, Fpu/GPS, and possibly RPM x2 on the second.
As far as channels are concerned, I have not yet decided on whether I can fixed pitch props or may need 3 servo + ESC on each motor in addition to 5 servos for gear/doors and possibly other things such as steering and elevator. So far, I count 17 possible servos + 2 ESC.
If I can use fixed pitch props, the I only need individual minor tilt on the engines + full 90° tilt as well as flaps.
I did look at the DCM and finally got it to work by getting one of the boards to use Com8. It works very well. I haven't looked at the flight code yet but will tonight.
Donald
I tried various serial devices (Prop Terminal,Parallax Serial Terminal, Hyperterminal) and only got special characters (7F) so I'm not sure what was being output.
What are you using for Dbg terminal?
Thanks
I tried sending 0xAA +0xA5, 0xAB, 0xAC to the unit. I also changedGyroOrientation to 0 and FrameConfiguration to 0 in the DAT section.
I think I really need the ground station software to look at what is happenning but I just don't want to spend $600 on VS. I just don't use it that much. I have VB 6.0 that I use infrequently. I had to use that to make some special characters for the MAX7456.
It is completely free. You have to register it after a bit, but it's still free, and they haven't been spamming me or anything. To elaborate on the flight code a little, it's essentially a 3-axis heading hold gyro. It will resist orientation changes from outside forces, and will even remember where it was and try to go back there, but it has no idea where down is. That's what I mean when I say auto-stabilizing but not auto-leveling.
Depending on the gyro board you're using, you may need to change the device ID for the gyro in the ITG-3200-pasm.spin file. Mine is using the Sparkfun breakout board for that gyro, and they set the ID to $69 instead of the normal $68. Because of the way I2C works, I pre-shift the numbers up by one, so my gyro ID value is stored as $D2 ($69 << 1). Yours might need to be $D0 ($68<<1) for it to read properly.
By default, on startup it sends out gyro packets which are 0x7F, 0x7F, followed by GyroX, Y, and Z, two bytes each. (I can't remember if they're high or low). It'd be a simple thing to change that output code to spit out hex or decimal versions of those values instead, like this:
The transmit buffer in the serial object is 16 bytes long, so sending more than 16 bytes at once will block until the first few characters get sent and there's room in the buffer for the rest. If that happens, it might not be able to keep up to the 250Hz output rate, so it'll appear to hang. If that happens, you can just temporarily change the waitcnt at the end to be 200hz, 150, 100, or whatever it takes to make it happy again. I use the hex version because it can't overflow the buffer, but it's less intuitive to read.
I'll play around with this setup for a while and try and learn as much as I can from it. Thanks very much.
I may get the ELEV-8 in April when I go back to Los Angerles for my checkup. I just want to use my own hardware instead of the closed system supplied.
Donald
www.onedir.com
Anyway, I will play around with this until your new version.
Thanks so much for your help. Maybe I'll get to Rocklin on Apr. 14.
For your configuration, since you only have the roll axis anyway, you should be able to strip out all the code for everything but roll and throttle until you have that part working. You can just comment it out using the single quote at the beginning of each line you want to remove. Depending on which version of the code you grabbed, you may have one that doesn't even support the multiple gyro orientations. The QuadX code should, but the code posted in the thread for the Elev-8 doesn't, because the HoverFly board that it's written for has the gyro mounted in a known orientation.
Keep playing with it, and if you have any questions about the code I'm happy to answer them.
I would like to know if there is any code available for the ELEV-8 or is it just for the Hoverfly? I don't mind purchasing the Hoverfly but I really want to add my own sensors and other items.
Great to see all the work being done here. As I'm about to dive head first into the quad arena and am a fan of the prop, I have a couple of quick observations.
As I see it, there are three "levels" at which flight controllers can play:
1) Flying around: basic control & stabilization (gyro, accelerometer). Examples: Hoverfly sport, Quardrino, OpenPilot CopterControl
2) FPV platform: above plus altitude and/or attitude hold (i.e. add a barometer a/or magnetometer) with camera gimbal control/stabilization. Examples: DJI Naza, Quadrino Zoom, Hoverfly Pro
3) FPV w/ Autopilot: Examples: Hoverfly Pro w/GPS & Gimbal add ons, Ardupilot Mega, DJI WooKong
For me, quads get *very* interesting from level 2 and above. I really want the Superman experience of flying from a first person view. If you aren't familiar with this, have a peek at a video such as this:
http://www.youtube.com/watch?v=v-B2yfmU89k
It seems to date, the incredible work that Jason Dorie has done has brought the open source Prop community to level 1. However, we all know that the Prop has the potential to really outshine other solutions as we move to levels 2 and 3.
For example, the Prop has the chops to do all stabilization and sensor integration *and* implement the nonlinear kinematics to properly stabilize a 2-axis camera gimbal, as proposed by DonBin Lee et al at Clemson (http://www.clemson.edu/ces/crb/publictn/CU-CRB-3-11-07-1.pdf)
The prop can also easily handle the PWM algos for motor speed control (as we all know). Why bother, given that ESCs are fairly cheap? Well, at $30 each, they do add $120 to the cost of a quad, plus they don't do anything to solve the wiring hassles inherent in a quad build. I'd love to see the "open" board that's being discussed have a socket where a daughterboard could be added that has the FETs for speed control as well as some handy screw down connectors that allow motors to be wired directly. Such cards could come in 4, 6, & 8 motor versions.
But my main wish for the Prop-based "open" board (and the point of this whole post) is that it starts at "level 2", and very seriously contemplates level 3. I see the main competitor right now as the Quadrino Zoom ($145 w/ gyro, accelerometer, magnetometer, & barometer). In addition to GPS & telemetry integration, getting to level 3 from there becomes mostly a software issue. The stuff the DIYdrones group has done there is quite impressive (waypoint flying, etc).
I look forward to seeing the Prop mature in the multi-rotor space. I really think it's an ideal application for the chip to strut its stuff, and believe there's no better chip for the application!
Hello Jason, my name is John, and I know this post is old, but I am desperate for propeller knowledge, and this code for the elev-8 quadx code. I think I have found the code that you posted onto one of the forums, but I'm not sure how to flash it to the hoverfly open board. I am sort of new to coding, I have been studying for about a year now, but I still cannot write my own code. I purchased an elev-8 and all of the sensors, including gps, accelerometer, compass and altimeter. I just don't know how to connect them to the board, or write code for them. I know that's the whole thing, but I do know the basics of it all, I just can't put it all together. If you could just give me a little help, I would appreciate it GREATLY. Thank you in advance. John
I have a list of some of the quadcopter threads in post #10 of my index. Including a link to Jason Dorie's HoverFly Sport code (I don't know how the Sport differs from the Open board).