T-Rex 500 heli with mRo Pixracer R15 and mRo SAM GPS with mag, running Arducopter v4.1.5.
I’m new to Arducopter in a heli, and have been trying to gain confidence in it over the past couple of months. Stabilised mode is fine, and a few weeks ago I tried Position Hold, without any drama. Then two weeks ago, while in Pos Hold mode the model suddenly climbed quickly at the same time moving forward quite quickly. I switched back to Stabilised mode and landed okay. Used the rest of the pack flying around in Stabilised mode without any issues.
Yesterday I encountered the same problem again – sudden ascent and forward movement while in Position Hold mode. I still don’t know how to meaningfully analyse a log file, so could someone please take a look at this and suggest what I should be looking at in the file, and what went wrong during the Position Hold mode.
I haven’t flown the heli since my initial post, but I have been doing some reading. I’ve looked at the log that’s linked in the previous post, and see that my x, y, and z vibrations are well within recommended limits, averaging somewhere around 10 throughout the flight, with a sudden peak around 35 on landing. I’ve also viewed the clip values where the “Measuring vibration” notes say that I should view the Clip0, Clip1, and Clip2 values, but I only see “Vibe > 0 > Clip” and “Vibe > 1 > Clip” using MP. For 0 and 1 the clip values are identical and peak at less than 10.
So can anyone see anything that would explan the sudden ascent and forward movement during Pos Hold, please?
From what I see you had a GPS glitch. In yellow is your altitude, from GPS point of view it drop very fast and the pos control made your heli climb up.
Thanks for looking Pedro_Claro. I see what you mean. But, according to the graph, the climb after the GPS thought it had dropped was greater than the drop was – it was still ascending when I took over.
Is there any other logged parameter that might explain what the glitch was caused by? Is it likely to be interference from the heli frame and equipment (it’s mounted on a carbon mast 8cm above the tail drive gearbox, 10cm behind the main shaft), or simply a faulty GPS module?
My explanation is that after you had the GPS issue in the vertical speed, it changed lane. I check your IMU1 an it has a lot of noise in the z axis, and I think when it changes lane it starts following the IMU1 and that affect the climb rate. Right after, it starts the Vibration Compensation, it also affects the climb rate. This is just my explanation but could be something else, I hope that another user can provide you better support.
My Arducopter hexcopter has flown perfectly from the outset, so Ive never had to analyse its logs. So please bear with me, with the problems I’m having with this heli, I’m new to this
First off, where do you find the IMU1 vibration data? When I select the Vibe option in the log browser I see sub-folders 0 and 1 – do they represent IMU0 and 1? Anyway, if I select folder 1 I don’t see any vibe data, but when I select folder 0 the vibration is steady around 10 throughout the flight which, according to what I’ve read, is well withing acceptable limits. I’ve also graphed Alt from the Baro sensor, and it shows a similar dip then ascent at the same time as the GPS does, but at a completely different altitude. I also graphed the number of satellites in case the GPS was having issues, but it remains above 10 throughout the relevant part of the flight (it does drop below 5 at one point earlier on, which had no noticeable effect on the flight).
Attached is a screenshot of the part of the log where the problem was, with Baro Alt in blue, GPS Alt in green, vibration 0 in red, and number of sats in yellow. The green arrow roughly indicates the location of the uncommanded ascent just before PosHold was cancelled by me.
That is not normal, it was supposed to be there, no idea why not.
IMU 0 is OK, but it switched to IMU1 and in my opinion the noise in the z axis is too high as shown in my last post. The climb rate is affected by noise in the accelerometer, also when it activated “vibration compensation” the climb rate is also affected, and we see climb rate getting away from the desired climb rate pictured in last post.
Your baro alt didnt nearly change from 15:52:48 600 till 15:52:49 437
Number of satellites is important but more important are the DOPs measures (dilution of precision), related to how the satellites are dispersed in the sky. Satellites concentrated in a small area is not good, they should be evenly dispersed to better compensate the error calculated in the receiver.
I’ve just realised that your vibe data is from a different source than mine. I was looking at Vibe > O and Vibe > 1 (but no data in Vibe > 1), where I should have been looking at IMU > 0 > AccZ and IMU > 1 > AccZ. If I graph Vibe and IMU Acc together I see that they’re completely different, so what’s the significance (if any) of that? Does it give any clue to where the vibration might be?
What does it mean when EKF switch lane?
Thanks for your explanations Pedro_Claro. I’m slowly learning the jargon, but right now I’ve got to go and hunt for whatever’s causing those vibrations or accelerations. The fact that they’re momentary makes it difficult.
During the week I cleaned the grass stains and dirt off the tail blades, and also tied some servo leads to the boom where I thought they could maybe have been flopping around a bit. But today, when preparing for a test flight, I realised that with this heli I’ve been in the habit for several years of not securing the front of the canopy, just relying on the two side pegs and gravity. So if the canopy were to bounce up and down a bit, maybe because of a gust of wind, it could certainly cause vibration in the Z axis.
With the canopy secured front and sides, a test hover using Pos Hold and Loiter modes was 100% successful.
Weather has prevented me testing for a few weeks, but yesterday I had two more successful test flights, mainly in Loiter mode, with vibration in all axes in the 0 - 10 range throughout. For both flights I took off and landed in Stabilise mode, then for one flight I let it hang in Loiter mode for 5 minutes, then for the other I did some basic manoeuvres while in Loiter mode for 5 minutes, to check out the response. In every case it settled back into a steady hover, without any oscillation, after I took my hands off the sticks.
So next week I plan to try an RTL. Following are the relevant parameters I’ve set:-
RTL_ALT = 1500 (my test will be on level ground with no obstructions)
RTL_ALT_FINAL = 0
RTL_ALT_TYPE = 0
RTL_CLIMB_MIN = 0 (I assume that’s the minimum distance to climb even if its already at RTL_ALT)
RTL_CONE_SLOPE = 3
RTL_LOIT_TIME = 5000
RTL_SPEED = 0
WPNAV_SPEED = 100 (1 metre per second for first test)
WP_YAW-BEHAVIOR = 3
LAND_ALT_LOW = 1000
LAND_REPOSITION = 1 (though I intend to switch to Stabilise mode before landing)
LAND_SPEED = 50
LAND_SPEED_HIGH = 0
WP_NAV_SPEED_DN = 100
Any comments please? The full param file is attached if you wish to go through it.
With the vibration problem fixed I today managed three RTLs without any significant issues. Despite a gusty moderate breeze each of the landings was within 2 metres of the launch point. I took manual control of the first RTL when it was about 2 metres off the ground, then I let the second one land itself, but disarmed it manually as soon as the skids touched (or maybe just before!). Finally I let it auto-land and disarm itself.
The only issue I had was that the heli really struggled in the horizontal leg of its RTL because the gusty wind was blowing it backwards and sideways, but it kept correcting, and made it in the end. I’ll be increasing WPNAV_SPEED for future flights, which I think will help it fly more in a straight line. I’ll probably increase WP_NAV_SPEED_DN too.
Thank you to all the forumites who helped me get this far.
