Well, as the school year winds down, and we go into a state of shock realizing how many tests we’re about to take… we need not study! There’s work to be done!
So, last weekend Matt and I met up again to get a little more minuscule bits and pieces sorted out. He had been complaining about the switch that pulls the reset line high or low to put the PIC in programming or run mode, saying “It won’t reset to programming mode, I put it in programming mode, but it doesn’t make contact, and I think the switch is broken…” Needless to say, the whole time I tested it, it went into programming mode perfectly fine.
… Well, except for when it didn’t… and then he rubbed it in my face, but all in good fun. So, first on our agenda was changing the switch, which we had come up with an ingenious plan for: There is a pin on the PIC that is a reset line, pulling it high will reset the microcontroller. I just so happened to have a reset button from a computer… a very special button. It was a double poll double throw switch (DPDT)… but a momentary push switch, so it had two feed lines, and then each feed line would go to one of two leads depending on if the button was pressed, or released. This would be perfect, we figured! We would put the reset line on one side of the button, so when you pressed it, it would automatically reset the whole PIC, as well as the choosing line on the other half of the button, which would pull the pin high, to put it into programming mode. After plenty of redrawings of the schematic, and Matt realizing when you flip the button over, the pins also happen to flip (left is on right, right on left now) (again, I’m just teasing him, he’s extremely smart) we finally reached a final draft. There would be two options, you could press the standard reset button on the PIC, to which the choose line would always be pulled low (momentary second button) and so you would reset the PIC into run mode, or you could press the new button, which would use the secondary reset line to reset the PIC, and also pull high the choose line, leaving it remaining high for a fraction of a second after you released the button via a capacitor so as the PIC booted, the line would remain high long enough for it to recognize the fact. This would be perfect, no more Matt flipping a semi-broken switch and pressing a button, and pressing a button but realizing he forgot to flip a switch, etc. etc. However, as we pulled our precious one-of-a-kind switch out of the breadboard (which we had to… jerry rig to make fit, see picture below) one of the pins broke off… and that was the end of that. No amount of pleading with my parents to just let me have a quick look in their computers to see if the power switch was the same kind, because I could easily replace it! It only needed two of the six pins! (which ours still had) helped.
Testing the New Switch
You see, breadboards are designed for ICs, the middle slot is wide enough to accommodate the two hole gap between the pins of a standard IC so the rows of connected pins can span outward in either direction, but not short the two pins on opposing sides of an IC together. Sadly our switches hole spacing was 3×3, so there was only a one hole gap in the middle. We couldn’t span the breadboard’s built in break in rows, so we had to come up with a way to still momentarily test the switch. It turns out an IDE ribbon cable (for hard/CD drives before SATA) butted up against the breadboard gives an exact one-hole-gap. So, as ridiculous as this may look, and as ridiculous as it felt, it worked!… Until we broke the pin off.
Without a momentary DPDT switch we had to dig up the next best thing, which turned out to be a normal DPDT. We decided against making the design any more complicated than need be, and just replaced the old SPDT we had been using that had broken.
Among other accomplishments during our meeting, we added landing gear (cut a pool noodle into two inch long sections, and zip-tied to the bottom four corners of the quad, pictures to come later), modified an adapter for Matt’s new “fancy” battery charger, watched it balance the cells automatically, charge them, etc. We deduced that despite our fears, the Lithium Polymer battery pack we have been using is not going bad (we were quite releived), and swapped out a propeller blade, since someone’s feline friends enjoy chewing… (to clarify, not mine)
Propeller we replaced
Good thing we bought extras!
Finally, we realized that our 12V to 8V power supply was heating up a little much. To be sure we weren’t drawing too much load or harming it in any way, we tested current draw with certain sensors plugged in and unplugged. Determining everything should be fine, and we had no shorts, we just added a nice heat-sink.
New Heat Sink for 12-8V
While this next photo is a little blurry, it shows the perfect placement with which we planned to fit the heat-sink, right around our USB plug for the PIC. Yeah… that’s right… planned… like everything, right?
As if it were designed to fit...
~Will
I am pretty impressed by the progress you guys have been doing in your project. I follow your blog and it is pretty impressive how you have come such a long way. We are also currently working on building a autonomous quadcopter, but we have a long way to go. We are able to interface with the 6DOF IMU, but haven’t applied any filtering (Kalman) yet. We primarily concentrated on RPM feedback. Have you guys considered any RPM feedback from your motors, or is it just the IMU feedback you guys are dealing with?
Thanks
Guinness
email conf
Hey Guinness, thanks for reading our blog, and sorry I’m replying so late. I’m actually quite surprised anyone else puts up with this crazy, scattered build log that’s now exceeded our wildest construction time estimates three times over
.
To be honest, I have no idea how to achieve RPM feedback with these cheap RC motors and speed controllers, and I’m also not entirely sure how that information would help. My understanding was that the ESC regulates the motor to an RPM roughly proportional to the PWM signal, so assuming its doing a decent job of it it shouldn’t really be needed? Although, at this point we have at this point no idea how accurately and or quickly we change RPMs, and after reading about others’ quads, particularly the really nice German ones, that is apparently an important factor in quads.
Hi Matt,
Thanks for the reply. We were primirily focusing on RPM feedback as a means to model our motor and control the response time of our motor. We used hall sensors to get RPM feedback. But now I beleive that concentrating in the IMU will be a wise decision as it clearly makes sense. We have a 6-DOF IMU. We were able to derive the position from accelorometer data and just showed in a GUI with Artificial Horizon in which we would clearly see the tilt along roll and pitch axis. We havent got to the point where we will apply data fusion (Kalman filtering) of the accelerometer and gyro data. Infact, just learning the basics of Kalman filter. Do you have any suggestions on how to start off with this process?
Thanks
I’ve been meaning to write up a blog post to try make the world’s first decent explanation of the Kalman filter for non-mathematicians… but I haven’t had time yet. I do have some GNU octave scripts in our codebase on github that run them offline that are slightly commented, if they help much. Here’s a link:
http://github.com/matthewbot/Quadcopter/tree/master/Octave/
In particular, this file sets up the matrices we used for the roll or pitch axis:
http://github.com/matthewbot/Quadcopter/blob/master/Octave/rollkalman.m
These are based around the wikipedia article on kalman filtering
http://en.wikipedia.org/wiki/Kalman_Filter
The F matrix describes how the state is expected to change, and basically says that we expect the angle to change at a rate equal to the angular velocity, and that our velocity and gyro bias is to remain constant. Velocity obviously doesn’t remain constant, but in the Q matrix we can give our state predictions an expected amount of error to compensate.
The H matrix describes how the state relates to an observation. It says that the accelerometer gives us a direct reading of our angle, but the gyro gives us a reading of our velocity minus our velocity offset.
The Q and R matrices are the fudge numbers, that control expected error in our state predictions, and expected error in our sensor readings. The ones in there act reasonably but I don’t know if they’re necessarily any good.
Once you define those four matrices you just have to implement the formula, and read answers out of the state vector. Hope this helps!