Hi,

I’m working on a Quadcopter for my senior design in
electrical engineering (this is the last semester). There are two problems with
this, my professors don’t allow me to use an already made code or share my code
so this makes it a little bit difficult to ask for help, but I’m going to try
to explain my program as much as I can. This might also work as a guide to
anyone trying to make their own program. (I’m using an arduino mega)

 

Right now, I’m having a lot of problems getting my PID
coefficients to work. (I hope that’s the only thing I need)

 

I’m using http://www.sparkfun.com/products/9431
6 DOF 2 gyros 1 accelerometer to get my pitch and roll angles (I also have a
magnetometer to measure the yaw but I’m not implementing that yet). In order to
get the angles I multiply the gyro reading times the difference of the time and
to get the angles from the accelerometer I use trigonometric functions
(accelerometers give the vector of the acceleration and you have to get the X
and Y angles from that vector).

 

After calculating the angle from the gyroscope and
accelerometer I use a kalman filter to mix both signals, you need to combine
them because a gyro keeps increasing its error with time and the accelerometer
is too noisy and gives wrong readings in certain occasions. I used to have a
complementary filter but I think the Kalman filter works better, the
complementary filter is only an equation:  compAngleX = (0.98*(compAngleX+(gyroXrate*dtime/1000)))+(0.02*(accXangle)).
I’m using almost the same script as this one: http://arduino.cc/forum/index.php/topic,58048.0.html
great project and guy by the way very helpful.

After the kalman filter I’m able to get a pretty accurate
angle in both directions going from -90 to 90 there might be two problems with
this though, I don’t actually know if I’m getting the angle measurements fast
enough because of the sensors or the script and I don’t know if I should use
low pass filters (my sensors are analog not digital). The measurements look
fast enough although my eyes can’t read at 50Hz or more so I have my doubts.

After the kalman filter I use the angles as input for a PID
control, I’m using the arduino PID library for this. This might not be good
enough I really don’t know. I know how a PID is supposed to be but I don’t
think I can do a better PID that the one in the library, the guy who wrote it
did a pretty good job ( here’s the explanation made by the author:  http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid...)

 

These are my settings for the PID:

My set point varies with respect of the receiver signal for
pitch and roll, the set point is 0 when I’m not touching the remote control
stick and it can go up to 35 this means that when I move the stick all the way
the PID will try to set the output (which is the actual angle of the quadcopter)
to 35 degrees in the specified direction.

 

The PID library is on automatic which I think means that it
will always be working, manual is when you want to turn the PID off at some
point.

 

My output limits go from -90 to 90 this are the same as the
input angles, I don’t know if this will cause a problem. I didn’t want to have
more than 90 as a limit since the PID might take longer to get to the maximum
and I kind of wanted to keep the value from -90 to 90.

My sample time for the PID is 10 milliseconds which will
give 100 Hz, my ESCs run at 50 Hz so this should be fine? I’m not entirely sure;
maybe the sampling time should run at the exact frequency needed (50 Hz).

 

Finally, I have two sets of coefficients for the PID one set
of conservative coefficients (really small almost 0) and a set of aggressive
coefficients. The aggressive coefficients are used when the difference of the
angle and the set point is more than 10 degrees and the conservative when it is
less. I haven’t experimented with the two sets of coefficients that much, I
used to have only one set but I found out that with vibrations the sensors can
measure a little less than 10 degrees even when at an actual 0 degrees so
hopefully this will eliminate some noise and increase the speed of the motors when
it actually needs it.

Now, my biggest question comes right after this. Once I have
the value coming out of the PID I add that value (absolute value) to the value
of the throttle (the one that controls the speed of the 4 motors at the same
time) my question is: what is the recommended percentage that the direction and
balancing signals should have with respect of the maximum speed of the motors?

 

I actually have a potentiometer that changes the value of
the throttle (the value for direction and balancing always go from 0 to 90 when
taking absolute value) this changes the percentage of those signals.

To send the signal to the ESCs I’m using the arduino servo
library this should be working just fine, I used an oscilloscope to check that
the signals coming out of the arduino give the same width (minimum and maximum)
and frequency as my receiver of the remote control, I don’t have the values
right now but it was somewhere close to 50 Hz and 1000ms minimum width and
2000ms maximum width.

