I had initially raised this question in Arducopter 2.x group yesterday but since no one replied and I really need help, I am posting this question in the Arducopter User Group.
Here is the situation:
I am doing a project to augment Search and Rescue operations as we know it with Semi-Autonomous UAVs. About a month ago we tried to join modules together but we hit a major problem with making the Arducopter fly in AUTO mode. We need to get the Quadcopter following the waypoints before Friday, the project presentation date.
Below is a screenshot of a log we downloaded yesterday. I have also attached the log to this post with our params file. The waypoint file for this flight only contained two waypoints and an RTL mode. Before this flight we tested Loiter mode and it worked well. In this flight however, we had multiple fly-aways with the Auto mode.
We believe that our project has potential. We have presented at the NCUR conference last week and won an award yesterday for our project, but for this project to come together we need a video of the waypoint navigation working with system by Friday.
EDIT 1:
Thank you Tsoi and Boland.
Yesterday (4/21) I did three things before flying:
1. Downgraded the FW to 3.1.5
2. Twisted the GPS wires for them to stay together and used a toroid.
3. Waited until I had connection to more than 10 sats before flying auto.
I ran two auto modes both worked well (the second ended abruptly at the second waypoint but that might be related to the problem I am about to explain).
The main issue that I am having now is the same the one discussed in the discussion forum called "AC 3.2.1 APM 2.5 Throttle pulsates in Loiter". As you can see from the image below and the log (named: 2015-04-21 20-18-29.log) attached, although the APM knows that the altitude is increasing and the error between desired alt and barAlt is increasing, it doesn't compensate.
red (barAlt) green (Desired Alt)
EDIT 2:
I flew again today (4/22) first with an Alt Hold P gain of 1 and then I increased it to 3 and tried it again.
Stabilization when Alt Hold P gain = 1:
Stabilization when Alt Hold P gain = 3:
Both flight logs are attached in the response I left today at the bottom.
Alt hold controller seems like it is broken. Not following the desired value at all.
What now? Tomorrow is my last day to test and fly...
Details
Frame: DJI F450 kit with motors and escs (original)
Autopilot: APM 2.5+
GPS & Compass: ublox RCtimer version (Ublox LEA_6H-0-002 (19) it also says v1.2) I also have a 3DR MTK v2.0 that I can use
I have done autotune to tune the craft.
Thanks!
Replies
I don't understand why you had to mess with the PID settings. The original issue was with GPS. Now that you had reverted back to 3.1.5, you should be checking GPS is working or not. Why mess with PID? Have you tried to fly with default values? I would restore the default value and try again. Then maybe use autotune. Right now you are too far off.
Yesterday with the downgrade I was able to get waypoint navigation to work well (EDIT 1) with jerky alt control. I am not trying to fix alt_hold mode to work. The only value I am playing with is the Alt_Hold P gain (EDIT 2).
Check your AHRS_MPU6K_FILTER value. See if it is set to 20. If not change it to 20.
The quad shot directly up whenever I switched to ALT_HOLD. the logs show that the desired value was at -15 meters. Interesting.
Good analysis and advice from Vinnie, Felixrising and Mike Borland. I agree it's the vibration that'll be the problem. There's no logs posted here with the IMU data (although we can see the graphs posted above) ut we can see it indirectly by looking at the CTUN message's Alt vs BarAlt. They diverge by more than 10m at times. Another clue (because we don't have IMU data) is the ClimbRate contradicting the Altitude.. so we can see the climbrate going to +3m/s but the altitude is actually dropping.
AC3.3 (Pixhawk and other fast CPU only) should perform better in these situations because the EKF is more resilient and we've also increased the Accel range from 8G to 16G. After AC3.3 goes out I think we will release a modified AC3.2.1 that includes the higher accel range. That'll need to be thoroughly tested though because it could reduce the alt hold accuracy a bit (i.e. larger accel range = lower accuracy).
Thank you for the response Randy. I have attached IMU log here for reference.
I believe I have the Kyosho zeal vibration absorption Gels which should be good enough but according to log (attached), my Z axis accel readings have a high (0 - 20) vibration range. Maybe its because of the amount of cables attached to the autopilot.
I will try to balance props and give it a spin tomorrow early in the morning.
Thanks again.
2015-04-22 22-34-48.log
I have a feeling whatever anti-vibration you used to mount the APM is not sufficient. The data from the internal accelerometers is combined with barometer and GPS data to calculate an estimate of it’s position. The accurate calculation of the position is critical when in AltHold, Loiter, RTL and AUTO flight modes. With excessive vibrations, the estimate can be thrown off and lead to very bad performance in these modes. Turn on IMU to log the vibrations. Z axis is the most important for AltHold. It must be below 0.5g. Also please double check and make sure you have sufficient foam covering the barometer inside the APM.
I couldn't find AHRS_MPU6K_FILTER but I found and changed INS_MPU6K_FILTER to 20 (was 0).
I am going to set alt hold param to its default value of 1 and go fly right now even though it is like 9:53 pm. :)
Thanks Much!
Thank you Tsoi and Boland.
Yesterday I did three things before flying:
1. Downgraded the FW to 3.1.5
2. Twisted the GPS wires for them to stay together and used a toroid.
3. Waited until I had connection to more than 10 sats before flying auto.
I ran two auto modes both worked well (the second ended abruptly at the second waypoint but that might be related to the problem I am about to explain)
The main issue that I am having now is the same the one discussed in the discussion forum called "AC 3.2.1 APM 2.5 Throttle pulsates in Loiter". As you can see from the image below and the logs attached, although the APM knows that the altitude is increasing and the error between desired alt and barAlt is increasing, it doesn't compensate.
Any suggestions as to how I can fix this?
Thanks.
2015-04-21 20-18-29.log
The pulsate problem was with version 3.2.1 firmware. Since you had reverted back to 3.1.5, you should not have the same issue. When changing firmware, you must go through the entire calibration process as if you are doing an initial install. Did you recalibrate your ESC, Accelerometer, compass and radio? If not do it first and try again. Then you may need to do the tuning as Felix had suggested.
-
1
-
2
-
3
-
4
-
5
of 5 Next