Propeller ActivityBoard Quadcopter
Dakota Writer
Posts: 34
Hi all. I'm relatively new to this - this is my first parallax project thread, but I know C pretty well and used the ActivityBot without a problem. Call me Dakota.
So, today I got in parts in for a quadcopter. I hope to keep use this thread to document my progress and request help along the way.
I mostly want the quadcopter to (1) fly - fancy tricks are completely unnecessary, (2) respond to commands, and (3) auto-level, if I can pull that last one off. I think I know how I'm going to it; my thanks to prof_braino and Duane Degn in this thread - my ideas have evolved since then.
The main pieces are as follows...
Quadcopter:
Microcontroller - propeller chip on ActivityBoard
Frame - probably PVC pipe
Power - NIMH rechargeable batteries
Altimeter - PING sensor (when under 10 feet up)
Navigation/orientation - 3-axis compass
Motors - my first question. Despite the advantages of brushless motors, I am pretty decidedly going for a brushed DC motor, possibly with a gearbox. I'd love any recommendations as to which motor I should choose. I already have transistors so that I can step up current from the microcontroller - up to 5 Amps output from the transistors before they burn out.
Remote:
>propeller ActivityBoard
>additional breadboard
>XBee communication module (also on quadcopter)
>2-axis joystick
>pushbuttons for altitude and other adjustments
This project is not going to be an overnight thing - probably will last into the summer.
I've already obtained most of these parts, and my remaining budget is low, so I don't want to get into the ESCs and corresponding battery / charger system necessary for the brushless motors that the Elev-8 uses (product 750-90002, I think). I wish that there was some way the propeller board could function as an ESC on the brushless motors - anyone know of any way I could pull that off? Otherwise, I really would love a DC brushed motor, possibly with gearbox, with similar specifications to the 750-90002. I would appreciate any recommendations. The Elev-8 is supposed to weigh 2.5 pounds, or so I read, so that's my goal maximum weight, and I'm using the same props.
I guess that that's all for now; I've got some physics homework to do. Anyway, thanks for checking out my project, and I'll try to keep you posted!
So, today I got in parts in for a quadcopter. I hope to keep use this thread to document my progress and request help along the way.
I mostly want the quadcopter to (1) fly - fancy tricks are completely unnecessary, (2) respond to commands, and (3) auto-level, if I can pull that last one off. I think I know how I'm going to it; my thanks to prof_braino and Duane Degn in this thread - my ideas have evolved since then.
The main pieces are as follows...
Quadcopter:
Microcontroller - propeller chip on ActivityBoard
Frame - probably PVC pipe
Power - NIMH rechargeable batteries
Altimeter - PING sensor (when under 10 feet up)
Navigation/orientation - 3-axis compass
Motors - my first question. Despite the advantages of brushless motors, I am pretty decidedly going for a brushed DC motor, possibly with a gearbox. I'd love any recommendations as to which motor I should choose. I already have transistors so that I can step up current from the microcontroller - up to 5 Amps output from the transistors before they burn out.
Remote:
>propeller ActivityBoard
>additional breadboard
>XBee communication module (also on quadcopter)
>2-axis joystick
>pushbuttons for altitude and other adjustments
This project is not going to be an overnight thing - probably will last into the summer.
I've already obtained most of these parts, and my remaining budget is low, so I don't want to get into the ESCs and corresponding battery / charger system necessary for the brushless motors that the Elev-8 uses (product 750-90002, I think). I wish that there was some way the propeller board could function as an ESC on the brushless motors - anyone know of any way I could pull that off? Otherwise, I really would love a DC brushed motor, possibly with gearbox, with similar specifications to the 750-90002. I would appreciate any recommendations. The Elev-8 is supposed to weigh 2.5 pounds, or so I read, so that's my goal maximum weight, and I'm using the same props.
I guess that that's all for now; I've got some physics homework to do. Anyway, thanks for checking out my project, and I'll try to keep you posted!
Comments
The propeller could be used to control an esc driver ic which would then drive the bldc motor. There are several schematics/projects on the internet. Google bldc motor driver and take a look.
Flight time isn't a huge factor for me, btw. I don't plan to use the copter heavily; it's a school project, and we have a good supply of rechargeable batteries.
I originally was going to control the motors via a transistor-amplifier circuit, because the propeller can't handle 4 Amps (the lower end of "maximum efficiency" for the parallax motors), but alas, that doesn't work with a bldc setup.
I'll take another look at the bldcs, though, just to see if I can manage it price/time/difficulty-wise. Until then, if you or anyone else has suggestions on any specific motors, possibly with gearboxes, that would provide torque and RPMs similar to the bldc motors on the Elev-8, I'd still really appreciate it.
Thanks kwinn.
A DC motor without a gear box produces less torque but higher RPM than a BLDC motor. It may be possible to compensate for that by using a smaller propeller. Think of it as the difference between a truck wheel and a car wheel. The truck wheel has a larger diameter so it turns at a lower rate than a car wheel would at the same road speed, but because it has a larger diameter it needs more torque to make it turn.
I might as well admit it now: I have next to no knowledge of or experience with integrated circuits. I get transistors, though. Question (1), then, is would it be possible to send the signals from the propeller board, then amplify them with a larger battery source via transistors?
With that, this project could probably swallow the cost of the ESCs from parallax, but the battery / charger system worries me. Question (2): would I need the specific batteries - LiPo 2-3S - and the $80 charger? (3) Or could I use an equivalent voltage (7.4 - 11.1 volts) and current (4-8 amp, for the motors) battery system?
Might as well ask now, too... the product page (http://www.parallax.com/product/750-90000) says this:
"> Programmable with an ESC programming card so you dont have to use your controller and count the beeps! "> 5 V BEC (Battery Eliminator Circuit)"
(4) Do I program the ESC separately from the microcontroller, or just send the pulses as I would to a servo motor?
(5) What does the BEC mean for me? Just that there is no internal battery?
Sorry that I need to ask all these (numerous) questions.... I might email Parallax about it if y'all don't know offhand. Please don't get impatient; I'm just trying to break into this wonderful world of flight.
Thanks for your very nice summary of BLDC vs Brushed DC motors. I need the torque more than the RPMs, so you've convinced me that BLDC is the way to go, if I can pull it off. I've heard that LiPo also is great, but I'd like to stick with what I have in that realm, if possible.
I don't really understand what you mean here:
You need enough torque to move the propellers but you don't need nearly as much torque as a ground based robot. You need the right combination of speed and torque. The exact configuration of motor and propeller is not a trivial task to come up with. IMO, you'll have a much greater chance of success if you use a combination that is already known to work.
What do you mean by "if I can pull it off"?
I replaced the control board on my small HobbyKing quadcopter a Propeller based control board. The Propeller board is the same size as the original control board. The ActivityBoard would be too large to use with the small quadcopter.
It's certainly possible to build a brushless ESC but you'll likely have to spend more money on parts than it would cost you to purchase a ready made unit from Parallax or HobbyKing.
A BEC is a "battery elimination circuit". It drops the main battery's voltage down to 5V. This 5V source can be used to power radio equipment and other electronics.
I'm not aware of any quadcopters powered with anything other than LiPo batteries. There's a very good reason for this. LiPos have much better power density than NiMH or other chemistries. You don't necessarily need an expensive charger to charge LiPo packs. There are a variety of charges available from HobbyKing some are relatively inexpensive. If you build a small quadcopter the batteries won't be as expensive as the packs needed to power a 'copter the size of the ELEV-8. The required charger would also be as expensive is you only needed to charge lower capacity packs.
The motors don't really care where the power is coming from. You could use any chemistry as long as the voltage is within an acceptable range for the ESCs and the batteries can deliver the needed current. You would use a lead acid or any other chemistry of battery to power the ESCs and motors. The ability of the quadcopter to fly with the added weight of these alternate batteries is a different story.
Many ESCs require some sort of programming. Programming the ESC sets parameters which best match the motors your using. You don't have to use a programming card. You can follow the directions for your particular ESC and program it from a RC transmitter. You can also use the Propeller to program the ESCs. There was a recent thread about using the Propeller as an ESC programmer. I'll find a link to the Propeller ESC programming thread and add it to my list of ELEV-8 links (I mentioned this list in the other thread).
BTW, you can get digital compasses from ebay for just a few dollars. I recently posted some code to compute the heading based on the xyz vector returned by the sensor.
Thanks for letting me know about that other thread, the one one programming an ESC from the propeller. If I understand it right, then, could I...
1) connect the ESC's three power wires to the BLDC motor
2) connect the ESC's control wires to the propeller board, very much like a servo motor
3) connect the remaining two wires to the LiPo battery
4) send pulses from the propeller, something like this:
while(1){ pulsout(pin1, 1500); //I don't recall the C equivalent of PBASIC's pulsout command, but something along this line. pause(20); }Would that alone turn the motor? If so, awesome!Thanks for all the help.
Just wondering... could it work to autolevel based on a 3-axis compass reading? I'm at about the same latitude as Idaho, Duane.
Still, if anyone knows of a light, brushed dc motor / gearbox combo that produces approximately same output as the Elev-8 motors, please let me know. (I'm still hoping!)
HobbyKing.com is your friend if you're trying to do things inexpensively, though if you're not sure what you're looking for it can be a bit daunting.
A 3-axis compass will only tell you the orientation of the magnetic field in a given location. To do auto-leveling you need multiple sensors, typically a gyroscope and an accelerometer. Adding a compass gives you the ability to hold heading, adding a GPS allows position hold, and adding an altimeter allows altitude hold. Some combination of these is often referred to as an inertial measurement unit or IMU.
Driving the motors will be the simplest of your problems.
I'm glad to hear that the pulseout (or servo32) code will work to run it, and that... I haven't used the servo32 object before... hoping that that's C, not SPIN? I just looked it up... rats, maybe not... Oh well, what are cogs for?
As far as the autoleveling goes... what if, upon startup, the compass took a reading to determine the "level" state, then used deviations from that to determine the tilt angle? Just an idea, and though I came up with it on my own, I'm not the first - see Duane Degn's thread, http://forums.parallax.com/showthread.php/155653-My-Version-of-a-HMC5883L-Object, posts #6 and #7. The math from raw data shouldn't be an issue for me.
Wind isn't bad in my area, and I'm not concerned about "drifting" after a change in velocity - thus my reluctance to go to the trouble of a gps system, at least initially.
Am I right in the ESC wiring, then? I don't want to mess that up. Does the ESC's wire pair go to the LiPo source, the three free wires to the motor, and the remaining three [connected] wires directly to the propeller board, like a continuous rotation servo?
And thanks for the tip about HobbyKing.
I would suggest you go through the ELEV-8 build to familiarize yourself with the components that go it to building a Quad Copter and the connections.
http://www.parallax.com/sites/default/files/downloads/80000-ELEV-8-Quadcopter-Info-Assembly-Guide-v1.1_0.pdf
"What if, upon startup, the compass took a reading to determine the "level" state, then used deviations from that to determine the tilt angle?"
A compass reads the strength of a magnetic field along an axis at a point in space. A three-axis compass reads the strength of a magnetic field along 3 axis. From those readings, it's possible for you to construct a vector which points toward magnetic north, but even that isn't trivial, and typically requires an accelerometer to determine the initial orientation of the compass so you know how to interpret the readings. Once you have "north" that's the only thing you know - You can tell if the craft is pointed north, but not if you're also tilted slightly to the left or right. For that you need an accelerometer, but those read acceleration as well as gravity, and are noisy in high-vibration environments, like a quad.
You really do need to use a 3-axis gyroscope to figure out your angular velocity. You use that to estimate your orientation, and then use the accelerometer and compass readings to slowly correct your estimate. This is what Kalman and Complimentary filters are for.
This video should help get you up to speed on what the issues are with the various sensors: http://www.youtube.com/watch?v=C7JQ7Rpwn2k
I agree one needs both a 3-axis gyro and accelerometer in order to have a quadcopter capable of auto leveling but I don't agree completely with limitation you state about a 3-axis magnetometer.
I've spent much of the day experimenting with a HMC5883L sensor. Once you've established the value of the initial vector pointing to magnetic north, you can use this information to figure out the quadcopter's new orientation by taking new readings from the sensor. The new heading will tell you have much the quadcopter has rotated around its z-axis and computing the new tilt value will let you know how much the quadcopter has tilted from being horizontal.
Thanks to my new program it is now trivial.
Again, as long as you give the program some sort of starting point by either starting with the quadcopter level or having the normal tilt value hard coded into the program for your location, you shouldn't need an accelerometer to figure out how much the quadcopter is tilted.
The 3D nature of the magnetic field does allow one to compute the tilt.
Again, I agree with the need for both gyro and accelerometer when trying to control a quadcopter but I think a magnetometer by itself would allow one to figure out one's orientation reasonably well. I sure wouldn't want to have to trust the magnetometer's readings when controlling a quadcopter. A magnetometer is very susceptible to noise from electronic devices which produce magnetic fields (which include just about all electronic devices). I think a magnetometer would make a useful addition to a quadcopter's other sensors but I think it would make a poor primary orientation sensor.
I noticed all the axes of the sensor are not uniformly sensitive to magnetic fields (there can be as much as a 20% difference in readings between the axes). I added the ability to add calibration constants to even out these inequalities but I also stated I was unsure if the added calibration was worth the bother since the noise caused by other electronic devices contributes more to the lack of precision of the sensor than these inequalities between the sensitivity of axes.
In my most recent project, I'm attempting to use a magnetometer as an input device. I'm hoping to use both rotation and tilt to make menu selections and to change mode settings.
So, if I'm understanding ya'll, the incapacity of the compass to act as the primary stabilizing sensor basically boils down to the extreme susceptibility to nearby electromagnetic fields - that, and variation in readings "as much as different". In theory, then, a perfect compass, distant from interfering fields, could work, right? Not that that's reality, of course.
I'll probably take a look at your compass object, Duane, even though I'm using C. (Objects, in this case, are SPIN, right?) And cool looking wallet-magnetometer project, BTW.
Thanks. I thought I saw somewhere that directly connecting the ESC to a propeller board, like a servo motor, could be dangerous... that the 5V BEC would try to power the propeller board or something like that. Just wanting to confirm: that's not the case? I was planning to run the board off of a 9-volt, for the sake of weight.
I've been starting work on the controller today, flushing out the workings of a two-axis joystick in controlling an ActivityBot. I was using xBee modules and fdserial.h. Not too complex for me, so that's encouraging.
Thanks again for all your help. Keep it up!
This is a great way to learn to use the Propeller. You can do an awful lot with a ground based robot that will apply to a quadcopter. You could try seeing if you could use a gyro to keep the ActivityBot driving in a straight line rather than relying on the encoders. You could also add the compass sensor to the mix to see how well it will let you keep the AB driving straight.
If you get your code wrong with the AB you won't end up with an expensive crash. It's much easier to crash a quadcopter than it is to fly one. You'll do well to learn as much as you can with ground based robots before taking to the air.
You will have additional things to worry about with a quadcopter. You mentioned a 2-axis joystick, usually a quadcopter uses one joystick (on the right side of the transmitter box) to control the roll and pitch; the other joystick is used to control the yaw and throttle. When using a XBee as a transmitter, make sure you can figure out how many control messages are being sent a second. A normal RC transmitter sends the position information from each channel 50 times a second. You don't want to have your control information being sent much slower than this if you want to control a quadcopter.
So, what's the best way to go about determining the speed of data transfer? I mean, the buad rate would factor in, I imagine, and that can be set as high as 115200, right? I guess at that speed data can be corrupted, which could be dangerous. What, then is the best baud rate? I'm using a baseline XBee module - 300 ft range.
I don't doubt that you know a LOT more than me about this, but why so high as 50 Hz? I can't send instructions nearly that quickly. The way I'm planning it, the propeller board on the quadcopter will handle most of the actual flight, storing whatever data I send and running off of that. For example, instead of holding the thrust at a certain level, I'll just tell it to increase or decrease via pushbuttons. Other option for that is a potentiometer-capacitor circuit, which I could easily do.
If I'm stuck with the cog solution, I'm stuck with the cog solution, but I just wanted to throw it out there in case anyone had experience with time.h on the propeller and could give me some basic guidelines (or a link to a tutorial), or knew another solution.
Thanks.
PropellerGCC provides a COG based RTC in lieu of a RTC chip like the DS1338, etc.... An RTC chip can be hooked up as well with a little more work.
Start the RTC COG with this function.
#include "sys/rtc.h"
_rtc_start_timekeeping_cog();
Get time like this.
#include "time.h"
time_t now = time(NULL);
Use linux time functions with time_t.
If you mean that it could build the timer into an already active cog... great idea!
I was hoping for a millisecond timer, with some "jitter' acceptible.
@jazzed:
Thanks. Sounds like exactly what I wanted (I think!). It'a a cog-based Real Time Clock; does that mean that it uses a whole COG to run, then? Still, it's better than what I was planning.
To you both, thanks for the pointers. I plan to explore both options, tomorrow. *YAWN*
From my reading of jazzed's post, I think the answer is yes it uses a whole cog.
You should be able to use kwinn's suggestion of adding a clock function to a cog doing something else. As long as you check the Propeller's main timer "cnt" once every 26 seconds or so, you should be able to maintain a software RTC. Of course the a the clock will only be as accurate as the last check to cnt. If you check cnt once a millisecond or so, your RTC would have millisecond accuracy.
I'm sure I have several examples of doing this in Spin but don't know of any C version of this sort of RTC.
You would also use cnt to time how often you are able to transmit to the quadcopter. And you're right, if the quadcopter is capable of flying itself, these transmissions wouldn't need to occur as frequently. If you wait until you have a program (you've written from scratch) for autonomous control of the quadcopter, it may be a long time before the quadcopter will be flying.
I personally think the approach you are taking, of writing the control software yourself without the aid of preexisting software and without learning to fly a quadcopter with normal RC equipment, is next to impossible. That's not saying you won't learn a lot in the process but I'm confident you won't have an autonomous quadcopter flying before the end of the summer if you attempt to write the control software from scratch.
haha... Got a belly laugh out of that. Seriously though, I think you are right - it's just too much, too fast.
-Russ
You can add an RTC function to another COG if you like and assign the #include "sys/rtc.h" _rtc_settime() and _rtc_gettime() functions to deal with it. I've done this with a project that uses a DS1338, but the device could be any background feature (defined in a COG for precision).
Below is an example. The GbI2C.h file defines an interface for an I2C driver that has about 5 devices in one COG. GbI2C_rtc_writeReg(...) and GbI2C_rtc_readReg(...) are the basic interface functions. All you have to do is define something similar.
It's all up to you of course ;-)
/** * @file RTC1338.c */ #include <sys/rtc.h> #include <sys/time.h> #include <time.h> #include "GbI2C.h" #include <stdio.h> // RTC year is only 0-99. Unix computing epoc is Jan 1, 1970 #define YEARADJUST 70 static time_t mytime; int RTC_setTime(const struct timeval *tv) { unsigned char ones, tens; struct tm *t = localtime(&tv->tv_sec); mytime = tv->tv_sec; /* printf("%02d:%02d:%02d ",t->tm_hour, t->tm_min, t->tm_sec); printf("%02d-%02d-%04d %d %d\n",t->tm_mon, t->tm_mday, t->tm_year, t->tm_wday, tv->tv_sec); printf("RTC_setTime Seconds = %10d TimeStamp %s\n", mytime, asctime(t)); */ /* * write rtc register fields. */ /* make sure seconds are encoded as BCD */ ones = t->tm_sec & 0xf; tens = (t->tm_sec/10) & 0x7; t->tm_sec = (tens << 4) + ones; /* CH bit is 0 by now. Should be to keep timer going */ GbI2C_rtc_writeReg(GbI2C_RTC_SECOND, t->tm_sec); /* make sure minutes are encoded as BCD */ ones = t->tm_min & 0xf; tens = (t->tm_min/10) & 0x7; t->tm_min = (tens << 4) + ones; GbI2C_rtc_writeReg(GbI2C_RTC_MINUTE, t->tm_min); /* make sure hours are encoded as BCD 24 hour time */ ones = t->tm_hour & 0xf; tens = (t->tm_hour/10) & 0x3; t->tm_hour = (tens << 4) + ones; /* 24 hour bit is 0 by now */ GbI2C_rtc_writeReg(GbI2C_RTC_HOUR, t->tm_hour); /* make sure week days are encoded as BCD */ t->tm_wday &= 0xf; GbI2C_rtc_writeReg(GbI2C_RTC_DAY, t->tm_wday); /* make sure month days are encoded as BCD */ ones = t->tm_mday & 0xf; tens = (t->tm_mday/10) & 0x3; t->tm_mday = (tens << 4) + ones; GbI2C_rtc_writeReg(GbI2C_RTC_DATE, t->tm_mday); /* make sure months are encoded as BCD */ ones = t->tm_mon & 0xf; tens = (t->tm_mon/10) & 0x1; t->tm_mon = (tens << 4) + ones; GbI2C_rtc_writeReg(GbI2C_RTC_MONTH, t->tm_mon+1); /* make sure years are encoded as BCD */ ones = (t->tm_year-YEARADJUST) & 0xf; tens = ((t->tm_year-YEARADJUST)/10); t->tm_year = (tens << 4) + ones; GbI2C_rtc_writeReg(GbI2C_RTC_YEAR, t->tm_year); return 0; } int RTC_getTime(struct timeval *tv) { struct tm t; /* read all rtc registers */ GbI2C_rtc_readRegs(); /* get rtc register fields */ t.tm_sec = GbI2C_rtc_getReg(GbI2C_RTC_SECOND); t.tm_min = GbI2C_rtc_getReg(GbI2C_RTC_MINUTE); t.tm_hour = GbI2C_rtc_getReg(GbI2C_RTC_HOUR); t.tm_wday = GbI2C_rtc_getReg(GbI2C_RTC_DAY); t.tm_mday = GbI2C_rtc_getReg(GbI2C_RTC_DATE); t.tm_mon = GbI2C_rtc_getReg(GbI2C_RTC_MONTH)-1; t.tm_year = GbI2C_rtc_getReg(GbI2C_RTC_YEAR); t.tm_sec = ((t.tm_sec >> 4) & 7)*10 + (t.tm_sec & 0xF); // bcd conversion t.tm_min = ((t.tm_min >> 4) & 7)*10 + (t.tm_min & 0xF); // bcd conversion t.tm_hour = ((t.tm_hour >> 4) & 1)*10 + (t.tm_hour & 0xF); // bcd conversion t.tm_wday = t.tm_wday & 0x7; t.tm_mday = ((t.tm_mday >> 4) & 3)*10 + (t.tm_mday & 0xF); // bcd conversion t.tm_mon = ((t.tm_mon >> 4) & 3)*10 + (t.tm_mon & 0xF); // bcd conversion t.tm_year = (t.tm_year >> 4)*10 + (t.tm_year & 0xF); // bcd conversion t.tm_year = t.tm_year + YEARADJUST; mytime = mktime(&t); tv->tv_sec = mytime; tv->tv_usec = 0; /* printf("%02d:%02d:%02d ",t.tm_hour, t.tm_min, t.tm_sec); printf("%02d-%02d-%04d %d %d\n",t.tm_mon, t.tm_mday, t.tm_year, t.tm_wday, tv->tv_sec); printf("RTC_getTime Seconds = %10d TimeStamp %s\n", mytime, asctime(&t)); */ return 0; } void RTC_init() { int t; /* make sure clock is enabled */ t = GbI2C_rtc_readReg(GbI2C_RTC_SECOND) & ~(0x80); GbI2C_rtc_writeReg(GbI2C_RTC_SECOND, t); /* make sure we are using 24 hour time */ t = GbI2C_rtc_readReg(GbI2C_RTC_HOUR) & ~(0x40); GbI2C_rtc_writeReg(GbI2C_RTC_HOUR, t); _rtc_gettime = RTC_getTime; _rtc_settime = RTC_setTime; }What I was trying to communicate is that I want the craft to hover by itself, waiting for me instruction, therefore minimizing need of input from an inexperienced user (me!). And for that, I was wondering why I'd need to communicate 50 instructions per second. I don't doubt that there may be a very good reason, I was just curious what that was.
With that, I'm planning the X-configuration: two props leading the charge when moving forward. I know that to make the quad move laterally, I should tilt it (I don't know how far) by decreasing the leading two props and increasing the back two. After that, if I equalize the outputs from the motors, will the craft continue with forward acceleration, or will it level back out?
Once again, let me thank you for humoring my DIY nature. If it turns out that I can't code it myself, I'll most likely fall back on others' code.
Would a C Library be equivalent to a SPIN Object?
Thanks for your continual support, and for humoring my perhaps unrealistically independent plan, while it lasts.
If you know the short answer to these questions and don't feel like writing out the long one at present, please just post the short answer for now. I want to order the "final" parts soon, and have two main questions that still need answered...
1) Batteries: I found out that LiPo batteries, for all their power, are very dangerous when charged incorrectly, dropped, punctured, overused, etc, etc, etc. Anyway, since I don't have anyone local to instruct me, I was wondering if anyone has had success with, and/or could recommend, an alternative battery that's simpler and safer to charge - especially a NiCad battery pack, as these have a high discharge rate. Nimh is fine, though, if there's one that fits the bill. I just don't want to be responsible for the power of a touchy LiPo pack. And, I know, with caution and experience they probably aren't as dangerous as they seem, but this page left an impression I won't soon forget. Any advice?
2) ESCs, again. Thanks, Duane, for mentioning that page on programming the ESCs from the propeller. My question here is twofold, and probably the answers are pretty easy. First, do I absolutely need to program the ESCs before using them? I imagine that the answer is yes, but I'm hoping that I can just plug it in and start sending pulses to it. Second, the ones on the parallax website contain a Battery Eliminator Circuit. Will that try to power my propeller ActivityBoard when I hook it up like a continuous rotation servo? Because I can't imagine that that would be good on the board, especially if it is already getting power from a 9-volt.
I'm still interested in answers to the questions I posted earlier, but these are now the more pressing, as I need to get in the parts before school lets out. Thanks in advance.
It may be possible to power a quadcopter with non-lithium cells but I haven't heard of it being done. I personally have never had a LiPo catch fire. I always use a charger with a balancer when charging my packs. I also use a "LiPo Bag" which is a fire resistant bag made to help contain a fire/explosion from a LiPo. HobbyKing sells these bags at a reasonable price.
I never charge batteries through the night (LiPo or NiMH). I never charge them when I'm not around to check on them.
I don't know what the negative effects of not programming the ESCs. You should be able to program the ESCs with the ActivityBoard using a program Roy Etham adapted for the Propeller. It was a recent "Open Propeller Project" (IIRC #4).
You can pull the pins from the three pin connector on the ESC. The first time you pull a pin it's a bit tricky but after pulling a few you'll get the hang of it. You start out by pushing the wire all the way into the pin housing and then with a small tool lift the plastic tab holding the pin in place (preferably without breaking the tab). With the tab held up the pin should be able to slide free of the plastic. I put a bit of heat shrink tubing over the pulled connector so it doesn't short against another pin.
An alternative to pulling the pin from the ESC would be to remove the power jumper from the AB. This should keep the center pin from connecting to the rest of the board though it will still connect to other items plugged into the servo connectors of the AB.
Wow, if just removing the power jumpers will accomplish the goal of ESC connection to the ActivityBoard, I'll go with that!
I'll probably program the ESCs with that AB program to eliminate the cost of the programming card, like you suggested. Would it work to program them with the jumpers removed, as you described? Or would there have to be other hardware alterations?
And thanks for the advice about the LiPo bag. I can probably get that done... even, if the day is nice, charging outside (just making sure that the dog is in!). Any particular brands that I should steer clear of when ordering a charger and/or battery? And I can cross-brands, right? So long as it's a balance charger and a LiPo battery?
Along with that, I see parallax sells a cheap USB LiPo charger. Would that work? It doesn't mention being a balance charger, so I doubt it.
As usual, many Q's and few A's. Safety is kind of important to me - last thing I want to do is blow something up accidentally (which, with LiPo, seems like a real option)! Thanks for the hundredth time.
I'll let you look up what the "C" rating means.
I noticed a lot of my packs are Turnigy brand. They seem to work okay. If you can find a pack at HobbyKing's USA warehouse, the shipping will cost less and the battery will arrive sooner.
If at all possible, don't just get one pack.
There are lots of cheap single cell LiPo chargers. but they're generally used on batteries powering low power electric devices.
The power wire coming from an ESC is a 5V supply from the "battery eliminator circuit" (BEC) which is typically just a regulator or two. If your activity board has power supplied to it already, there's no need to have those connections as well. The only reason you might want them is if you intend to "stick program" the ESC from a normal receiver. That receiver would need to be powered, which you could do from the power line on the ESC, or with an external receiver battery.
Regarding the charger, the Tenergy charger that Parallax sells would work for you, but the $10 USB charger would not. That one is only for charging single cell packs, and for a quadcopter you're likely to end up using 3 cell packs (12v).
If you want something decent that won't break the budget, check this one out: http://www.hobbyking.com/hobbyking/store/__6478__IMAX_B6_AC_Charger_Discharger_1_6_Cells_GENUINE_.html
It works on AC or DC power (many lipo chargers are DC power only, requiring a separate power supply, or a car battery), and will charge, balance, or discharge anything you're likely to use for quite a while.
Something like this, then? Maybe with one of the topmost three (Turnigy) chargers on this page? The chargers say that they require a 12v source; I assume that a cheap wall adapter could supply that?