I might be calibrating the ESCs the wrong way though, what
you are supposed to do in order to calibrate them is to start the motors having
the throttle in the maximum position then after hearing certain beeps you are
supposed to lower the stick to the lowest position, this makes the ESCs know
what are your maximum and minimum widths and adjusts to make them its maximum
and minimum speed.

To make that work, my maximum value before going to the
servo library is the maximum value of the throttle this presents a problem, if
the throttle is at its maximum the motors won’t have any room to increase their
speed when the PID needs it in order to get the quad to the set point, this
shouldn’t be a big problem at first since I usually never go above the 50% of
the throttle in order to make the quad fly.

Sorry, this is getting quite long for a post. Just to make
it clearer I’m using a + configuration this means that to balance the quad I increase
the speed of the motor that is tilted down and for example when I need to go
forward the motor in the back increases its speed.

 

To calibrate my PID I start with only one axis (I disconnect
the other two motors and hang them) then 
I start calibrating, which I think works pretty well, the working axis
stabilizes really fast actually faster than some that I’ve seen in some videos,
but when I try all the motors at the same time I’m having a lot of problems
getting it off the ground. Let me rephrase that, it does get off the ground
somewhere around 10 cm, sometimes it wobbles a lot but it is still sort of
flying and some other times it looks like it is stable but when I try
increasing the speed a little bit more it just flips quite fast, as if it isn’t
even trying to stabilize after some point but it does stabilize when trying it
on one axis.

 

To anyone making their own quad you need the PID control it
really changes things I tried it first with no PID and you get an unstable
system and I really mean unstable, instead of decreasing the angle it just
keeps increasing more and more, it’s kind of fun to watch…

 

Anyways, is there something that I’m missing? Some secret
kind of PID control no one ever talks about or am I making a mistake or having
a wrong approach somewhere?

 

I hope someone can give me some hints and that this post
helps someone. If anyone has any question I’ll try to answer as fast as I can.

Eric

Views: 10489

Reply to This

Replies to This Discussion

Hoo boy.

 I’m working on a Quadcopter for my senior design in electrical engineering (this is the last semester). There are two problems with this, my professors don’t allow me to use an already made code or share my code

When you get something tangible and working, challenge your professors for this reasoning. Yes, it's generally a good idea to know what your using, but a Quadcopter is one of those systems that a one-man team can NOT build completely from scratch in a few months. (Trust me, I know)
  

I’m using http://www.sparkfun.com/products/9431
6 DOF 2 gyros 1 accelerometer to get my pitch and roll angles (I also have a magnetometer to measure the yaw but I’m not implementing that yet).

In order to get the angles I multiply the gyro reading times the difference of the time and to get the angles from the accelerometer I use trigonometric functions (accelerometers give the vector of the acceleration and you have to get the X and Y angles from that vector).

Yep, that's how you do it, although you really want to have a single, concrete sampling period for a discrete control system (which is pretty much what every microcontroller can only do, no continuous!).

 

I used to have a complementary filter but I think the Kalman filter works better, the
complementary filter is only an equation:  compAngleX = (0.98*(compAngleX+(gyroXrate*dtime/1000)))+ .02*(accXangle)).

To be honest, it depends on what your MCU can handle. Basic complementary filters are pretty basic, and are "good enough" for the most part, but if your application demands better blending, then the more expensive Kalman filter will suffice.

After the kalman filter I’m able to get a pretty accurate angle in both directions going from -90 to 90 there might be two problems with this though.

You really need to extend that range to a full 360 degrees, (or 2pi radians).

 I don’t actually know if I’m getting the angle measurements fast enough because of the sensors or the script. I don’t know if I should use low pass filters (my sensors are analog not digital).

Sparkfun's Analog Razor has LPF's built on them, check the schematics and you'll see an RC filter tuned for 50Hz.

 The measurements look fast enough although my eyes can’t read at 50Hz or more so I have my doubts.

There isn't an oscilloscope available to you?

After the kalman filter I use the angles as input for a PID control, I’m using the arduino PID library for this.

I don't know what Arduino's libraries have, but if they have it so that the sampling time is variable, expect problems. Remember that discrete systems should have a standard sampling time. Research z-domain functions, difference equations.

I don’t think I can do a better PID that the one in the library, the guy who wrote it
did a pretty good job ( here’s the explanation made by the author:  http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid...)

 

I haven't read through all of this just yet, but so far he sounds like he knows his stuff.

These are my settings for the PID:

