Teensy Quadcopter

Status
Not open for further replies.

simondlevy

Active member
20161007_162439.jpg
Success at last! This was my third or fourth attempt to build a custom quadcopter flight controller with an Arduino-compatible board. Thanks to Teensy, I was able to prototype it on a vehicle small enough to be safe when something went wrong. Now I have a customizable flight controller with all the power of the Arduino universe at my fingertips. (The commercial flight controllers are awesome, but geared toward FPV racing, not experimental development).

Now the only remaining bug to iron out is using the Pulse Position Library. Unfortunately the bug (throttle and yaw channels swapping value intermittently) seems reproducible only with motors powered and propellers on. I suspect that the extra vibration from the props is what is causing the bug to manifest. So I am currently using my own PWM input library. This gives me clean, consistent RC input, but requires a separate wire for each input channel.

Tips for PPM input will be appreciated -- I'll keep working on it! Maybe PencileGeek's PPM library will do the trick.
 
Since those two channels are adjacent, maybe you're missing the throttle and capturing the rudder channel in it's place. However, that would not explain where the rudder data is coming from. How many total channels are you using? Does the waveform look correct on a scope when moving the individual sticks?

Maybe the data is not swapped but the throttle mixing to get yaw is not correct.


'
 
@Arctic_Eddie: thanks for the tips, but check this: unfortunately the bug is so intermittent, dangerous, and difficult to reproduce that I am inclined to switch to a different receiver type. I'm going to try using a Spektrum DSMX satellite receiver on the RX1 pin, hope the glitch will go away.
 
Sounds like motor current is causing a sag in the supply voltage. Since each motor ESC has it's own 8KHz switching rate, they would occasionally all spike low at the same time. It depends somewhat on how well the receiver 5v0 input is filtered. Maybe you can put a large capacitor on a short servo pigtail and plug it into a socket adjacent to the supply voltage input.

You definitely don't want the quad to fly off in an unknown direction at some throttle setting above the hover value. You may need to put some failsafe code into your sketch whereby if adjacent readings in time differ by some amount, or more, continue with the previous values. If the values continue to appear invalid after a few seconds then stop all sideways motion and reduce throttle to one click below hover so that it lands safely.
 
No ESCs -- brushed motors (it's worth reading the original post, if you haven't already). But yeah, it's gotta be some voltage-drop issue. Your difference-threshold idea is something I'd thought of too -- basically a low-pass filter. Unfortunately, the intermittent channel-swapping is not transient; it lasts for several seconds. So, no real way to solve it in firmware.
 
Since the fault is load triggered, a hardware solutions seems necessary. Have you tried caps directly on the motor terminals like they do in servos? You could still have a drifting sync condition whereby four identical motors turning at similar rates will have brushes moving to the next commutator segment occasionally at the same time. Also, since motor voltage polarity is constant, you could make the filter caps quick large using the type common in swtiching power supplies. The brush noise might be rather high frequency. Watching the voltage input to the Arduino with a scope might be informative. You could even set up the scope trigger for a one shot falling value just below 5v0 and catch it in the act of sagging.
 
Clever hardware idea, but weight is at a premium. Right now it looks like a faster path to success will be to try a different kind of receiver.

But since you bring up oscilloscopes: I haven't used one since college (late 1980's), and am in the market for a decent one, in order to do the kind of testing you describe. Can you recommend one with a good price / quality compromise, for this sort of microcontroller work?
 
Mine is an Owen SDS7102 but the Rigol is similar. I selected the Owen as it had a few more features but mainly a built-in, and replaceable, Lithium battery for field use. These new digital scopes are a joy to use. The screen data can be dumped onto a USB stick and imported to the PC.

There are some tantalum caps with high value and low weight. There definitely needs to be something directly on the motor terminals.

Also, the receivers having this problem likely have inadequate filtering on the 5v0 line.
 
Thanks -- the Owon SDS7102 is on my Amazon wish list!

Again, the problem goes away with an old-school PWM (one channel per wire) receiver. Also, the PPM (multiplexed PWM) receiver on which the problem is occurring uses 3.3V from the Teensy, not 5V; however, I agree with you that inadequate filtering on the RX is likely the problem. Hence I'm hoping that a DSMX receiver (also single-wire, but using UART instead of ordinary digital input). I've also contacted Curtis Fissel (a.k.a. Beef), who makes the PPM receiver, in case he has any ideas.

Which still does not address the bigger issue: What's a guy named Arctic Eddie doing in Florida? ;^D
 
Shortly after retiring in 1994, I drove from home to central Alaska every Aug/Sept/Oct for almost ten years and spent a lot of time in the Yukon gold field area around Dawson City. I'm somewhat fascinated by the mountains, glaciers, beauty of the region, and it's history. As a result, my two favorite programs on cable are Gold Rush and Life Below Zero. I've been in many of those areas so it's a little like going home to the Arctic. If you want to do something interesting, spend a day with an Eskimo/Inuit family in Tuktoyaktuk, NWT. Lunch was a real surprise, but quite tasty.
 
Shortly after retiring in 1994, I drove from home to central Alaska every Aug/Sept/Oct for almost ten years and spent a lot of time in the Yukon gold field area around Dawson City. I'm somewhat fascinated by the mountains, glaciers, beauty of the region, and it's history. As a result, my two favorite programs on cable are Gold Rush and Life Below Zero. I've been in many of those areas so it's a little like going home to the Arctic. If you want to do something interesting, spend a day with an Eskimo/Inuit family in Tuktoyaktuk, NWT. Lunch was a real surprise, but quite tasty.

