In recent test, GND_PRIMARY value was changed to 1, and it’s look like the altitude oscillations have disappeared.
However, pressure sensor’s(BARO1) heater still showed oscillations.
is it hardware problem(cube orange)? or firmware driver?
We will give you some parameters to change on the heat control loop.
We suspect the heater is a bit stronger and needs lower PID settings. This is only in master so far but it should be in the next beta release. (unless you are able to test master)
As Leonard says the heater change didn’t make it into -rc2 but it should be included in -rc3. Basically the heater in the CubeOrange reacts much faster than the one in the CubeBlack so AP’s heater controller needs different gains.
Thanks very much for your report. It was extremely helpful to have the logs.
I’m faced with several issues in the altitude controller since updating to copter 4.0. I did a lot of test flights and was not able to get rid of those problems. I’m confused that nobody of the developer take a note. @rmackay9@Leonardthall Maybe you can have a look on those issues:
No, I conscious set the RTL height to 3m. Before that, the RTL height was set to 25m and leads to a crash. I flew a auto mission 5meter above ground. At the end of the mission the drone climbs to 25meters and crashes into a power line wire during RTL(who was standing in the field).
I understand the RTL height as the minmal RTL height. If I set it to 3m, the drone never fly back home below this value. If its above, for example 10m from the last waypoint, the drone fly back home in 10m. I’m I right?
It should fly back at the current altitude but you are using terrain altitude and when it changes to altitude above home it keeps the current altitude but changes the reference. That results in a change in altitude.
In fact, I believe that a lot of people have a problem with low altitude terrain following the fact that the RNGFND_Gain does not work in Auto mode which causes too much aggressiveness of the drone and therefore relatively large height deviations.
I do not understand why it change to altitude above home. I set TERRAIN_FOLLOW to 1. So the rangefinder should be used also for RTL.
After a few hundreds of flights this year, I can definitely say that something is wrong with the altitude controller…
@chr89 Thanks for your post. That explains why terrain following in Loiter is very smooth and in Auto partially very aggressive. I see a lot stop and go behaviour like in my linked thread above. It would be nice if we can eliminate this issue.
Hi @chr89 and @buckker , I get the distinct impression you think this stuff is easy and can be done in a quiet evening after the kids are in bed. Maybe that the dev team is negligent in addressing the communities needs. After all, how hard can it be to make an aircraft do 60 km/h 2m over undulating terrain?
Apparently nobody thinks the feature is important enough to pay a dev to fix the problem either!
That means the members of the dev team will work on what they think is most important. In the case of Randy and myself that is finishing the 2 to 3 year project we have been working on to implement S-Curve navigation and rewrite the navigation controller. And the only people paying for that work to get done is Randy and Myself, (soon to be followed by all the other dev’s that will help insure the PR is right when it goes in).
Or maybe it is just isn’t doing what YOU want it to do.
So I would suggest that when you start feeling a little frustrated that your particular application could be done a little better or your life made a little easier if only the “dev team would work on the issue” I would suggest you take a moment to think about what you have done to help the dev team work on the issue. Maybe you could take more time to clearly show the problem so a dev member doesn’t need to spend an hour working out when and under what conditions the problem happens. Maybe you could read through the code and work out how to fix the problem. Maybe you could spend a week finding a fix for the problem, testing that the problem is solved and works under all conditions and create a PR…
Now I am going to get back to trying to finish this multi year project to rewrite the navigation controller to make it easier to do all the things you would like to do and many others that you don’t know you want to do.
I have to say that my motivation to spend my own time on terrain following is significantly less than before I decided to spend a few hours of my personal time trying to answer questions on the forum…
It seems that my words feels a little bit harsh, sorry for that. First, I really appreciate the dev. team work. I start using arducopter where we had version 2.xx. It’s great to see the improvements over the years. Unfortunately I’m not a software engineer and I’m not talented in software programming. I’m talented in CAD design and building machines. So, I really want you to help to find issues in the code, but I’m afraid that I’m the wrong guy for that. The only thing I can do is to give you feedback from my test flights. I try to do this as precise I can because I know without that it’s finding a needle in the haystack…
I see a lot of unread pull requests on Github and I’m asking me if its worth to spend time and energy to give feedback if they stay without any impact. And yes, that’s sometimes a little bit frustrating because I like to improve the functionality of arducopter as well. But I now learned that your time is very limited to answer to those requests.
For my particular alt hold issue. In my opinion it’s not only a bagatelle. I saw the drone climbs or descends a few meters after the last waypoint during the RTL. It’s a unpredictable behavior and that’s what I’m concerned about. Maybe it make sense to wait until the S-Curve navigation is ready for field tests.
No your words are not harsh, they assume that features just happen or should just happen. Nether @buckker or @chr89 made any attempt to acknowledge my explanation of the problem, much less understand it. Or my explanation on your issue report.
I did not close the git issue report because I do not believe this behaviour is correct however RTL does not and should not follow the terrain. RTL should be set to be able to clear all obstacles. If you can not risk climbing to RTL altitude because of overhead power lines then you have other failsafe options available.
We could enable terrain following for RTL but that would be a feature request, not a bug fix. And if you want it done quickly because it is important to you then you could make a case to have that feature added and fund one of the devs to get it done.
Then we have another feature request that is completly oblivious to the complexity of this problem and contradicts itself. You get either aggressive and accurate or smooth with deviations.
But the groundwork is being done as part of the S-Curve work.
But then this:
You have absolutely no data or information to make that statement and after ignoring my feedback we have entered simply venting on the dev team.
Maybe if you are doing:
you should become a partner and get on the partner dev calls so you can contribute back to the community that supports your business, even if it is only a small financial contribution and insight into the needs of your industry.
I saw your explanation, but it don’t make sense in my eyes. It does not correspond to the information from the arducopter wiki (maybe I also misunderstand it…)
Now I’m confused. Following terrain in RTL is available:
I would totally agree to this, until we had a crash this year. This shows me, that a high general RTL altitude is not an insurance for no crash. Even better would be so send the RTL altitude with the mission to the flightcontroller. According to my knowledge it’s not possible. This would allow me to set the RTL altitude according to the environment. I’m now using a front facing lidar for object avoidance to minimize the risk for flying in low altitude. But in the end of the day, the pilot still stays the master…
Yes it looks like someone has already added RTL terrain follow as an option. But in your mission you set RTL to absolute. Maybe try with RTL set to terrain too. That may give you the behaviour you expect.
I have spent an hour trying to work out what would happen with your particular combination of parameters but have not got far. This code has been changed a lot in Master too so I am not sure if the problem has been fixed with those changes. If you have an aircraft you can risk testing master then maybe you can see if the problem still exists.
In any case there is a problem with the initialisation of RTL altitude here.
Sorry for low information problem was losing altitude and recover it in 1 or 2 second (many happened in first screen shot)
First i think is a high z vibration but z vibration is below 15 for the second look i was think its underpowered but it was ok
Also it makes losing altitude in autotune mode
Totally altitude losing is not sudden and recovery/losing is soft
I did a lot of test flights this afternoon. It’s not possible to send a terrain altitude with mission planner. If i read the mission back it jumps to absolut. Despite that, I send my multirotor on the mission. No success.
The problem seems to be complex. I was not able to find out under which circumstances the issue occours. I also disabled the rangefinder. One time I can’t notice any altidude change during RTL. Other flights with the exact same mission showed another result… I also increased the WP Nav Accel Z values which helps a little bit. I noticed that the multirotor leads sometimes to tip over during take off in auto mission. But no problem in Stabilize and Alt Hold. I also noticed that the drone drifts sometimes a few meters in Loiter even with a GPS Hdop under 1 (15+ satelites). I’m using CUAV gear (V5 Nano and the standard GPS module, the CAN GPS module was dead on arrival). I’m asking me if this could be a hardware problem…
On of the last flights with rangefinder enabled shows this result:
a part of the mission flyed over allready harvested corn plants (with is 2.5m altitude difference in the mission. But the log shows no change in altitude…
As a next step I will erase the hole flightcontroller an load the latest beta firmware. Not sure if maybe some parameters are totally off… I can’t explain all those issues…