My set point varies with respect of the receiver signal for pitch and roll, the set point is 0 when I’m not touching the remote control.

Pretty standard. In a systems set your set point is your "desired" or "commanded signal."


The PID library is on automatic which I think means that it
will always be working, manual is when you want to turn the PID off at some
point.

You really need to check to see whats the difference between automatic and manual.

 

(cont...)

(Reply cont...)

My output limits go from -90 to 90 this are the same as the
input angles, I don’t know if this will cause a problem.

 Don't limit your error signal. Apply saturation (or constrain) to only the input signal (your set point).

My sample time for the PID is 10 milliseconds which will
give 100 Hz.

Research what the audio industry uses to sample signals.

 ...my ESCs run at 50 Hz so this should be fine?

NO. Your ESC's will NOT be fine at 50Hz, especially if they're cheap. If your lucky, and you got the auto-ranging type, you might be able to use the so-called TurboPWM treatment on them.

Finally, I have two sets of coefficients for the PID one set of conservative coefficients (really small almost 0) and a set of aggressive coefficients. The aggressive coefficients are used when the difference of the
angle and the set point is more than 10 degrees and the conservative when it is less. I haven’t experimented with the two sets of coefficients that much, I used to have only one set but I found out that with vibrations the sensors can measure a little less than 10 degrees even when at an actual 0 degrees so hopefully this will eliminate some noise and increase the speed of the motors when it actually needs it.

If you set your Kalman filter right, and you put your sensor in the right place, you shouldn't have more than 3 to 5 degrees of noise. I don't remember exactly, but I think my accelo's where digitally LPF'd at 3Hz or so using the complimentary filter.

Once I have the value coming out of the PID, I add that value (absolute value) to the value of the throttle (the one that controls the speed of the 4 motors at the same time) my question is: what is the recommended percentage that the direction and balancing signals should have with respect of the maximum speed of the motors?

They should be small, really small. We're talking like 2 to 5% throttle (20 to 50us pulse width) for minor wind gusts. You can go up higher but keep in mind quads generally have very low momenta of inertia. Determine a basic physical model of your craft so you can figure out what difference in speeds between the motors will determine what maximum rotational speed you'll get. Hint: the drive equation for thrust drops to zero at some speed. Also, the length the motor is away from the COG plays a factor.

 

I used an oscilloscope to check that the signals coming out of the arduino give the same width (minimum and maximum) and frequency as my receiver of the remote control, I don’t have the values right now but it was somewhere close to 50 Hz and 1000ms minimum width and 2000ms maximum width.

Pretty standard. If your using auto-ranging ESC's that are meant for planes, you might experiment with setting the floor width to 900ms, so that at 1000ms the motor will spin. I don't know if helicopter ESC's do that since I haven't had time to get one yet.

I might be calibrating the ESCs the wrong way though, what you are supposed to do in order to calibrate them is to start the motors having the throttle in the maximum position then after hearing certain beeps you are supposed to lower the stick to the lowest position.

If they're the auto-ranging type, you can  calibrate them this way NOTE: DANGEROUS.

  • Apply lowest PWM for 1 second
  • Apply highest PWM for 1 second
  • Apply lowest PWM for 1 second

I'd suggest mounting a motor and an ESC to something heavy like a 4x4x12" block of wood, and without a propeller attached. Experiment with different ways and different waveforms to the ESC and see what works.

  

To make that work, my maximum value before going to the
servo library is the maximum value of the throttle this presents a problem, if
the throttle is at its maximum the motors won’t have any room to increase their
speed when the PID needs it in order to get the quad to the set point, this
shouldn’t be a big problem at first since I usually never go above the 50% of
the throttle in order to make the quad fly.

ArduCopter limits the available maximum collective to 80% to allow for enough headroom to stabilize, I'm sure a few other autopilots do the same.

Just to make it clearer I’m using a + configuration.

They're the easiest to stabelize in regards to code. x configurations filter the final output with a simple cosine matrix (a.k.a. rotation matrix).

I’m having a lot of problems getting it off the ground...

Let me rephrase that, it does get off the ground somewhere around 10 cm, sometimes it wobbles a lot but it is still sort of flying, and some other times it looks like it is stable, but when I try increasing the speed a little bit more it just flips quite fast, as if it isn’t even trying to stabilize after some point but it does stabilize when trying it on one axis.

Yep. Sounds like you did something wrong. Remember that the output to the motor is the sum of the collective and the corrective output of the PID. Also remember that the PID output is not a % of the collective.

 

