I am using the PixHawk 2.1, v3.5.x
I am using a LidarLite v3.
AC v3.5.3
The Lidar is working correctly and measuring distance correctly.
The problem is that the copter is not holding altitude correctly. It is still using the barometer, even though I want the lidar to be used for altitude measurements.
Check this video I made today:
I believe the firmware is attempting to mix the barometer measurement with the rangefinder. The problem is that the barometer is a terrible way to measure altitude and I want to shut it down, if possible.
How can I make the rangefinder’s altitude measurement have more weight than the barometer?
Yes, by default the measurements are fused by the EKF. If you want to use lidar only, you will need to set the following parameter:
EK2_RNG_USE_HGT = xx (not -1)
This defines the range at which the EKF will start using the lidar as the primary source for altitude control. It is a percentage of the maximum range you set in the rangefinder settings (RNGFND_MAX_CM).
(I edited this post to remove incorrect information)
I already have those settings in place.
The problem is the damn barometer keeps being used instead of the Lidar. The lidar is almost completely ignored.
RNGFND_ADDR,0
RNGFND_FUNCTION,0
RNGFND_GAIN,2 << this value should give range finder a lot of weight, in the alt calculation.
RNGFND_GNDCLEAR,5
RNGFND_MAX_CM,3500
RNGFND_MIN_CM,5
RNGFND_OFFSET,19
RNGFND_ORIENT,25
RNGFND_PIN,-1
RNGFND_POS_X,0.11
RNGFND_POS_Y,0.13
RNGFND_POS_Z,0.1
RNGFND_PWRRNG,0
RNGFND_RMETRIC,1
RNGFND_SCALING,3
RNGFND_SETTLE,150
RNGFND_STOP_PIN,-1
RNGFND_TYPE,15
What I want to do is completely turn of the barometer or give it a very very very low weighting in the altitude calculation, for example 0.0000001.
Here is my understanding of what you are seeing in your video. Someone correct me if anything here is wrong:
Rangefinder reading and altitude are not necessarily the same, and the flight controller uses both of these measurements for different purposes. The altitude is just the height above the home point, while the rangefinder reading is used to find Height Above Ground Level (HAGL). In flight, a rangefinder will detect trees and other obstacles, as well as gradual changes in terrain height, which will affect the reading and therefore HAGL. This means that it might be different than altitude, but that doesn’t mean that either reading is incorrect.
In your video, probably what has happened is your barometer drifted while the drone was sitting on the ground (or you moved it, etc.), so the altitude has changed but lidar reading has not. When you arm the drone, Arducopter calls a ground_start() function which will set the barometer altitude to 0. So, when you start flying, the baro and lidar should agree if the scaling is correct and there are no obstacles.
When in flight, most altitude-controlled flight modes will use both HAGL and altitude, depending on which is appropriate for the task at hand. This means that even if your barometer’s altitude isn’t quite right, the flight controller is still actually using your lidar for routines such as landing, terrain following, or other routines where it is applicable.
That would be a good explanation.
The only problem is that when in flight, the incorrect altitude (ALT) measurement is used and the copter does crazy manouvres. For example, today, I launched the copter in ALTHOLD mode. It should’ve gone to 1m in the air and stopped climbing. Instead, it went about 20m in the air. I checked the GCS, and it was reading -20M!!! I put the throttle to low. The copter kept climbing. I had to put the copter in STABILIZE and using direct throttle control, I brought the copter down. When it was sitting on the floor, it was now at around -30M.
If the alt measurement was not causing crazy flight performances, I wouldn’t bother complaining. The problem is that I can’t get the copter to sit still in the air, It is bouncing up and down like a yoyo, because the ALT measurement is incorrect.
I need a way to completely disengage the barometer. The copter is being designed for indoor usage, so it should never reach more than height of 2M - this is where the LidarLite (LL) comes in. At this point, if the ArduPilot uses the barometer for ALT readings. what is the point of spending so much money on a LL?
One thing I have checked (on the log files), is that normally the date is always 01/01/2000.
However, in the last few days (which is when the altitude problem started), the log files are correctly dated 05/12/2017.
EDIT: Tommy1605 explained that the date/time is got from the GPS.
Barometer values (1 and 2).
Altitude.
And the rangefinder reading.
You can see towards the right, line number 5400, while the measured ALT is around 1M, the rangefinder reads 8M. In other words, the copter reached a height of 8M, however, the flight controller, believed the copter was till hovering at 1M. I then had to put the copter in stabilize, to bring it down. This was also the time that I had throttle to minimum, though the copter kept climbing.
In this graph, I normalized your RC3 throttle input to be from 0 to 1, so it is on the same scale as Throttle Out (yellow), which is basically just a measure of commanded motor power from 0 to 100%
The discrepancy you noted around line 5400 is due to a crash. The drone rolled over, so it was on the ground (alt ~0) but the rangefinder was looking at a ceiling or wall or something.
The bouncing you see seems to be due to the copter changing its desired climb rate from an interaction between sonar alt and desired sonar alt (DSAlt). You command the drone to descend, so DSAlt has a downward slope, but the copter doesn’t seem to be descending. After SAlt and DSAlt diverge too much, DSAlt resets, resulting in the jagged lines in the graph and altitude bouncing you see.
The rangefinder and barometer agree with each other well enough. The EKF’s altitude solution, however, is very different from these readings. This is important, but I will have to look into it later, or maybe someone else can.
The other important thing is that your copter doesn’t seem to change climb rate in a way that matches the ThOut. Later in the log during a Stabilize flight, it can be seen that your copter hovers at a ThOut of around 0.55. However, in this Alt Hold flight, even when ThOut is as low as 0.15, the copter continues to climb. This may be a flight controller problem, but maybe it is also mechanical or ESC related. I don’t know what kind of copter you’re flying but it might be worth checking if your ESC has some throttle expo or smoothing setting or something like that.
If I get some more time, I’ll take a closer look. Hope this helps in the meantime, though.
The reason why this happened was that once the copter was in ALTHOLD, it shot up very high in the air.
I then put throttle to miniimum.
Copter kept climbing.
I believe this was because the copter thought it’s altitude was around -xM. Only in reality, the altitude was around 8M.
The problem is the discrpency between the actual altitude and the altitude which the flight controller thinks that the copter is at.
The other thing is that the copter was flying fine last week. Everything worked smoothly. The next day I brought the copter out for a flight test and it began to behave like this. No changes were made overnight. No hardware or parameter changes.
The ESCs used are SimonK, 30A, cheap ESCs from ebay. These have worked fine for many months and unless all ESCs have become defective, I don’t believe there is anything wrong with these.
My suspicion is that there may be something wrong with the flight controller.
What I may do is disconnect the wires and then re-connect them.
If you do have any further advice, then let me know. Also, do you know of anyway to reduce the dependence on the barometer, so that the lidarlite has the most weight in the calculation of the altitude?
I had another flight today, just to capture the problem, so the flight log is short.
1, I switched copter to althold.
2, i armed copter
3, i put throttle to max for 1 second, then dropped to middle (to initiate launch in alt hold)
What should happen is the copter should reach about 1 metre, and then hold.
What actually happened is the copter shot up like a rocket and refused to come down, so I had to disarm.
link to log file: https://drive.google.com/file/d/1w-0LuCzQFzkDRumt7L0GM9rBmcihl674/view?usp=sharing
Last night I disconnected and reconnected everything and I am now thinking that the flight controller has gone defective.
Yes, I just looked at this new log and Eosbandi is right. Your Z vibrations are severe. This causes the EKF altitude solution to be very different than the baro and lidar reading, which agree with each other.
See if you can modify how you mounted the flight controller to improve damping, and also check for sources of vibration such as loose motor arms.
I checked some older logs and I must admit, the vibes have increased for whatever reason.
The z vibe went from around 27 (when the copter was working well), to around 90 (which is causing problems, now).