Seal eyes? I-nuit!

Thanks for filling me in -- fascinating story. I have the same sentimental attachment to New Mexico.
 
The PPM signal parameters used by the STM firmware are different, e.g.:
http://www.rcgroups.com/forums/showpost.php?p=21996147&postcount=3960

Pulse Position also doesn't enforce a minimum PWM width for each channel, which the STM firmware does. Maybe, the receiver generates a glitchy PPM signal under certain conditions.

The Pulse Position PPM receive code is quite simple, it would be easy to make it behave the same as the STM version.

Thanks, tni! I was hoping someone might point me toward a solution like this. I will give it a try.
 
Not quite that surprising but very little of a whale goes unused. The part that does not end up on the dinner table goes to the dog dish.

Please keep us informed on your progress and findings. Since the new Teensies make marvelous controllers and data collectors, the sky is not even the limit. At this moment, I have a T32 in a bathroom closet monitoring temperature and humidity and sending it to the living room by a 915MHz RFM69 module. Later, it will include battery voltage, current, and consumed mAh on an 80" foam board copy of a military RQ-7B drone. Ground display is a 128x64 OLED from Adafruit.
 
That pesky breakout is cool. I'm using the Sparkfun MPU9250 breakout and the Adafruit BMP-180 pressure sensor. My project purpose is unrelated but ultimately I'm after attitude and altitude readings of sufficient accuracy and at a highest possible rate.

I've got a lot of this working in other Arduino's but I'm new to teensy (through the 3.5/3.6 kickstarter) and so I'm hoping to get some insight into your code for using the MPU+pressure.

Are you using Sparkfun/Kris Winer's library and code ? (although I just saw you've posted in the new MPU9250 library thread by brtaylor)

Did you need to modify it much?

Did you need any special libraries to access I2C on teensy?

Are you accessing the pressure sensor through same I2C bus as MPU?

Are you running I2C in fast mode (400kHz)?

TIA
 
Last edited:
Did you need to modify it much?
Thanks to some modifications that Brian (brtaylor) was kind enough to make to his MPU9250 library, I was able to use it as-is.

Did you need any special libraries to access I2C on teensy?
Nope! Brian's library uses the i2c_t3 that now comes standard with the Teensyduino distro. Worked right out of the box!

Are you accessing the pressure sensor through same I2C bus as MPU?
I have some pressure-sensor code on the back burner, but want to work on the PPM radio glitch first.

Are you running I2C in fast mode (400kHz)?
Since I am just using the defaults in Brian's library, and the library appears to use the 400kHz rate as default, I have to say yes!
 
You can push the I2C rate up to 2Mbps and higher but you'll have to watch that the slaves can respond. If everything runs fast enough at 400Kbps then there's no real reason to go higher. FYI, I2C between two Nanos will run fine at 888Kbps.
 
Since the fault is load triggered, a hardware solutions seems necessary. Have you tried caps directly on the motor terminals like they do in servos? You could still have a drifting sync condition whereby four identical motors turning at similar rates will have brushes moving to the next commutator segment occasionally at the same time. Also, since motor voltage polarity is constant, you could make the filter caps quick large using the type common in swtiching power supplies. The brush noise might be rather high frequency. Watching the voltage input to the Arduino with a scope might be informative. You could even set up the scope trigger for a one shot falling value just below 5v0 and catch it in the act of sagging.

After a few experiments, I've concluded it's a power issue, not noise issue. Evidence:

(1) RX input is smooth with five-channel FrSky VD5M (old-school PWM), whose operating voltage start at 3.0V.
(2) With VD5M, I get maybe 30 sec flight time -- suggests rapid power drain.
(3) Significant modification of Paul's PulsePositionIn code, to make it similar to STM32 PPM input code, has no effect. I.e., does not seem to be a timing issue.
(4) Attempt to use Spektrum DSMX satellite receiver showed similar behavior to FrSky micro PPM receiver: worked fine until under load with props, then failed. Being a serial protocol, the DSMX simply failed to report channel values after a certain point (i.e., couldn't parse serial messages). I also noted dimming of "talking to transmitter" LED under this load condition.

With the advent of ultra-small STM32 brushed flight controllers like the Multiflite Nano and the Quanum Pico (the latter having a built-in DSM receiver), and my lack of electronics skills & knowledge, it makes more sense for me to continue this brushed nano-copter research with one of those boards. It was fun getting my own flight controller working though!
 
Do you have an electrical schematic of how everything is hooked up? Might not be too hard to troubleshoot.

Brian
 
These are good questions and good ideas. Unfortunately with my teaching responsibilities I don't have time to do more than answer that the battery is a 1S 3.7V 750mAH lipo.
 
That's a good enough answer as a LiPo should have enough current capacity to cover surges. However, you will have to monitor the voltage with a meter when the motors are loaded. There may be enough drop that the receiver and Teensy are starved. The regulators need a little bit of margin to work correctly and you may be near that value. If the receiver is 5v0, it may already be in trouble.
 
Yeah ... I have a Watt's Up power analyzer and am planning to do some test when I have a spare afternoon. Meanwhile I note that Beef's FrSky Micro RX is rated for 3.3V, with a warning not to send 5V through it or you'll fry it. Since this RX works fine on his brushed board with 3.7V lipo and motors under full load, I have to think there's something on the Teensy that's drawing more current. Someone with more electronics knowledge than me might want to look over the BBB and see why it would draw so much less than the Teensy + MPU9250 + DC motor adapter, with the same exact battery and motors.
 
Status
Not open for further replies.
Back
Top