Anyways, is there something that I’m missing? Some secret kind of PID control no one ever talks about or am I making a mistake or having a wrong approach somewhere?

 

 Well there are other controller schemes out there, but PID is perhaps the best place to start. That, and brush up on your discrete systems and see if there's a chapter or two in your controls systems book.

Wow that was a great reply thanks. Your project sounds awesome ill have to read some fuzzy logic stuff some time in my life.

Well, i have some doubts about your reply i tried researching the stuff you wrote but i couldnt find some of it.

" you really want to have a single, concrete sampling period for a discrete control system (which is pretty much what every microcontroller can only do, no continuous!)."

all microcontrollers are discrete in practice so i dont know what you mean, am i aproaching something as continues which i shouldnt or something like that?

 

" don't know what Arduino's libraries have, but if they have it so that the sampling time is variable, expect problems. Remember that discrete systems should have a standard sampling time"

you can define different sampling times but they are not variable while running the program

 

"Don't limit your error signal. Apply saturation (or constrain) to only the input signal (your set point)"

Im not exactly sure what you mean with this, im not an expert on PID i only know how to use the arduino library ha... in this library you have to define the range of the output, it could be any value but by constrain i understand that i should have a lower range for the output as this might get the PID to work faster?

"NO. Your ESC's will NOT be fine at 50Hz, especially if they're cheap. If your lucky, and you got the auto-ranging type, you might be able to use the so-called TurboPWM treatment on them."

So 50 Hz is not enough? do you know if im able to use the turnigy sentry 25A at a higher frequency? its just like the plush http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=... but with another connection that goes to the battery to read the cells. I really dont want to burn them. Do i have to do some modification to the ESCs? or i just use a higher frequency as long as the pulse width is between 1 and 2 milisecs?? This is the thing that concerns me the most so i would appreciate al the info you could give me. I'm reading this http://wiki.openpilot.org/display/Doc/TurboPWM+ESC%27s#TurboPWMESC%... but its kind of vague at some issues.

 

"

f they're the auto-ranging type, you can calibrate them this way NOTE: DANGEROUS.

  • Apply lowest PWM for 1 second
  • Apply highest PWM for 1 second
  • Apply lowest PWM for 1 second "

This is to calibrate the frequency or the max and min Pulse width?

" Also remember that the PID output is not a % of the collective"

do you mean that the contol PID output should not depend on the collective, the total should be a sum of both the collective and the control without any of them depending on each other right?

 

In conclusion what i get from your reply is that one of the most important things is to get the fastest loop time possible and use this frequency directly on the ESC right? obviously there are sampling concerns with the sensors. I think i read somewhere that you have or had the same sensor board as me the 6dof rasor and there is the problem of the 50Hz filters should i still be fighting for a faster loop and PWM to the ESCs?

 

Thanks for all the help and good luck with your project.

Eric

Your project sounds awesome ill have to read some fuzzy logic stuff some time in my life.

 

Thanks, it is an interesting topic, but should be probably done only after one has a good understanding of controller theory. I'll admit that I'm trying to improve my understanding of PID's and FLC's at the same time...

 

" you really want to have a single, concrete sampling period for a discrete control system (which is pretty much what every microcontroller can only do, no continuous!)."

all microcontrollers are discrete in practice so i dont know what you mean, am i aproaching something as continues which i shouldnt or something like that?

 

I think I got a glimpse of an Arduino's PID library that had the sampling time defined as a variable... that just didn't sit right with my coding ethics paranoia, lol.

 

"Don't limit your error signal. Apply saturation (or constrain) to only the input signal (your set point)"

Im not exactly sure what you mean with this, im not an expert on PID i only know how to use the arduino library ha... in this library you have to define the range of the output, it could be any value but by constrain i understand that i should have a lower range for the output as this might get the PID to work faster?

 

I think the point of output saturation is to be just a safegaurd, and prevent the I term from becoming too large (or something along those lines).

 

Ah, but as far as the input values, the input signal (your set point) should be constrained to prevent nonsense values such as "570 degrees." The error signal (commanded input - sensed input) shouldn't be constrained since the PID has to know how big of a difference you want it to be vs. what it currently is.

 

"NO. Your ESC's will NOT be fine at 50Hz, especially if they're cheap. If your lucky, and you got the auto-ranging type, you might be able to use the so-called TurboPWM treatment on them."

