Wohoo looks interesting. Can’t wait to test it.
Does it combine with the 4 servo swash plate firmware?
@Pakman as of this morning the L1 Navigation feature is available with four-servo swashplate support. Follow the link above.
This is built on Copter 3.6.9, so please pay attention to the “watchdog” stuff, the bad IMU support for Pixhawk Cubes, etc. that was dumped into what was supposed to be a stable release after Copter 3.6.7. Personal experience with this new in-flight rebooting of your controller with ChibiOS says it is not a real impressive “feature” in Copter 3.6.9.
There is both NuttX and ChibiOS builds available - NuttX does not have the “watchdog”.
The L1 Nav support will soon be in ArduHeli-stable, which is built on Copter 3.6.7, as soon as I get it merged.
1 Like
thanks for this quick support.
so should I better start testing with the Nuttx release? (I am still using profiCNC CubeBlack on my testbench)
btw: will the ArduHeli-stable release also support 4 servo swash plate?
It’s not planned at this time because there was a significant backport for 3.6 four-servo support, and the swash setup breaks the current Heli setup page in QGroundControl due to parameters that appear and disappear based on swash selection.
For stable release for commercial operators we need the heli setup page to work.
Chris,
Does this mean we will finally have ArduHeli as a standalone branch without all the copter nonsense?
I did some test flight with 3.6-L1 today in 550sport goblin.
The navL1 works awesome.
It flew 30m/s like a charm. See some overshoots but tuning is not finished.
I was confused: the tuning knob seems not to actualize when refreshing parameters. But it reacts accordingly (wp nav speed is tuned from 0 to 30m/s)
Patrick,
Glad to get some feedback on L1. I hadn’t done much tuning either and I have noticed an initial overshoot on speed. After it locks in, i didn’t see any big transients but I only tested it at 15 m/s.
Please post your settings once you get it tuned to your satisfaction. As for the update of the wpnav speed, I will have to look at that. I am guessing the parameters updated when you did this with copter nav. I’m not sure what would be different to keep it from updating the wpnav speed.
WPNAV_SPEED will not update on-the-fly in your GCS. The parameter list has to be refreshed every time it changes. MavLink does not do this on-the-fly.
The ArduHeli builds are already there so we can fly new features on the current stable code, while being independent of what Copter does. The ArduHeli concept was something I dreamed up a couple years ago, as we have complete control of what goes into it for new features we have developed and tested. It is what makes it possible to fly new things like the governor, L1 Nav or the Vbar acro on Copter 3.6 without having to worry about when the next major release is coming out that will have these features. And worrying about how many bugs is in the new Copter release, that are totally not related to heli, in order for users to fly these new features.
ArduHeli is called a “fork” of Copter that is specific to helicopters. All open source projects develop forks with time, such as Ubuntu linux being a fork of Debian.
Blockquote WPNAV_SPEED will not update on-the-fly in your GCS. The parameter list has to be refreshed every time it changes. MavLink does not do this on-the-fly.
well I did see the changes in the previous version (3.6.6 4-servo swash plate). I hit the button tools/refresh, took some time, but afterwards the changed wpnav speed was visible…
qgroundcontrol AND missionplanner…
for test results:
I did figure-8 runs. first accu with L1 deactivated for plausibility checks, and to reapply some parameter settings.
then L1 activated and I was completely excited.
unfortunately I had no internet access and no notes with me… so I was completely blind while “tuning” parameters… or lets say I was changing parameters and observing behavior…
EDIT: the firmware was “ArduHeli-3.6-L1Nav-CubeBlack”
Very good. We have rain here today so working on the next version of the heli setup in QGC. I need to fix some things we did in a couple commits that make the heli setup not work. But after I get that fixed I’m going to see if I can get the L1 tuning settings incorporated into the heli setup in QGC.
The reason I want to do this is because L1 is specific to helicopters - it is not implemented for multi’s. So one difference between Plane and Heli is that Heli has the capability to fly a wide variety of speeds on L1 Navigation. Planes are more limited because they eventually stall and fall out of the air if you slow them too much. So right now, I have my L1 tuned for flying 20kt survey flights. But I might want to load in a flight plan for a 50kt long-range flight and this takes different tuning for the turns. Having these settings handy in the heli setup will allow click, click change the settings where it’s handy, and bingo - she’s set up to fly my 50kt flight.
So I think we can get a L1 Navigation tuning category in the heli setup in QGC that will make this very simple to do (after I get the rest of things fixed up so it’s compatible with the heli setup). @DonLakeFlyer and @LuisVale were very helpful in getting us that first heli setup in QGC. Now we want to make it awesome so this can be done from your mobile phone or tablet on-the-fly in the field with no hassles.
If you put L1 in QGC, will that cause problems for the versions of copter that are built without L1. I’m really not sure that we will get L1 into master.
@ChrisOlson let me know when there is an updated qgroundcontrol station.
@bnsgeyer this L1 upgrade is really awesome.
do changes in ATC_ACCEL_Y_MAX affect the NAVL1_TURN_SF?
what parameter does affect the aggressivness in turns, lets say maximum bank angle? there were spikes with almost 60 degree. but no continous bank with >40degree
L1 will be in the ArduHeli builds regardless of what happens in master because it’s gonna be a VERY popular feature. So if it never makes it into master I’ll build a custom build of QGC for it.
This is all open-source software. We are not restricted to what somebody THINKS we should have. We can have what we WANT to have.
3 Likes
Anything that tunes the yaw axis for stabilize mode will affect the response of the yaw axis in L1. L1 just makes yaw rate requests to the attitude controller.
The L1 damping and L1 period affect the aggressiveness of the L1 controller which is accomplished thru the bank angle. The L1 computes the yaw rate request based on the bank angle. The yaw rate request is modified by the navL1_turn_sf parameter to give more or less input.
1 Like
You want to stay with 0.8 to 0.9 on the damping. The dictates the overshoots you will see on capturing a course. The period will dictate how tight the turn will be. However they do interplay some.
Make sure you set your WPNAV_RADIUS to the distance your heli flies in two seconds. It won’t use it all if it doesn’t need it, but this affects how the heli makes the turns.
Well, we now have L1 Navigation in ArduHeli Stable. I finally got around to dropping into stable and test flew it late this afternoon. It works great. This build is based on Copter 3.6.7 so it does not have the Cube IMU “hotfix” and watchdog stuff in it for folks who don’t want all that extra code bloat, or an Automatic In-Flight Rebooter in their controller. There is both ChibiOS and NuttX builds for PX4 V1 thru V4.
- The PX4-v4 build is NuttX for the Pixracer
- The PX4-v3 is NuttX for Cube, CUAV v3’s or any other v3 spec boards
- The PX4-v2 and v1 is NuttX for older Pixhawks or other boards designed for the v2 spec, or v1 if it has the 1MB flash bug
This new ArduHeli stable build also changes two of the governor parameter names to be compatible with 3.7 (when it comes out). The governor rpm setpoint has been renamed to H_RSC_HEADSPEED and the throttle curve gain renamed to H_RSC_GOV_TCGAIN. This will not affect anybody flying the governor in their gassers - the new name of the params will automatically update without changing your settings.
2 Likes
will definitely test this. I will switch from 3.6 L1 to this stable release with my CubeBlack.
Do you plan something similar with 4 servo swash plate-support?
I didn’t want to do this in the Stable because the params changed and it breaks functionality with the ground station setup in 3.6.
OK understood,
to summarize:
Standard swash plate config: ArduHeli-3.6 Stable Release 3.6stable
- full qgroundcontrol support
4 Servo Swash plate: ArduHeli 3.6.9 3.6.9
- limited ground station support
- not ok with CubeBlack
- but OK for CuavV5 ?
Patrick, I don’t know for sure how that IMU “hotfix” affects the CubeBlack. From what I understand there was defective boards built in those from Jan 2019 that could cause the IMU to fail in flight. The IMU is supposed to switch over to the next one if it fails, but I have no clue what that does to the attitude solution. So I don’t trust it. Nor do I know how they are detecting the bad IMU.
All my commercial heli’s have CUAV V3x controllers, which is the same hardware as the Cube, but it doesn’t have the problem with a bad PCB. Since I fly those in my commercial heli’s I did not want something I haven’t tested, nor do I know how it works, in my commercial machines. That’s why I stopped ArduHeli stable at Copter 3.6.7. I already had an unwanted autorotation from auto flight mode running the newer code due to the system in-flight rebooting. This is not fun. So I reverted ArduHeli stable to a codebase I know is reliable. On the newer code I had GPS problems, logging problems, in-flight reboot causing an emergency autorotation - can’t go there flying commercial machines.