I have just bought the ArduPilot Mega 2560 Full Kit... plus the Triple Axis Magnetometer HMC5883L. I should have it built over the weekend.. then i'm off to a my mates machine shop, and i'll make the splitter plate for the lower frame onto which i am going to fit the Ardupilot. the magnetometer i'll put on the tail as suggested. I am going to use my X-cell Razor 600E. For those that dont know its around the 50 size nitro heli.
Do i need to buy any other sensors i.e. the Sonar... i can fly a helicopter all day long but this is my first time flying one with stabilisation so any tips would be gratefully appreciated.
If this works well then i am going to try and use it on my x-cell gasser. i can get up to 20 minute flights with this. But i think for the time being a battery 600 is the way to go.
i'll post some pictures when i have it all together.
So you have two outputs from the BEC, going to both sides of the servo rail, with the servo rails split. I get that part.
Why I'm confused is that I thought you needed to leave that solder jumper for the APM 5V power in place in order to supply power to the APM from the servo input rail. I thought the only time that you unsolder that jumper is when you are going to power the APM directly via the MIC5219 and an external power supply.
Let me put this another way:
My understanding is based on these pages which are the best info I can find to date:
I already know these are out of date as they are based on the APM1280, not the 2560. Most importantly it talks about a 1A limit on the LM317, but the 2560 has the MIC5219 with, at best, a 0.5A limit. In fact the limit is much lower, more like 0.2A if you are using a 2S input battery as suggested in the wiki.
I think this whole situation is just wrong. That wiki needs to be updated. The whole idea of powering the APM board from the MIC5219 is... basically impossible. I'm not even sure why that chip is on there, or why anybody is talking about powering the APM through the external power port. You can do it if, and only if you are ONLY running an APM, with no sensors, possibly not even the IMUshield, and only if you are running a low voltage input like 2S, definitely not 3S. The chip is rated at 12V input, but it can't disipate enough heat to power even the APM like that.
But, if you're not using the MIC5219 it's a moot point.
It looks to me (assuming the 1280 board layout is similar to the 2560) that if you are back feeding power from the input rail to the APM board chips, you have to leave JP1 soldered. The power rail for the servos is called 5V!, and it is connected to the 5V system on the board via JP1. If you unsolder that, how is power getting to the board?
It appears to me as if most of the chips on the board are powered by Vcc, which is linked to the 5V line through the 500mA fuse F1. The fuse is supposed to protect the LM317 chip from the servos drawing too much power, but in fact in this case it is doing the opposite. If the board draws more than 500mA it will trip, shutting down the APM, but not the the reciever. It's probably OK like this, but I do wonder...
Now, how does power get to the shield? I believe it gets 5V and not Vcc, but I'm not 100% sure.
So, how are you powering the board if you unsoldered SJ1, and don't have external power to the MIC5219? You must have left that soldered and I misunderstood what you wrote.
Just thinking about the power hack again, why do you even need to run that wire from the 5V pin to the servo rail? If the jumper is left in tact as it must be, the rail should already be powered by the 5V trace? Or are there multiple 5V traces in the board?
As you noticed, the power-hack includes soldering a little wire from the left side of the servo rail to one of the 5V pins on the APM. So it's much like the jumper..maybe if you leave the jumper in place it feeds from the right side of the servo rail which wouldn't be good...not sure to be honest but I expect jason would have used the jumper if it was possible.
I see it now.
First of all, in Jason's Power Hack post, it does not mention unsoldering JP1. I'm not sure why. Regardless, that does appear to be necessary.
The reason is because the 5V! line comes from JP1, and then goes into the Servo Out rail first, then it goes to the Servo In rail. When you cut the trace between In and Out, it leaves the Servo In positive rail "orphaned", no connection to anything. However, the Out rail is still connected to 5V!, and thus 5V through JP1. That is why you must remove the JP1 solder jumper. This now leaves the Servo Out rail orphaned, and free to be powered however you like. But, the Servo In rail needs to be connected to something, which is why the wire is connected.
Now, I do wonder if there's a reason Jason chose to use the 5V pin on the opposite side of the board? There's another 5V pin on the same side of the board as the Servo In side. It's located in the FTDI pin header area.
I may have actually answered that already. That pin is labelled 5V on the board, but I believe it is actually Vcc, which means it's on the other side of the 500mA fuse from 5V. So it might be a slightly bad idea to use it. But I'm not sure. Maybe it wouldn't matter.
BTW, you might want to look into this problem:
This might be the actual cause of your blackouts. I don't know for sure, it is strange that one of the times you mentioned, the heli stayed in the air and you had to bring it down with throttle. But the instance in your video (http://vimeo.com/32722979) sure looks like it may have been the I2C lock-up.
I'm grounding my heli until this is fixed.
Yes, I'm following that thread as well.
I'm 100% certain that my black-outs were caused by the ppm encoder and it's low voltage weakness. I was eventually able to reproduce the problem multiple times using a smaller battery and then after upgrading, it was gone! :-)
I might give Jason a hand with that if nobody jumps in and sorts it out, the only thing holding me back is I'm doing a demonstration of the heli at make-fair tokyo this weekend.
It's worth noting that if your hardware is fine, you should never see the i2c lock-up problem. I'm been flying for ages without seeing it. Also it's an issue with the Arduino library itself, nothing to do with our code. I'm not saying it's not an issue but it's always been there lurking...
Been out of the loop for a while (though checking in every day) and thought I'd share the progress - still waiting for the enging but that is no longer major hurdle as I have paid for it, all I have to do is pay for shipping and then the magic will be happening (by magic, I mean the tuning and flying of the arducopter will begin)
Very interesting. Can I get more pics of the camera mount system please? Is that custom? Is it cantilevered off the roll servo? Supported only by the servo bearings?
Servo on the tail? Why did you wrap the wiring around the tube like that? The head looks interesting too.
Made some progress on the weekend.
I removed the shielded cable I used for my tail servo, and replaced it with simple twisted servo wire. But instead of running the ground and power direct to the battery, with only the signal wire going to the APM, I put the ground and signal to the APM, and only the power wire directly to the battery. I also added a large 4700uF cap glued directly on the back of the servo. This appears to have fixed the problem! I have no noise at all from the Xbee.
I'm not really sure why this worked, as there really isn't anything, no resistance of voltage drop, between the battery ground and the ground rail of the APM. So it shouldn't matter, but it appears it does make a difference.
I also made my own capacitor bank for the APM. It's 5x4700uF caps soldered together. It helps for sure. I can actually flick the power switch on-off-on very fast and the APM does not reboot. You have to do it FAST, but it works. Also, the servos are drawing on the cap bank as well. I'm sure once I split the servo rail from the APM, it will keep the APM alive even longer.
I've checked in those changes to fix the slow roll/pitch updating. I haven't updated the version coming out of the ap mission planner yet until I have a chance to check the alt hold again.
I'm pretty sure the sudden climb issues that marianne was seeing (and i also saw recently) were caused by a high I value on the throttle rate. I think what is happening is sudden negative spikes (which happen often if you have a noisy sonar due to an uneven power supply) in altitude from the sonar would cause the I term to build up and these would overpower the P. That's my guess at the moment (more testing this weekend).
It looks like the diydrones store has sold out of trex mounting plates so I'll send some more in. The mounting plates fix the APM2 as well by the way although I have not yet flown a heli with the APM2.
What do you mean fix the slow roll/pitch updating? Is my the yaw stability patch included?
When you say checked in those chanages, that's in APM, or the download section?
When I modified the collective pitch scaling (so that you can better control the collective pitch when in stabilise mode), it also affected the roll/pitch. I didn't like this because it meant that modifying the collect pitch range would lead to you having to modify your stabilise's roll and pitch PID values. Basically, if you load the latest code, you may find that your roll and pitch is a bit more responsive than before.
Yes, the yaw stability patch is in there. It's slightly different than you provided but not much and in either case the behaviour is the same.
These change are in git only...I can update the APM's version too if you'd like. Trunk seems ok according to the simulator anyway.
So is this strictly in GIT, or can I get it from downloads? Looks like the last thing checked into downloads is Arducopter 2.0.55_Alt_Hold_Patch 3 days ago, so I don't think that's your latest changes.