I’m experiencing some weird behaviour during waypoint missions.
Every now and then the heli will drastically slow down half-way between two waypoints, then speed up again. There’s no mission item there, no reason for the action.
In the image below I’ve plotted waypoint latitude in yellow, target position and actual position. It happens all over the place but the most obvious point is at 4.25s. This was in the middle of a 300m straightaway, the UAV pitched back violently to brake for no apparent reason, then continued You can see that the target position seems to stop updating or something?
Any ideas?
Log uploaded here (was too big to attach)
It’s a bit hard for me to tell, but it’s looking like GPS speed drops as the craft tries to climb (and descend) in line with rangefinder distance and the tuning comes into play where you start to get pitch and roll oscillations.
There’s few other oddities, like the log ends at Land Complete Maybe instead of the usual disarming messages and so on.
Vcc (5 volts) is a little low, not critical but probably worth looking at - is the rangefinder running off the flight controller Vcc? It might need it’s own BEC.
PIDs are odd to me, but this is like a trad heli right (Chinook) ?
Check if the craft can actually achieve the WPNAV parameters you’ve got set.
Probably best to move this to the Traditional Heli catagory if this is a tuning based problem.
Maybe @bnsgeyer or one of those super-experts can rule out or rule in the tuning.
I was looking at CTUN.Alt, which seems to increase in response to the GPS speed decreasing. However when I looked at the rangefinder alt at your suggestion I found the following:
When CTUN.SAlt gets too high (can’t find a reason for the exact value yet) the target speed sqrt(TVX^2+TVY^2) drops, and in response, the altitude drops.
I can’t find the exact piece of code that would cause this yet, but I wonder if it’s similar logic to a multicopter reducing its tilt angle when it can’t maintain altitude.
I wish I could introduce some I gain to the Z velocity controller to get rid of the steady state altitude error at high speed, but it doesn’t have an I term.
Thanks for the other comments too, looking into those. Yes we’re flying a tandem helicopter (Chinook flying sideways). It seems to be hitting all the WPNAV targets and parameters.
I believe this is a problem with the way we move the target location as we get vertical and horizontal position errors. We scale the vertical and horizontal based on their respective stopping distances. This has worked well for most cases but starts to fall down when people use high accelerations and low max climb rates like you have here. This makes the aircraft slow down if it thinks it is not controlling altitude properly. The way the controller is set up this results in a braking maneuver.
So this is a combination of the waypoint controller design and some aspects of the position controller. The good news is it has all been rewritten in the S-curve navigation controller.
What you can test right now is to decrease the vertical acceleration and increase the vertical speeds. This should give you more room to move vertically before it starts trying to slow down.
This would be worth looking into. @phinchey This was an auto disarm?
The tune is pretty good but could be improved. One of the big things to improve is the delay between the target and actual angular rates. In reviewing the log, I see over a 100 ms delay between the target and actual rates. Recently I’ve noticed that the filters on the requested attitude contributes to this delay. AC 3.6 has this filter fixed at 10 hz. In AC 4.0, the filters were broken out individually which allows increasing this filter cut off frequency. I would recommend increasing the INS_GYRO_FILTER parameter to 20 hz and use the static notch to suppress the 1/rev or 3/rev vibration depending on which one is worse. I see you also have the ATC_RAT_RLL_FILT and ATC_RAT_PIT_FILT at 10 hz. What drove you to set these at 10 hz? Depending on what you are guarding against, I would recommend trying to raise them to 20 hz. Again, the goal is to clean up the vibrations in the feedback signals using the static notch. AC 4.0 provides more vibrations suppression capability with the harmonic notch.
I noticed in the log that the roll axis shows a bit of oscillatory behavior around 1 hz. It would be good to see a log with the aircraft being flown in stabilize to see whether this behavior is being driven by the wp nav controller.
There are other questions I have on decisions made for parameter values like lowering the pitch and Roll Ang_P gains. Typically, at least on single main rotor/tail rotor configurations, I try to push the Ang_P values higher to provide better attitude adherence. I think the VFF in the roll axis probably needs to be smaller as this axis is more like a multicopter using differential thrust rather than tip path plane tilt.
These are just some of my initial thoughts looking at your log.
@phinchey I would be careful if you plan on just raising the filters to 20 hz. If you had lowered them after you completed your tune then you should be fine. But if you tuned with the filters at the current values then you may want to back off on the rate P and D gains a little just ensure you don’t get into feedback oscillations. You will probably want to retune after you change the filters anyway.
We’re still playing around with tuning and filters for attitude control based on Bill’s suggestions. Changing the acceleration and speed parameters per Leonard’s comment fixed the navigation issues. Thanks everyone!
