Hi @steve,
I’m not aware of any new parameters that have been added that affect the cornering speed but in general the make the corners smoother:
We really should have a wiki page on this… it’s on my to-do list.
I haven’t compared 4.4 vs 4.1 yet… I can do that although I expect it will be the same as 4.3.
@rmackay9 thanks for the response, however I have played with all those settings and still can not attain the same flight performance for nice smooth (and slow cornering) as I did before.
WPNAV_RADIUS I can decrease this very low or to the maximum but it does nothing at all to the cornering behavior (never has to be honest)
_JERK does not seem to have anthing to do with cornering, I turned it down a bit to stop the sudden forward tipping as it tried to accel up to the desired speed.
ACCEL_C as per above needs to be down to 200 for the drone to slow down in the corners but then it pretty much stops, turns then goes…
I am not in a position to do any testing for a couple weeks. I will do some then and post a log for the community but won’t be changing firmware on my clients drones anytime soon so I hope to solve it with settings that I am somehow missing.
Thanks all.
I agree especially if your testing and compare old firmware that I know works. I have firmware like 4.3.4 that I know works. If I understand this correctly. Possibly a new folder location and naming would help Now i have zero idea if more bugs have been added.
We have almost no regressions:
ArduPilot is much better than most software out there when it comes to regressions. I want to make that very clear.
But… sometimes one regression gets trough all the processes described above, but that is the EXCEPTION, not the norm.
"But… sometimes one regression gets trough all the processes described above, but that is the EXCEPTION, not the norm. " I guess next time you don’t need to bring it up then. 
Testing old firmware with new firmware is comparing the two for me a important way to find things that are wrong.
Back to testing after MP is not able to flash my FC with out forcing bootloader. Talk about regression.
Loiter hold seems to be up and down about .5 meter. Normally i can use the ground effect to calibrate.
Ground effect is not working well and Quad will bounce off the ground during low level flying
.
I getting an error after re flashing Beta.
" per arm UAVCAN: duplicate node… /1241"
Hi @Quadzilla,
It may be possible to clear the pre-arm message by setting CAN_D1_UC_OPTION to 1.
The issue can be caused by two dronecan devices trying to use the same node id (similar to a mavlink component id) but I’ve also seen it caused when using the same device again but AP doesn’t recognise it somehow when comparing vs an internal database of dronecan node ids.
Went away after a reboot! I was testing Beta and Stable version around the same time helping to find a MP error during flash, alls well.
Got to figure why i lost ground effect this time. Normally I can skim across the bricks and asphalt.
There seems to be some fallout from the change I made to the cornering behaviour with the parameter WPNAV_ACCEL_C.
To keep identical behaviour as before you need to set WPNAV_ACCEL_C = 2 x WPNAV_ACCEL.
This parameter only comes into play during corners that turn by more than 60 degrees.
To get the most open and smoothest sharp corners you don’t want to be reaching the radius or acceleration limits. If this is your goal I would suggest you start with two data points:
If your minimum WPNAV_ACCEL is less than half your maximum WPNAV_ACCEL_C then you have some room to experiment with acceleration, just maintain WPNAV_ACCEL_C = 2 x WPNAV_ACCEL. If WPNAV_ACCEL_C > 2 x WPNAV_ACCEL not then you will need to use these values.
Start by setting WPNAV_RADIUS to a large value, something like 10000. This will ensure you are never limited by the maximum radius during the turn.
Now you need to set the jerk. The most open corners are jerk limited corners. You can achieve this by setting the jerk based on this equation.
Jerk = Accel^2/Vel
Where:
Accel = 0.01 * WPNAV_ACCEL_C
Vel= 0.01 * WPNAV_SPEED
and
WPNAV_JERK = Jerk
(it will be great when we remove cm!!)
Make sure you have enough space between waypoints to get up to full speed.
This will result in the most open corner while reaching the maximum acceleration.
If you use a lower jerk compared to the calculation above you will not reach maximum acceleration.
If you use a higher jerk then you will decelerate in a straight line before initiating the turn.
If you reduce WPNAV_ACCEL_C below 2 x WPNAV_ACCEL the corner angle will be more open when you will start doing a sharp turn rather than a sweeping turn.
As you can see above it does have a big impact however it is more noticeable in some corner geometries.
I hope this helps. I know this all might appear a little complicated but we are trying to achieve a jerk, acceleration, velocity and radius limited corner geometry for all corner angles in a 3 dimensional space where our vertical limits differ from our horizontal limits. So yeh, it is a little complicated.
Thanks for the great response it is appreciated.
However, it is overly complicated when it worked fine before. And to be honest it’s changes like this that I can’t deal with when I have a fleet of drones to maintain so hence I had not updated FW in years. This is a change that needs proper documentation if possible and verification because to be honest all advice given so far is to no effect.
I also am concerned about what happens in outlying situations, high wind, low wind gust or other external forces. A drastic change in flight behavior means I have to fly about 40 hours in varying conditions to ensure my data is not effected.
For example my survey data was bad for every flight after FW across all drones this was because the done was going too fast through the corners and was tilting too fast to accelerate etc. This all stemmed from the FW update. So I had to madly find a solution to get good data, recall all the drones and update them (not good for business)… now the drone pretty much stops in the corners and I am not about to change it because I can’t risk thousands of dollars of data.
I would love to spend a day testing (not being sarcastic I would really like to) these things but unfortunately I will not have that opportunity anytime soon so I have to leave the discovery to someone else.
At any rate I am not trying to be negative, you guys are amazing for sure! However from a heavy users point of view these things are tougher pills to swallow than the dev’s realize.
Thanks again and I will test when the opportunity arises.
@steve I am a developer and a manufacture so I understand your situation. I am going to be blunt here. You are responsible for updating your aircraft and understanding the impact of any changes on your system.
If it worked fine before then don’t update. If you do update then do your due diligence and test properly. This is especially true if you have “not updated FW in years”.
Are you a partner Steve? That is a great way to provide support and puts you in a position to both request and fund improved documentation in the areas that will help you. Documentation does not help if you are not able to spend the time to understand and test the new parameters before you roll it out over your fleet.
If it worked fine before then don’t update. If you do update then do your due diligence and test properly. This is especially true if you have “not updated FW in years”.
I had to update because a safety issue in the FW caused a crash that is a known issue and needed to be updated, otherwise I would stayed on the same FW forever… I have been using Ardu stuff since day one and this approach had done me well.
Does it state somewhere how all these parameters work together as per the description above and I just missed it? Or was I suppose to do my due diligence and guess as to the relations of all these parameters? Cause that is what I did and was not able to succeed after many test flights. I did my best and ended up just accepting the stopping corners.
Are you a partner Steve? That is a great way to provide support and puts you in a position to both request and fund improved documentation in the areas that will help you. Documentation does not help if you are not able to spend the time to understand and test the new parameters before you roll it out over your fleet.
I agree, I would love to help I am not a partner… however it is pretty hard for me to document something for you that I know nothing about how it works. Like asking a user to document a feature they don’t know exists.
I am not trying to start a war here, I know where you are coming from but look at the responses above. It took this long to get a response that may be the correct one.
I will state it again… you guys are awesome… and again I would love to help more and test and document for you but I am a user at the moment not a dev or tester.
I am just giving you feedback as others have that something changed, it’s not as easy as it was before.
All the best and keep on doing awesome work.
I agree with this approach.
We rely on the support forums to understand what questions need to be answered and how to communicate these answers effectively. The due diligence you should have done is to test your aircraft and ensure all settings are appropriate before sending it out across the fleet. In particular you said this:
S-Curves have been coming for a long time and you updated to the second release where we added the corner acceleration to provide further customisation to corner geometry. It is also worth noting that your application is one of the key drivers to improving the mission cornering. These changes give you much tighter and more reliable and predictable control over the mission. This lets you shorten overshoots and waist less energy on corners. That all translates to time, money and safety when fully utilised.
I appreciate and respect that. I am not trying to have a go at you.
Here is some background that might help understand why we changed to S-Curves and how they work:
Thanks for all the info! this is great background stuff for me.
Keep on doing great work.
@Leonardthall can you comment on how these settings are affected by settings in the attitude controller. In particular, how does ANGLE_MAX and ATC_INPUT_TC affect the ability of the position controller to meet acceleration and jerk requirements.
Would you set the cornering accel based on angle max?
WPNAV_ACCEL_C = tan( ANGLE_MAX) * 9.81
I think Jerk is the harder one to figure out because it relates to how fast the attitude controller can achieve a bank angle. How is the jerk shaped? The attitude controller achieves attitude using a 1st order like response with ATC_INPUT_TC as the time constant. It would be good to know when the attitude controller would limit the jerk in the position controller.
Hi @bnsgeyer,
Yes and no. This defines the maximum acceleration of a stationary aircraft in a zero wind environment. The problems begin when we are operating in wind or changing speed. In these cases we have already used up some of our lean angle range to fight the wind and/or drag. So our maximum acceleration changes based on the direction of the requested acceleration.
When I consider my “lean angle budget” I consider three things:
Ideally the lean angle will be sum of 1 and 2 (equivalent acceleration but applying small angle approximation here). However it is pretty normal that the sum of 1 and 2 will be greater than 3. In this case I set the lean angle to 3 and accept that the aircraft will not be able to accelerate at the target value into the maximum head wind.
This is a little trickier but I actually look at these values in the code and reduce your settings if they are limited by the attitude controller input shaping or command model.
In answering this question I believe we have not limited the actual maximum target acceleration based on the maximum lean angle. We do limit it in the code and the various navigation systems do elegantly handle acceleration saturation (they have to do this anyway). However I wonder if we should add that…
This is where we limit the final output acceleration and detect saturation:
Lean Angle → Acceleration
Angle Rate → Jerk
ATC_INPUT_TC → related to snap and crackle
So ATC_INPUT_TC is not a major player here.
Jerk describes how quickly you achieve an acceleration (rate of change of acceleration). So the rate at which you achieve bank angle (acceleration) is governed by input_tc. I don’t see how that cannot affect the position controller if the input TC is set to a long time constant.
