"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.
input_tc tends to limit how quickly you get to your maximum angular rate rather than the maximum angular rate. By that I mean input_tc is intended to limit angular acceleration. So if it is really slow then it can dominate and limit the maximum rate but it isn’t normally dominant.
Without any angular accel limits, the square root control algorithm is a first order response in angle. The plot below shows the desired output from the square root controller. The attitude is shown to have a first order response shaping.
It shapes how quickly the aircraft achieves the requested angle which for the position controller is the horizontal acceleration. The jerk used in the position controller shapes how quickly the acceleration is achieved. I think you even have cosine shaping on the onset for the jerk. I don’t see how this is different.
I guess I was just looking for a calculation or rule of thumb to determine when the position controller is asking more than what the attitude controller can give in terms of rate at which horizontal acceleration can be achieved (i.e. how quickly you can roll into a turn). Maybe this is not a factor until some large value of ATC_INPUT_TC is achieved but I think it is useful to know since this will limit the position controller when rolling into a turn.
On a similar note, I had played with this new cornering accel and it does help; but to keep speed up in turns for cases where the waypoints are closer together like in a mapping survey, the jerk needed to be increased so that the time to roll into and out of the turn was decreased. This made the pitch response very sensitive. It might be worth investigating an additional cornering jerk parameter (I know, I know… Like we need one more parameter). Just like the cornering accel, this allows the user to adjust the cornering a little more.
Hello
After changing the version of MatekF405-STD to V4.4.X, it no longer recognizes the barometer. The barometer of this FC is like DPS310.
The parameters are set as follows.
BARO_PROBE_EXT=64
BARO_EXT_BUS=0
It was normal until V4.3.8.
soramon
The real problem with this is it would require big changes to the S-Curve generation. That isn’t going to be practical for quiet a while.