So 50 Hz is not enough?

 

Not by a long shot. From tests I've done with my ESC's, I've determined that the response operates on signals 1 / 2.2 of the input frequency. So if I set a 50Hz signal to my ESC's (BP Hobbies 18A) they won't change the motor speed until the 2nd or 3rd pulse. This effectively means that my ESC's, given a 50Hz signal, actually operate around 23Hz. 

 Do i have to do some modification to the ESCs?

 

That all depends on which ESC your using, if they're autoranging, they'll not only map the maximum and minimum pulse width to % throttle, but they will usually also take a higher framerate. (In the R/C lingo, a "frame" is a single pulse).

 

The idle-full-idle technique I've been using so far has been working for me. I think during one of my tests I found that if my framerate was too fast, it wouldn't recognize the 100% throttle when you started it up. I found that by using idle first, the ESC would recognize the higher framerates.

 

"Also remember that the PID output is not a % of the collective"

do you mean that the contol PID output should not depend on the collective, the total should be a sum of both the collective and the control without any of them depending on each other right?

 

Absolutely. The final output to each motor should be the collective plus the output of the attitude controller for that motor. The collective would be varied by a seperate height controller routine.

 

In conclusion what i get from your reply is that one of the most important things is to get the fastest loop time possible and use this frequency directly on the ESC right?

 

Ideally, yes. But as I meantioned before, your ESC might be halving the frequency your giving it.

obviously there are sampling concerns with the sensors. I think i read somewhere that you have or had the same sensor board as me the 6dof rasor and there is the problem of the 50Hz filters should i still be fighting for a faster loop and PWM to the ESCs?

 

With a 50Hz filter on a sensor, this means that the sensor can only output 50Hz signals to whatever is connected to it. From the standpoint of the controller, this means that you can run the control loop at a frequency of infinity plus... but your final output signal would still look like it's 50Hz.

 

And lastly, time-varying signals have issues with resolution if the digitizer is too slow. This is usually solved by making the digitizer run at the Nyquist frequency, which is 2 times the maximum frequency of the desired signal.

 

This leads us to two rules of thumb:

 

  • In a control loop, you are only as fast as your slowest frequency.
  • When digitizing a time-varying signal, use a sampling rate that is at least a factor of 2 of the desired maximum signal frequency

 

Note that the audio industry prefers the factor of 2.2 for their sampling rates as an extra insurance.

Thanks, ive done some work on the program and im sending 150 Hz to the ESC im still working to make this faster, whats the frequency that you send to your ESC? and did you end up changing sensors or you stayed with the rasor? (since it has the 50 Hz low pass filter)

 

Eric

I'm running my ESC's at 400Hz. Even though my control loop is currently going at 110Hz or so,  I made the ESC's run at that frequency just so I could have some extra head-room when I finally did upgrade the IMU.

 

I'm still sticking with the old analog razor while I'm getting the program into a "usable" state. It's pretty much isolated to lab tests for now, but it should suffice.

My quadcopter is flying (kind of)  thanks to all your help :)

It is pretty stable although it kind of tilts in one direction but im pretty sure thats because of the structure when i put some counter weight on it it flyes better.

Now im working on the yaw control since it's spinning quite a lot. Would you know if the CCW motors make the quad spin to the left and the Clock Wise to the right?

Also, I have the same question with the percentage speed that it needs to increase in order to control the Yaw. You told me it was around 5 % for the pitch and roll although that didnt work for my quadcopter since it is very heavy (im working on that) my quadcopter used 33% of the total speed of the motor in order to balance itself.

Thanks for your help, How is your quadcopter going?

Don't mention it, :) It's always better to have somebody with experiance help you out than trying to fly solo from the start.

 

If it's continually tilting in one direction, you may have to double check your I term (assuming your using a PID compensator). The I term is solely responsible for correcting any "DC offset," so you probably have to play a bit more with the Ki gain.

 

Now, I haven't been able to get to the Yaw control as of yet, but I have done research on it as well as a bit of thinking. Remember Newton's laws? "An action on a free-body always has an equal and opposite reaction" or something along those lines...

 

Anyway, When the motors have a "constant" speed, the CCW motors will make the quad spin CW, while the CW motors willl spin it CCW. Quad's turn themselves by speeding up one pair while proportionally slowly down the other pair. Depending on the mass of your craft and your rotors (propellers AND motors), your quad may be able to rotate slowly for a fraction of a % difference or maybe as large as 20%.

 

