OK I thought that this reboot only affects a certain type. But in this case I will stay away from 3.6.9 release.
Any chance you create something with the 4servo support AND 3.6stable content (L1) as a rc1 or beta?
The rebooter can affect any board. It’s only supposed to reboot if the main loop locks up. In my case a system that was flying NuttX builds for two years, switch to a ChibiOS build an it shuts my engine down in flight is highly suspicious. Put a NuttX build back in it and it’s been fine since. NuttX might be fine on 3.6.9 as the in-flight rebooter is not enabled for NuttX builds. But I didn’t actually test that, and being commercial aircraft, I decided to stick with what I know works.
What is the difference between the NuttX and the ChbiOS builds? Which one should I be using?
Flying a Pixracer.
NuttX is the RTOS (Real Time Operating System) that runs in your controller that the ArduPilot code runs on. ChibiOS is a new RTOS that ArduPilot adopted as a replacement for NuttX, with Copter 3.6 being the transition from NuttX to ChibiOS, with both available. In 3.7 only ChibiOS will be available.
ChibiOS has been a long development project to get it incorporated into the ArduPilot ecosystem. What prompted the in-flight “watchdog” rebooter is the fact that a board locked up in flight and an airplane flew away, refusing to respond because the controller locked up. So the “watchdog” now monitors the main loop and reboots it if it locks up. With a helicopter this results in going into autorotation with a dead controller.
It was not supposed to affect boards that have an I/O processor. But after my experience with an in-flight reboot I will only fly it in my test heli - won’t use it in commercial machines yet. I didn’t realize it was enabled by default and I failed to verify that before I flew it.
So you can fly either one in your Pixracer. I built many custom NuttX heli builds for users with Pixracer on 3.5, and the px4 build for Pixracer is still available on 3.6. On 3.6 you can also fly ChibiOS in your Pixracer. The “watchdog” feature can be disabled by setting BRD_OPTIONS to 0. I can’t say what is best - I know at least one other person has had ChibiOS lock up with a heli and his heli refused to shut down. I don’t think anybody has really looked into why it is locking up on some hardware - it has just been patched at this time to prevent flyaways. But the root cause of the lockups still exists. tridge is the one that works on this and he’s very busy. But I’m sure he will eventually find what is causing the lockups with ChibiOS.
The reason I went back to NuttX in my commercial machines is because it is very mature and proven reliable. Which I need for commercial use. In my test heli that I fly for fun I’ll fly ChibiOS, as having to do an emergency autorotation now and then is good practice to keep you on your toes 
4 Likes
coming back to this older post:
WPNAV_Speed for tuning on CH6 is working for me, but a full refresh of parameters with QGroundcontrol always delivers “3000” for WPNAV speed (which is tune_high), but the calibrated knob is at ~50% and the Heli flies ~15m/s…
another question regarding Tuninng CH6:
for D gain, it does not give higher resolution than 0.001, is that correct?(my final manual setting is 0.0005)
For the D term, the tuning knob may not from what I remember but you can set it to what you want in the full parameter list. I think there is a manual entry method of entering values in QGC. So it can be whatever you want.
Hi Chris,
With L1 would it be possible to have a setting value that would force the helicopter to fly parallel // to the flight path. This would aid in optimising image over lap for mapping vs optimising for flight duration.
Also you mentioned about having another tuned parameter for speed. Would this be possible to utilise in a lookup table and mapped to GPS speed? We had this similar running on the micropilots back in the day.
Do you mean fly parallel tracks on survey grids? It already does that flawlessly. That’s what I’m using L1 for at the present time.
As with any aircraft, the faster you go, the wider the turn radius has to be to maintain the same G-forces in the turn. L1 will do this automatically while holding a constant airspeed/groundspeed. Copter Nav won’t.
So the first thing that must be understood is how an aircraft turns, and the forces and dynamics involved. All aircraft (ones that actually fly - this does not include multicopters) make a coordinated ball-centered turn by banking. As the aircraft banks, G-load increases. A 30 deg bank angle results in 1.15G. 45 deg bank is 1.4G. 60 deg bank is 2G. 75 deg bank is 3.8G, 85 deg bank is 6G. 90 degree bank is infinity - if you ever get a chance to fly in a fighter jet or a high-performance aerobatic airplane, roll it to a 90 deg bank, pull back on the stick and you can pull 20G’s if you want - but humans and airframes can’t handle those forces.
So the minimum turning radius of a super high-performance aircraft like a jet fighter is limited by its speed and the G-forces the airframe and pilot can handle. This is usually going to max out around 9G’s.
So higher bank angles require more speed for a ball-centered turn with no loss in altitude. The faster you go, the wider the turn radius.
So tune the L1 controller’s WPNAV_RADIUS for the highest speed you want to fly your heli at. It won’t use it all if it doesn’t need it. Tune the L1 turning period for the most aggressive bank angle you want it to achieve. Now, where the limitations arise is power. It takes more power to go 90kts than it does 40kts. So let’s say you have your L1 tuned so your heli maxes out at 60 deg bank @ 40kts. Your 20lb helicopter has an apparent weight of 40 lbs in that turn. Does it have enough power to take off at 40lbs takeoff weight? Does it have enough power to take off at 40lbs and fly at 40kts? If it does, your 20lb heli can make that 60 degree banked turn at 40kts. But she’s gonna be pulling a lot of pitch and the throttle is gonna be wide open in the turn.
L1 will maintain this limit you tune for but at the higher speeds it will fly a wider turn radius to do it. So the limitation is that it takes more power to go faster and now your heli may run out of power at 90kts vs being able to make that turn at 60 deg bank at 40 kts. So I increase the turning period at higher speeds to keep it within the power limitations.
The reason a lookup table won’t work is because you can’t predict how much power somebody’s helicopter has. And raw shaft power is the limitation.
L1 is really fun because it removes the Copter restraints, turns a heli loose and lets it perform to it’s maximum capability. But it’s up the pilot to know what that is.
In QGround Control (QGC) and Mission Planner (MP), there is a routine that helps you plan survey missions and you can specify the amount of overlap and sidelap for your passes. The programs have common cameras available to select which then allows it to automatically plan a survey mission with just the planned altitude, sidelap, overlap, and speed. It is very helpful in planning missions to survey large areas.
There is also a feature in the planning for survey grids (at least in QGC) for how much overrun you want on the end of a pass. What this does is place four waypoints in a “box” at the end of the run. I’ve found that L1 works better if you don’t use this. Simply set the overrun to zero so it lays out one waypoint at the end of the pass, and another one at the start of the next pass.
L1 will make a way tighter turn than Copter Nav does with splines, and it comes out on the next pass dead on target speed. So if you’re using timed shots with post geo-referencing (or real-time geo-referencing in the camera equipped with GPS), the shot spacing is much more exact with L1 than it is with Copter Nav.
If you are using a pwm camera trigger, then it won’t matter a lot.
What we’ve been using is modified GoPro’s on Time Lapse, without a pwm trigger. The GoPro has one of the fastest image processors in the business with their proprietary SoC chip. It can capture full-res, super-sharp 12MP imagery at a rate of one image every 0.5 seconds, with GSD ~0.5 cm/pixel. At 20kts we get a shot every 17 feet.
We simply trash the extra imagery we don’t need in post and geo-ref what we use based on the GPS time stamp. The GoPro’s clock has to be sync’d with GPS time to do this. But it provides a lot of flexibility in post processing of the data.
I’ve never had real good results from using a camera trigger at high survey speeds at low altitude to get the GSD. And this is where L1 shines. It covers the acres at a constant speed no matter what. So timed shot spacing is very exact with L1.
2019-06-27 09-45-13.log.param (14.9 KB)
These were the last Parameters after tuning L1 Nav.
It flew great.
but it ended up with a crash. I think there was something wrong with my uploaded waypoints. But I used the waypoint files before without issue…
here is the log file and waypoint files.
I did several tests - checked how to change flight speeds while in air without RC Transmitter.
also checked altitude changes in different speeds. this was done with first waypoint task.
final tests was a high speed task. Everything at the same altitude level.
Tuned to 30m/s WPNAV SPEED for this flight.
and it ended up in a crash… looks for me that the HELI wants to descend in that stage. unfortunately this was too fast to react… (I allowed 10m/s descend rate)
hard for to check this but maybe you can give me some advice…
Your collective pitch (CTUN.ThrO) and power was maxed out at 60kts. She couldn’t hold altitude anymore at that speed.
Only combustion engines can maintain continuous high power output at high speeds. Electric sags very quickly on voltage and will do a short “burst” at high power output. But if your helicopter is requiring 5 hp continuous to fly at high speed, with heat losses in the battery, ESC and motor and the efficiency at probably around 75% the battery has to deliver the equivalent of ~5kW. If the voltage sags to say 40 volts under heavy load that is 125 amps that have to come from the battery. At that amp draw the ESC, battery and motor go into cascade failure due to further efficiency losses, the rotor speed sags and she maxes out.
A combustion engine, however, can run at wide open throttle producing maximum horsepower continuous. And the combustion engine is actually at it’s peak efficiency and BMEP at WOT at maximum torque.
So with electric heli’s you have to keep this in mind - electric power systems can exceed a piston engine for a very brief period of time on power output. But they cannot match a piston or turbine engine for stamina and raw continuous shaft power flying at high speeds.
1 Like
@Pakman also want to add that’s a pretty healthy little 570. It looks like it hit ~53-55kts before it maxed out on pitch at whatever headspeed you were running. Those kinds of cruise speeds are in 700-800 class category
Thanks @ChrisOlson
in addition it was the warmest day this year. the engine was extremely hot after each run.
the log is from the 5th flight.
it was above 30°C.
one remark to this L1: the flight characteristics is really awesome.
with the onboard video result, I would have reduced ATC_ACCEL_R_MAX and ATC_ACCEL_P_MAX, the tuning guide recommends far too high values for this tiny class (when used as drone).
Changing speed:
it seems that there is no way to change speeds during flight while on auto mission (with no link coverage to the RC transmitter and a potential Channel6 tune for WPNAV_speed)
so what I did is use at least one WAYPOINT with DO_CMD_SPEED_CHANGE. but this needed mission modifications, upload of the mission and a manual “jump to” command, plus a manual jump to command to bring the system back on its original way.
if there are different missions with focus on high cruise speed, it is easy because I can use one single setup.
But If you need altitude climbs and descends, it is quite complicated.if you need both, depending on location, I don’t know how to handle easily.
as @ChrisOlson already stated:
Blockquote
-
you must become familiar with the maximum turning, climb and descent performance of your helicopter, as L1 is capable of pushing your machine to its limit with no holds barred
-
become familiar with the maximum climb/descent gradient you have set for your heli with the WPNAV UP/DOWN settings. You’ll have to figure this out and calculate your maximum gradients when you lay out waypoints. Otherwise you’ll end up with the same problems that full-size pilots have cruising at FL450 @ 580kts, want to make a standard “rule of 3” descent so as to not overwhelm the cabin pressurization, don’t start the descent at 500 miles out you won’t make the airport unless you pull the throttles back and slow down. L1 is the same way. Learn about climb/descent gradients and how to apply them in flight planning, as L1 will not automatically slow the aircraft to hit an altitude target.
So you can prepare a mission, but adjustmens in flight are quite uncomfortable.
The “change speed command” in mission planner does not work/ is not supported,
so the easiest way for me would be adjustments to WPNAV_SPEED parameter during flight over MAVLINK. Highest value for top cruise speed (with enough margin for altitude hold and other unknowns…), lowest value like 1m/s or whatever to focus on climbs, descends,…
That’s strange, because DO_CHANGE_SPEED works with a QGroundControl flight plan on L1 Nav. Have you tried flight planning with QGC? IMO its interface is much cleaner and easier to use than MP. There’s a little learning curve if you haven’t used it before. But once I got used to QGC there’s no looking back.
I use the Channel 6 “tuning” to set my WPNAV_SPEED on-the-fly. If you have this configured to use Channel 6 to set your cruise speed it totally ignores any DO_CHANGE_SPEED commands in the mission and obeys the Channel 6 signal. I have never lost RC on an auto flight for more than about 30 seconds - usually when the heli is turning and it momentarily shields both antennas on the helicopter. And it usually has to be more than 2 miles away before that becomes a problem. So I’ve found Channel 6 “tuning” to be the most reliable method of changing speed in auto “on-the-fly”.
L1 is a lot more fun than Copter Nav. If I have altitude change on a flight plan I look at it and go, “hey, I have to slow down a bit to make this”. Do the rough calcs in my head like you do when flying a full-size one and decide you can make the climb or descent gradient at 40kts (or whatever). So turn the speed down to that to be able to make the gradient. It’s more interactive, like programming a full-size autopilot in flight to do the same thing. Rather than sitting on the truck tailgate drinking Mountain Dew and watching it fly around, which becomes totally boring.
Total automation is fine for people that enjoy that kind of thing. But it breeds pilot complacency and dependency on it. Then when something happens like lose the GPS a mile out the pilot is screwed because he/she doesn’t know to handle the situation and get it back to the helipad in one piece. And instead stares in total disbelief while it flies away, frantically flipping the Return To Launch, which no longer works. I urge all UAV pilots to not become one of these “GPS Safe To Fly” types:
yes , Maybe I was not clear enough: change speed works as “waypoint”, but there are also “ChangeSpeed” action buttons that don’t work.
And: what If you are flying out of range of your rc transmitter? I like the ch6 WPNAV Speed tuning knob, but I miss something similar in (Q)groundcontrol under long range circumstances.
I am still switching between both Qgroundcontrol and Missionplanner, MP provides playback of telemetry logs and plot analysis of SD card recording. for tuning qgroundcontrol is much more convenient.
Oh, those. I’ve never used them, so not familiar with whether they work or not.
I guess I don’t fly out of range of the RC. Like I said, I’ve lost signal momentarily sometimes, but I don’t make it a practice to fly beyond a range where I have no control over the aircraft. IMO, maintaining that control link is critical to the safety of the aircraft, and for avoidance of any manned aircraft that may enter my operations area. Unmanned aircraft have the legal requirement to give right-of-way to all manned aircraft, which may be anything from someone flying a paraglider to an agricultural aircraft, to a manned aircraft making an emergency landing in a farm field. Without the control link, and 100% control by the pilot in command, that basic legal requirement can’t be met. ADS-B and automatic avoidance is not a legal solution because many aircraft, even after the ADS-B mandate, are not equipped with ADS-B. This includes agricultural, ultralights, paramotors, etc, all of which fly in the same airspace I’m using.
1 Like
Patrick,
Sorry to hear about your crash.
I have also noticed that the change speed request does not work in mission planner. I will have to try that in QGC. That might tell us whether it is a ground control problem or a arducopter problem.
Thanks again for testing out L1 nav.
QGC doesn’t have that. It’s got Plan (takes you to the flight planning screen), Land, RTL and Pause buttons on the main flight screen. I have never used those, but I assume they work.
Normally when I have to come in to refuel I break off the flight plan in a turn by switching to Pos Hold to let it brake to a stop. Then switch it to acro and fly it back home and land it to refuel it. As long as it is not disarmed can restart it, take off, fly back to the mission, go to auto mode and it will pick up where it left off.
I have the telemetry from the ArduPilot system on my RC, so I don’t actually really look at the ground station much, except for pre-flight and to load a new flight plan.
Is there a minimum speed that the L1 Nav will work? I tried 5kts and 2m line spacing with recommend setting but it was pretty ugly.