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.
Yeah, I tried some Loiter today and had some VERY weird results. Basically, it kept shooting off to the right, looked like it was going to roll to 45° if I didn't stop it. I don't get it. I tried it 2-3 times, and it kept going hard right, like it was on a mission, but it was loiter.
I ran across the likely cause of this today. There was a #define AUTO_RESET_LOITER previously that would allow you to turn on/off the functionality to make manually changing the roll/pitch reset the loiter target to the current position. That switch is gone now so it will always reset the loiter position if you move the (roll input + pitch input) > 5 degrees. At that point a loiter_override flag gets set on and you can only unset it if you get your roll and pitch input exactly back to zero. I suspect that if you look at your roll and pitch values, they're not quite zero so you can't get out of this mode. Try making your roll and pitch dead zone bigger (RC1_DZ and RC2_DZ) a little bigger and it will probably start working again.
It's possible to make the code a bit more forgiving as well...for example we should almost certainly switch that loiter_override flag back to the default position (false) when you disengage and reengage loiter.
The code in question is here.
Yes, that would make more than sense. Think about guys using subtrim at the TX. I think that was the reason why I never hit zero on roll and pitch again.
However in the version before, using trim at the TX never played a role. The loiter logic with that flag must have changed then from former version to 2.4.
Where does the logic count "zero" from. Absolute zero of ROLL and PITCH IN or relative to where I started up the APM? Maybe before it was don on relative basis.
I imagine zero comes from your radio calibration.
You really never should be using your trims with AC anyway.
I did another 2 flights today with 2.4.2 from ~Monday.
Great news about the yaw improvements. Did you say the collective yaw compensation was backwards (i.e you needed to put in a negative value?). The truth is I took a guess when I first implemented that (and you've fixed two other bugs since). Happy to reverse the direction if you'd like (or you can do it yourself I suspect!).
The 2.5 release is only 1 hour old but I've found and fixed a small bug in the loiter control which would affect the speed calculated when loiter is first engaged. I have no idea if this is related but maybe.
P.S. I had somehow must have clicked the "stop following" button to this forum so so I fell way behind, sorry!
Randy, I'm now using a positive h_collyaw value after I fixed that bug. I think it's now going in the right direction. Positive gives me right rudder. So that's good.
A big part of it being "backwards" was that it didn't work right at all, and I just didn't understand that yet.
Overall the yaw is doing really well now. Much more confidence inspiring. Having the coll-yaw working reduces the need for I-term, since the tail moves automatically even with hover collective. I don't have to even think about the tail much anymore.
Oh, and 2.5 has been released, it's in the Mission Planner now! I'll try it tomorrow.
Unfortunately it is raining today. I really would like to do some loiter tests. Maybe it clears up later.
Thanks Randy, that loiter DZ story and my subtrim seems to have been the right solution to my loiter mode problems from yesterday.
But guess what. Now I am having the GPS red solid light problem again ;(
What does it mean if already on startup the red light goes not to blinking status, but goes off completely?
Usually it goes to blinking and then as soon as the GPS has a lock it goes solid red. I tried to narrow the problem and found out that already on startup the red light goes off. But as said, the GPS is working and goes solid blue after a while, but as the red light is totally off, I have no chance to get a GPS lock status and let it change to solid red.
Is there a problem with the automatic GPS recongnition at startup?
I have the feeling the APM does not correctly recognize the GPS and thus turn red light off assuming there is no GPS. But the GPS gets power and is running, thats why I see it goeing solid blue after a while
Ok. It is really an issue of detecting the GPS. In the case of no red light at all, the MP reports "no GPS". In case of a blinking red light is reports "no fix".
Did the GPS identification process change recently? Like I said, the issue was not there in 2.1 and former versions. It believe it is very unlikely that something to my GPS or connection happend. I believe it is more a code thing. Did the timing change? Maybe the GPS reports back to late. The time window became too small? Anything?
Yes, that sounds like the same issue.
We really haven't touched that code much in a while. The only thing i remember us doing any time recently is changing the update rate from 10hz to 4hz (because we were finding that packets were being dropped at 10hz).
No sure if it's helpful but there are also example sketches that might simplify or help narrow down on the exact sequence of events that make the problem appear or not.
ah, one last thing..it was reported that if the if your gps has a battery the APM has more trouble identifying it. this points the finger at the timing issue because the GPS takes a while to warm up and start sending data.
I the lastest Mission planner and via APM 2.5, has disabled the AC2(heli) setup widow :(
Otherwise I be testing now