Hi!, I hope IanLee74 or anyone else that’s using the Plush ESC in combination with FEZ can help me :P. Reading the manual of the ESC it seems that I need to connect the ballance cord of the accu to the ESC as well, connect + and - and the “receiver”.
However, I have 4 engines / esc’s and only 1 battery (perhaps 2), so only 1 or 2 balance cords. I also don’t have a receiver but want to controll the speed with PWM (FEZ / XBee will be my receiver).
Do you need to reprogram the ESC?
Is is possible to have the balance cable disconnected (I think so by reading the manual)?
What are the cables you could connect a PWM pin to?
And what frequency should I use for the PWM?
And…, I thought the ESC had an power out as well to connect the microcontroller on to. I don’t see that within the manual. How do you power the FEZ with the same battery?
I don’t know why the ESC would want the balance cable attached, unless it is detecting unbalanced cells and trying to protect against that? Not sure that I would worry about that unless the ESC won’t arm without being able to detect the individual cell voltage. (Personal thought: when discharging, balance is less critical than when charging)
Powering your uC with a “power out” of the ESC / BEC is possibly not a good idea. Engines draw large amounts of currrent and will cause voltage sag, so personally I would try to minimise the potential for impact there and avoid using the same power source. If you’re using 3S and regulating power down to 5v for Fez, you may get away with it (that may change over time as the battery response changes). I don’t know if there is any common way that ESCs provide power-out, but I would try to tap directly to the battery and not via the (poorly) regulated output from the ESC, which means you will need custom cabling.
The “reciever” line is essentially the PWM output from your Fez. Make sure you ARE sharing GND if nothing else !
@ mammaplank - Glad you enjoyed the article. I’ve gathered a lot of good new info in the past week working with my quad that I hope to add to that post before the end of the weekend. So, you may want to read over it again early next week.
Most ESCs have a built in BEC, which in the RC world means Battery Eliminator Circuit… specifically talking about eliminating the need for a Receiver Battery to power the RX and servos.
The output on the ESC’s 3 wire servo lead is regulated, normally at 5v, and if it’s a nice one with a switching BEC you can vary the voltage for faster servo operation.
The balance leads off of LiPos are used solely for charging. People do sometimes use them for other things, like powering LED strips for night flying aircraft… but they were only intended for charging.
From the manual: You MUST conect the adapter with the balance charge connector on battery pack BEFORE conecting the main power to ESC. And if you use banana-shape connectors on main power wires (input wires), please connect the black wire (negative polarity) BEFORE red wire.
Later on it explains that it is using the balance wire for balance discharge monitoring and protecting function. It seems to be able to reduce the output power gradually if it detects a low battery.
It also I’ve also read that the engine power can be set from 1ms to 2ms (0 to full power) using PWM but it needs to startup at 1ms otherwise it will enter configuration mode.
If I receive my FEZ power from the ESC the ESC will allready be active before the FEZ started up. I probably don’t want that as well, in combination with the possible instable power source from the ESC I will probably add another battery to power the FEZ / Mongoose.
@ Brett: “Make sure you ARE sharing GND if nothing else !”. How should I do that? Should I split the negative polarity cable from the 3 cell battery and the 2 cell negative polarity from the FEZ battery and connect them both to FEZ ground? Will that be sufficient?
@ Ianlee74, I’m looking forward to read your new posts.
Every ESC i have come across enters programming mode when you power it up and it receives a 2ms signal. If it receives no signal or does not get 2.0ms then your safe. it will not go into programing mode.
ESC’s have a boot up time of about 2-3 seconds. During which time they will beep how many cells you have. I.E. 1-beep for 1 cell, 2 beeps for 2 cell and so on. At the end of the beeps it will check for a 1ms signal. If higher than 1ms or no signal the ESC will not arm. If there is 1ms signal then you will hear a final ARM confirmation beeps.
So, if the processor your using takes longer to initialize and squirt out the 1ms PWM signal than it takes for the ESC to start up then you will have to power your uP first before the ESC.
If you have multiple power sources, you just need to make sure that ALL the GND wires from all those sources are connected together. BLK wire from battery 1 connects to the BLK wire from batt2, BLK wire from anything else connected to BLK wires. So it’s important to make sure somewhere in your circuit the GNDs tie together
Gus, I assume you’re talking about building an IMU. I’m using this one. There’s certainly nothing difficult about it - just a serial connection. If you’re thinking of building an IMU module then my first request would be multiple interfaces (SPI, I2C, & Serial).
That’s what I’m trying to do… Right now I’m still trying to get the roll data under control then I’ll move onto the others. The data from the IMU isn’t hard (minus the normal difficulty of reading serial data). Getting a tight enough loop in NETMF to make it useful seems to be the challenge so far. I haven’t narrowed it down yet but there seems to be more than GC going on that causes interruptions. If I just run something as simple as this code:
while (true)
{
_propellors[2].SetPower(20);
Thread.Sleep(1);
_propellors[2].SetPower(60);
Thread.Sleep(1);
}
It produces no GC. However, you can tell audibly that something kicks in and causes interruptions to the rhythm at random times. Any ideas? Also, I have some questions about Sleep() but I’ll post that to a new thread.
@ JDAL, Tnx! Think FEZ needs about 2-3 seconds to boot and load so that would be tricky. I will power the FEZ with its own battery and startup FEZ before the ESC’s.
@ Brett, Tnx, I will remember this.
@ GUS, Mongoose is allready returning degrees for yaw, roll, pitch and the temperature / double. Isn’t that allready the usefull data you need?
@ NewQuestion: I’ve created a new thread that is listening to the IMU (serial) and sets all values within a static class. My PID loop class can now read the actual values from IMU, but also from another thread that sets the ultrasonic height.
I’ve set the priority of the IMU listening thread belownormal (and my PID thread high).
Somehow it is allready generating a lot of GC call’s and I can’t actually explain why (there is no disposing, all variables are private / static and will not need disposing as well). The IMU is raising a lot of data events but I don’t see anything the GC should clean up. However it is doing something that takes 2ms each run. I start to think the GC fires after an event is raised a lot of times or so.
I’m now thinking of connecting the IMU to I2C and only get the latest values when needed. Any ideas why the GC would fire this often?
I assume this will work fine as long as the range finder is beaming down in a straight line. If the quad is within any angle this could return bad results. This is why I’m thinking of hanging the range finder below the quad on it’s wire with a little weight on it pulling it down and forcing it to face the earth in a straight line. Would that be a sane idea? Or is there a better alternative? I know this would be a problem if my quad would ever start performing loops.
@ mammaplank, i dont think it’s a bad thing that it takes 2-3 seconds to boot. The reason is that while its booting the PWM pins are dead until initialized right ? If so, then there is nothing to worry about. The ESC just wont arm itself. So once booted, and you send the 1ms pulse, it will then arm itself and be ready.
Tnx JDAL! But I’m not sure if they are dead. I’ve created a robot first with a motor driver controlled by PWM from FEZ. During startup of the FEZ it started driving at 100% speed, until FEZ initialized and set the PWM to 0. I did fix that with a pull-down resistor so indeed I guess that could work here as well.
If you dont have a scope, you might try slapping a servo there to see which way the servo swings when booting. If the ESC thinks whatever the PWM is doing during boot is >1.8ms signal, then yea that is going to be a big problem as it will want to go into programming mode.
I think it’s quite impossible that you’re reading & parsing serial (string) data and are not using any new memory that needs to be GC’d. Remember that strings are immutable in NETMF. So, even if you are using static string variables they are still using new memory every time you change their values. Also, the memory to store the parameters for interrupt events are not free either. So, it is quite normal that you are seeing lots of GC’s once you start parsing the serial data. This is a big part of what I’m also battling with at the moment. Rarely have I ever said to myself that I miss C, but this is one case where it would be nice…
So, have you achieved a stable hover and are moving onto maintaining height or are you tackling this all at once?
;D, you are right about that. But 2ms that is this often lost to GC is a lot. I’m switching to a way where I can pull the current readings out of mongoose within the pid loop (at the time I need them) and stop the mongoose from spamming FEZ with all of this data that will most probably not be used 80% of the time.
I’m still waiting for my new engines and some other stuff to come in, so I’m continuing programming without any ability to test the program yet. I do hope to have a program that “should be ok theoretically” within 2 weeks (hover and maintain height only with framework to receive xbee commands, etc). Hopefully the rest of the orders arrive soon after that as well.
@ mammaplank - Have you tried any interfaces other than UART with the Mongoose? It also supports SPI & I2C. I think my next step will be to convert over to SPI and try polling rather than dealing with the serial data stream. However, currently, I’ve backed up and am testing with just hard-coded numbers to convince myself that given a constant loop with no GC that it will indeed be constant. Not looking good so far. Unfortunately, my scope is only single channel and this is making it very difficult to see exactly where the issue originates.
Yes, I’m trying to change from serial to SPI. I believe they are making a lot of process on this within the multiwii platform (Mongoose 9DOF IMU with BMP085 - MultiWii). I’m going to try and read that code to see how they implemented SPI on the Mongoose because i’m not having any luck myself yet (okay, also did not have enough free time for this fun stuff lately). Ckdevices is also not really answering your question on this part as well
Specially interesting idea from that multiwii site (written by ckdevices, so I guess they should have this code as well):
Another idea would be to use the SPI port to transfer data between the Mongoose and the main controller, with the main controller being the SPI master. If the transfer was done as binary (instead of ASCII) this would be very fast and allow for lots of savings on the processor bandwidth on the main controller as compared to polling all the sensors over I2C as is done in most setups. I think all the data could be sent in about 40 bytes and if the SPI was running at 4MHz, the compete transfer would only take about 100usec. This is at least 10 times faster than if the main processor was to poll all the sensors over I2C.
Right now I’m still trying to get the roll data under control then I’ll move onto the others. The data from the IMU isn’t hard (minus the normal difficulty of reading serial data). Getting a tight enough loop in NETMF to make it useful seems to be the challenge so far. I haven’t narrowed it down yet but there seems to be more than GC going on that causes interruptions. If I just run something as simple as this code: