Hi Rob,
We got the GX9 to 32m/s maximum speed in AUTO today. Logs are here:
http://uav.tridgell.net/GX9/2016-04-25/30.BIN
The final step to getting rid of the pull-ups in the turns was to reduce ANGLE_MAX. It was at 30 degrees previously, and at that angle the motor starts to really bog down as it tries to hold altitude at maximum collective. By reducing that to 22 degrees it flew much more smoothly and had much better turns.
We think we can get a bit more speed by tuning the engine a bit and fitting a new carbie that should generate a bit more power.
We did have a problem during the landing approach. The heli was tuning for high speed runs with WPNAV_ACCEL at 900. On the low speed landing approach at 4m/s it started overshooting the desired position as it used too agressive accelerations. It ended up backtracking a bit while approaching the landing point and we switched to stabilize to land it.
Getting the right tuning for both high speed flight and gentle landing approaches is something we need to work some more on.
Cheers, Tridge
Fantastic Tridge!
Yes, I definitely think this sort of operation is not handled optimally in the current code and needs improvement. It should not require so many tweaks and tuning to nudge it up to these speeds. Particularly such high Accel values and low Angle Max values. But for now, itâs a really good result.
Rob
here is a video of the flight:
Leonard has pointed out we werenât using all that accel value, and it may have done better if the ANGLE_MAX had better matched the WPNAV_ACCEL. It should have been around 390 for WPNAV_ACCEL to match a 22 degree ANGLE_MAX (Leonard told me it is 9.8*tan(angle))
Weâll try again next weekend with a lower ANGLE_MAX and see if that helps the landing approach.
Perhaps WPNAV_ACCEL should be automatically lowered to match ANGLE_MAX?
Hi Tridge,
That might be a good idea. I will have to have a look at that and think through the issues.
I see no reason why you should have to restrict Angle-Max in order to have it perform some WPNAV_ACCEL value. That would tell me that something is not optimal with the controller.
If you restrict angle-max to make Auto work properly, you risk underperforming in the wind, and reducing your ability to panic brake in an emergency, and since the angle-max is now âroundâ instead of separate roll and pitch numbers, you will limit your ability to go around corners at higher speed in the future whenever we get velocity feed-forward in the future.
Oh, I just realized what youâre doing. Youâve got a huge WPNAV_ACCEL of 900 to try to get the helicopter to go around the corners without slowing down. But then restricting the AngleMax to prevent it trying to accelerate too quickly forward because it doesnât have enough power.
What will happen if you try to decelerate with a tail wind? Wonât it overshoot badly? Or accelerate into a head wind, it will underperform the accel target.
Rob,
We are restricting ANGLE_MAX to 22 degrees as the heli canât maintain altitude at beyond that angle with the current max collective and engine power. This would be the same no matter what the wind is.
Iâve just pushed in a change to automatically reduce WPNAV_ACCEL to match ANGLE_MAX:
the navigation code has an issue where if the accel implied by ANGLE_MAX is lower than the accel given in WPNAV_ACCEL then the vehicle will backtrack when flying waypoints. The simplest fix is to reduce WPNAV_ACCEL to the level implied by ANGLE_MAX.
Cheers, Tridge
Hi Tridge,
Nice demonstration here. Very very nice looking turns in the logâŚ
Looking at it, I can see that your PIDxâs P, I and D are set to 0. Are you using the external FBL configuration? What version of Master were you using?
Best,
Nicolas
Very cool,
I canât seem to get one of my electric heliâs to go over 12 m/s even though in stabilize it has no issues with flying at 25 m/s.
Also, how do you get the heli to use a waypoint as a pass through like the plane, instead of stopping at every waypoint? Is there a different type of waypoint we can use so that the heli wonât stop and then continue?
When editing tasks, use the âcurve Waypointâ Edit task will achieve smooth, consistent, uniform flight path!
@nicbk117, yes, weâre using a skookum 540 for rate control. The exact branch we flew is in my tridge/gx9-heli branch.
What way, be able to use a single connection Pixhawk sbus of sbus out to FBL system (Vbar, SK540 / 720) of sbus in it? Which parameters need to modify it?
@zhangsir, we just enable SBUS out with BRD_SBUS_OUT. We set it to 150Hz frame rate.
The only other issue is the Skookum canât remap the channel ordering to match ArduPilot. Skookum wants throttle on channel 3, collective on 6. Weâre using this nasty hack patch to fix that for the moment:
that just swaps channels 3 and 6 in the HAL layer. Iâve been meaning to do something nicer with a parameter.
You also need to set H_SWASH_TYPE=1 to use the H1 type swash, as that is what these FBL controllers expect. And you need to set it as a flybar heli too. You then just use VFF and set P, I and D to zero.
Thank you for your timely reply to meďź
I set enable SBUS out with BRD_SBUS_OUTďźBut still can not be successful drop sbus out into the output signal FBL Kbar Lane, (Kbar the RXC support sbus input), I can only connect with ordinary FBL Kbar independent channel mode
In the photo it looks like you donât have the SBUS output port of the Pixhawk connected. It is the one next to RCIN, marked SBUS. Did you test that one?
Yes, I did not use sbus connection, because I try to use sbus connection FBL but failed, so had to use ordinary single-channel corresponding connection, I do not know where the problem occurred!
what is Curve Waypoint? you mean Spline waypoint?
I donât see any option for curve waypoint.
if you post a link to a tlog showing an attempt to use SBUS pass-thru then I may be able to spot the error.
When debugging it can also be useful to have either a logic analyser or a SBUS decoder that you can attach an ordinary servo to.
Yes, that Spline waypoint. Iâm sorry I do not express clear