There's also this bit about motors producing much more torque when they're speeding up or down, but since you have a heavy quad I don't think this will be much of a problem for you now.

 

And unfortunately my quad hasn't progressed much since we've last spoken. Blasted homework keeps getting in the way, Lol.

 

Hey,how have you been?

I finished a lighter stucture last week and im currently working in the Yaw control still... have you had any luck with it? any good ideas on how to calibrate that PID?

I have one question that you might have the answer to. All the quadcopters that Ive seen have the sensors in the middle but wouldnt it be better to have them as far from the center as posible? since a small degree change makes more difference as you go away from the center? maybe im just not thinking right i have to inish this in a few weeks lol...

Reply by Eric

Hey,how have you been?

I finished a lighter stucture last week and im currently working in the Yaw control still... have you had any luck with it? any good ideas on how to calibrate that PID?

I have one question that you might have the answer to. All the quadcopters that Ive seen have the sensors in the middle but wouldnt it be better to have them as far from the center as posible? since a small degree change makes more difference as you go away from the center? maybe im just not thinking right i have to inish this in a few weeks lol...

I've been doing alright, thanks for asking! I did a presentation at Texas A&M's Pathways Symposium last week, and had a good time. The poster presentation itself was in shambles, but I didn't mind at all - its the experiance going there is what counts.

 

I've haven't had any luck with the system so far... currently the old 0.1 code is officially down the trash bin, and 0.2 C++ code is in the works. Wish I had a couple of more people help with the construction of the system code, but that's basically how it has been since the start.

 

Bitterness aside, the new code will be in AV/MISRA complient C++ and take advantage of classes and other "non-memory hogging" features as much as possible. The new Vector and Matrix classes are looking promising with their ability to be at any size, but otherwise is another headache within a headache.

 

The Yaw PID controller should be tuned just like any of the other systems, Zero the I and D and adjust the P until it oscillates or barely decays, and then adjust the I and D terms... ( there should be a detailed guide on how to do this somewhere )

 

The IMU sensor placement can theoritically be anywhere you want it to be, but keep in mind that the accelerometers are made to sense all linear accelerations. If you have an accelerometer offset from the centor of rotation ( which in our case is the C.G. or C.M. ) then the accelerometer will detect rotational acceleration in addition to gravity and the craft's linear acceleration.

 

a = g + (radius*w)

 

a = acceleration sensed by the accelerometer

g = acceleration due to gravity

radius = the distance from the center of rotation

w = the angular acceleration about the center of rotation

 

In fact, if you can place the IMU sensor at a known distance away from the C.G., you may be able to use the IMU for yaw dampening, versus the standard compass and gyro. Keep in mind though that for absolute heading, a compass and GPS is still the preferred way to go, since noise filtering is tricky.

Hey Allen, yesterday i finished programming and setting up my i2c sensors (the ones they use in Aeroquad) and they perform 10 times better than the old razor we have so if you havent changed it i would recomend doing it.

Now i was checking for noise on my sensors, and a lot of it came from the motors vibrations which i reduced by balancing props, putting some foam to reduce the vibration and stuff like that but i was still receiveng too much noise, specially in the magnetometer so i decided to put the receiver antena as far as i could and it reduced the noise by a whole lot.

Right now i am using a breadboard with wires connecting everything.I know bad idea, the i2c didnt even work until i twisted the cables. Im making my PCB this week which will help reduce a lot of the noise i think. My question is do you know of a way of eliminating the noise from the receiver? should i be covering the arduino and sensors with a case and putting the receiver outside ? wrapping something in aluminum helps? Anyway anything you know on the subject should be a lot of help. I tried looking for answers but apparently no one cares that much about it maybe im the only idiot that designs a quadcopter with a breadboard with huge i2c wires (they are not that big lol)

Glad to hear! I'm unfortunately stuck with the razor for now until I can get some additional hobby funds, I'm also grounded until I can flesh out the new 0.2 code. :(

 

The receiver shouldn't be causing noise on your compass, unless the amplifier is leaking RF. Don't put your compass inside of a metal box, because that will block out the Earth's magnetic field too. You could try placing the receiver inside of a metal box and try grounding/not grounding it to see what happens.

 

Wrapping in aluminum works if you can't get a box, but be careful when stuff comes into contact with it.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service