We pull the IMU data through the MAVLINK paramter Attitude. We run a line sensor and have to correct for pitch in the data, that is why we log the IMU info. We are unable to get a datastream with an update interval of less than about 250 ms from the attitude parameter. Is there a way we can get the pitch from the flightcontroller at about 40 ms intervals? I have not looked at the possibility of using SCALED_IMU. What is your suggestion?
Logging raw IMU and Fast Attitude is not causing excessive load, so there’s no real issue with them. I only suggested turning them off in case they were confusing the issue.
Are you saying the copter should follow a line on the ground? with corrections from the ground station?? Please feel free to correct me, but I dont think I can help with any of that. I am certainly no guided mode/mavlink expert by any stretch of the imagination. I see you already have the serial ports set to relatively high speed, 115k baud.
Would it not be better to run a LUA script for corrections, or a companion computer onboard?
What I am suggesting is improving the basic tuning, which will hopefully allow any advanced issues to stand out more.
We’ve often seen people asking questions about why something is not working well in guided mode or missions, yet their basic tuning is either not attempted or terrible. That makes it hard to tell if there is an actual issue with their mission or guided mode commands.
I’m not saying your tuning is that bad 
I would persist with some additional tuning though, and use RC to test, until pitch and roll are doing what they are meant to do. Then see how the missions are affected and what needs altering.
The test flight team reported more instabily following above process. They reverted back to previous parameters and ran auto-tune for roll and pitch.
What part of the PID is used to run control for altitude position setpoint? Alt Holt, Acceleration? We see for xy position, but not for z, except the alt_hold parameter. I am refering to the extended tuning page in mission planner (see image).
Part of our oscillation stems from the rangefinder signal lag. This lag comes from the implemented low pass filter. We are going to dial back on our low pass filter cut-off frequency (make it larger) to reduce the lag, but we still need to know where do we tune the control loop for altitude?
Hi @hbrenkman,
There are a lot of changes between 4.1.4 and 4.3 in the terrain following. I suspect there are a few things we can do better in this area. However given you are running old firmware it is difficult to help you.
Thanks for the info. We upgraded to the latest. We also made changes to our rangefinder code in order to remove lag. Plan to test Thursday and Friday. We’ll update new bin files once we have them.
Ok, if you are not using the standard release, I can’t help you.
Just to clarify, if you are using the standard release I may be able to make changes to address the problems you see if the existing flexibility can’t address the problem. But when you use custom code that is no longer an option.
Yes, we are using the standard release. Copter 4.3.3.
Then I don’t understand this:
Can you please explain?
The changes relate to a radar sensor we use. We had some lag originating from the radar sensor output due to filter implementation. We changed our code and now it gives a very good signal without lag issues. The lag was visible in the oscilation when we fly with terrain follow enabled, or shall I say, surface tracking. You will see it in the previous log posted. We just tested our new code this morning and do not see lag. We have not yet tested with terrain follow on. So, no we have not changed any ardupilot code, just our own sensor code.
I still believe you should improve the tuning using the params and methods I provided.
Dont run missions and such, just concentrate on the tuning and get it right - then do the missions and radar fault-finding.
There’s no way that autotune produced the results you pictured in that screenshot. And the Harmonic Notch Filter settings were not even updated.
The test site was very windy today so they could not tune the drone. They will try tomorrow. I agree with you, it has to be tuned as best as we can before flighing with terrain follow.
Here is a bin file from a flight today. Just to separte things out, we changed our algorythm for getting ground from the radar sensor, removed the filter. The lag is now gone. During straight flight you will see in the linked bin file that the dolphin oscillation seems to dampen out. Previously it did not. My conclusion is that removing the lag helped, and with tuning we should be able to get the rest sorted. We still need to better understand what parameters we need to use to tune.
The test was conducted in high wind conditions. At waypoints the rangefinder gets very noisy. One of the issues we deal with is to correct for pitch when we approach waypoints. We stream the pitch from the flight controller via the ATTITUDE parameter. We cannot get the interval period below about 150 ms. If we want to use the picth from the flight controller, then we need it at intervals not exceeding about 50 ms. What options do we have to speed it up to our companion computer? We only stream two parameters, GPS_RAW and ATTITUDE.
By the way, Copter-4.3.4-rc1 has some improvements to the filtering that may help as well.
In particular item 3k from the release notes linked above
- k) Surface tracking uses filtered and corrected rangefinder values
Thanks. This explains what we saw today that the rangefinder values are filtered in copter 4.3.3 but not so much in 4.1.0.
1 Like
The values are filtered in 4.3.4-rc1 and NOT filtered in 4.3.3 and bellow.
We have been able to tune out a lot of oscillation, but some still remain. Our latest log is here: 00000130.BIN
Are you sure that’s the correct log?
It shows as being earlier that recent once and is still Arducopter 4.3.0
Thank. We changed drones and missed checking that. We upgraded to 4.3.3 and here is the log: 00000132.BIN
We noticed that we are not reaching the desired altitude. Will be tweaking that.
No Battery voltage and current monitoring - that will be essential for safety and even for tuning
ARMING_CHECK,1
INS_ACCEL_FILTER,10
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
After you’ve set up the battery monitor and at least got voltage readings, connect to MissionPlanner Initial Parameters and put in your prop size and battery cell count, select Suggested settings too, then accept everything it offers.
Then just do some hovering and gentle movements in AltHold and Loiter.
Let’s see that log.
I’m still a firm believer in getting the tuning right first, so you know the copter works as it should at a basic level - then move on to advanced features and any fault-finding.
If you dont have a good tune to begin with you wont be able to tell where issues are coming from or how much of a problem they really are.
1 Like