My goal is to have the heli RTL when the signal is lost. Since the ESC is directly connected to the receiver, when signal is lost, the ESC would power down. Anyway to get ESC to be controlled by the APM2? My plan is to have the ESC running in governor mode to have a fixed throttle. So APM2 doesn't really have to have any variable control to it. More or less like a toggled signal.
The configuration stuff is mostly done in APM_Config. You also have to declare your APM2 there as well.
Oh, to reload the original code, you can just use the upload from MP. If you really mess things up, you might need to do a factory reset and/or erase the EEPROM. Both of those are done in CLI.
You should have a poke around the CLI stuff (done through MP) to get familiarized. There's a few things you can do there that you can't do in the GUI.
Ah!! I see. Thank you.
Hmm... I just noticed that I suppose to use the "mrelax" version of Arduino. After I do that, my Visual Studio (VS) no longer compile. It compiles just fine using arduino.exe itself though. VS must have gotta confused somehow...
Sorry, I can't help you there. As I said I found VS a little too heavy for me, a bridge to far. It's certainly very powerful, but I just can't take that on along with figuring out the program.
Well, one solution is to set up your receiver failsafe to hold the ESC on. I've done that.
But, I am actually working on doing exactly what you are asking for. Hopefully the feature will be out in the next week or so. Whenever the next release happens.
Do you have any input into nitty gritty details of how you want it to work?
So far, I have planned to only be able to feed a governor controlled ESC. The signal that is sent will be a parameter in MP, so you can change it on the fly over telemetry. You will also be able to do Ch6 Tuning on it, the same way you can for the Ext. Gyro Gain.
The ESC signal will be zero whenever you are Disarmed, so you will have to use the Arming proceedure. Even then, however, the ESC will only be switched on when the collective stick is raised off the bottom, so it's a dual safety. This is also required to allow the pilot to stop the motor before doing a disarm, since a disarm requires full down and left stick, it would result in the heli pushing down hard and trying to yaw.
So the intent is, the user will have two collective pitch curves, normal and idleup 1 or something. They will be identical, other than the bottom of idleup 1 will be just a smidge higher than normal mode. So you boot up in normal mode, and arm. Then switch to idleup1 which raises the collective command just a touch, enough to signal the APM to turn on the ESC. The heli will spool up, and away you go. When you land, switch to "normal" and drop the stick which will shut off the motor. Now, I just realized that this causes a bit of a hiccup because you'll still be required to push the heli into the ground, at least momentarily, to shut the motor off.
The only other way to do it is slave an input channel to control the ESC permanently which... isn't much better than just running the ESC direct from the Rx anyway.
I've already been doing the Arm/Disarm procedure already, since I do want the logs (consistently). What you are planning to do sounds like a very good solution.
One problem with the arm/disarm has always been seeing those tiny little LEDS. I've got a solution to that problem, I just have to finish making it work on APM2. This is "CopterLEDS" funciton.
There is a row of pins on the side of the APM2, and you can plug these DIRECTLY into them to be driven by the APM2.
Sweet! Can't wait for the CopterLEDS function! I already have a bunch of those LEDs from hobbyking.
My heli is night flying capable. Fully lid with green on right and red on left, along with blinking white LEDs. I opted for the 12v sticky ones for lower profile and much brighter light. I still have room for the LEDs for CopterLEDS. :D
Oh my, you've got a lot of stuff on that heli! rock on. :-)
It's got some align parts but it looks pretty alien to me!
Went through the codes for hours last night until 6am. Very sleepy... But it gave me lots of idea to improve so many things. :D
Anyway, first thing I'll do is to make Ch7 passthrough to one of the output port (when Ch7 is not assigned to a function) since that's what I expected it would have behaved. It would be more like a small step practice exercise. Also adding Ch6 (or Ch8) as another passthrough port. I could connect ESC through it and have the actual throttle input from the receiver like it suppose to.
Next small step would change that channel to work only when the heli is "armed".
Then, next is to add one more function for Ch7 and call it H_EnableFailSafe and it would be used just for Heli. When the Ch7 toggle is at low, it works like before as a passthru but only enabled when "armed". When it's high, the FailSafe is enabled and it'll tap into the existing APM FailSafe code. The existing FailSafe code would kick it when the Throttle fall to a certain level and the distance is over 1000m. The existing FailSafe code should work fine execpt it needs to add a conditional check that when it's for Heli, set the Ch6/8 to a set amount of throttle for the ESC. That amount could be a parameter later set from the APM planner.
After that, I might change the existing fail safe code to fly the heli at a flat higher altitude until near the RTL location then lower to a lower altitude and even landing. Since plane can't land vertically but heli can, I thing it's a better way for Heli. For me, it would crash into many tress before get back to my RTL point if it fly straight like a WP. :D
Ultimately, I'll target the landing code and make it possible for a heli to actually land. The key is to check the change of the altitude rate and don't let it move too fast. Even the target altitude is way down, when heli fail down fast, it would be tough to slow it back down to hover. It's better to control the decent rate. My last crash would have been avoided if there is such check.
Too many idea. lol. I wonder if I can even make it pass my first goal. lol.
Oh, btw, got the Visual Studio working again. I downloaded the 001 relexed version which is the oldest beta code ever. That's why it broke it.
The non-relaxed one I got was non-beta version 1.0. Do I really need the relaxed version since the ArduCopter.dpe build just fine.