Copter-3.6.0-rc1 available for beta testing

@JoeBreznai auto tune changed for this release, so a faster process is quite believable. (If you redid autotune under the normal PX4 based build you should see the same speed level).

@WickedShell, Thanks for that info on auto tune.
Guess that’s what happens when you compare apples to oranges!
I intend to switch back to NuttX to check the " Bad Gryo" messages. I didn’t see them before when testing 3.6.0 rc1- under NuttX, but I want to confirm that.
Joe

Could not do the ESC Calibration as the Safety Switch could not be invoked.

Thank you all for this good work.

I noticed also that ESC calibration doesn’t works, as the safety switch remains blinking even if we press it.
This happens with the ESC calibration through MP, but also with the “old” method.

Cheers

@rmackay9, after all resetting to default my Pixracer, installed latest beta, everything ok, but when I open Initial Setup… Battery monitor, I have the message Set BAT_AMP_PERVOLT failed.
Don’t know if it’s my fault or beta, but before I was able to setup this correctly.
BattAmpPerVolt

This is simply because the parameter name has changed in 3.6 and Mission Planner has not caught up. Functionally it’s still works as the values you had previous to updating were transferred. If you want to change this value do it from the Full Parameter List BATT_AMP_PERVLT (note the change?)

BETA 3.6.0 rc-1 on Pixracer FENCE Problem.
450 Quad, Mro Pixracer.

Flown 3.6.0 rc-1 Nutxx version for 15 flights and 20+ flights using ChibiOS build, with no issues until today when I tried FENCE settings for 1st time.

Started with ChibiOS build and had issues with Fence not working correctly. Tried using both Beta MP and with Stable MP build, under both NutXX & ChibiOS builds.

Setting up Fence with Polygons in Beta MP ( 1.3.26 build 1.3.6672.5419 ), under ChibiOS, got odd fence boundaries’ after uploading. MP reported "invalid Fence Boundaries’: Fixed by redrawing Boundaries’ as it kept putting “home” point outside fence on setup, and quad wouldn’t arm giving the “Polygon Boundary Invalid” message.

Thinking it might be a Beta MP issue I removed and reinstalled Stable MP ( 1.3.56 build 1.3.6672.30243 ). Re-did Polygon insuring it included my power-up point ( different from Arming location) was within fence area as well just to be sure that wasn’t the issue. Made sure the “Return Point” in Fence was within Boundaries.

Quad just blew past fence.

Loaded NutXX version of 3.6.0 rc-1 and using Fence settings “Alt & Circle”, Quad would hit fence and stop, with 0 set as action. With Fence action set to 1 ( RTL ), quad stopped at both ALT and Distance, but it did NOT “RTL”.

Manually invoking RTL by Ch7, and RTL worked OK in both Nutxx & ChibiOS versions.

Tried many combinations of Beta MP and Stable MP, with NutXX or ChibiOS Beta loaded, with different fence action setting with same results.

Maybe I am doing something wrong, or this an issue with the Beta Software being incompatible with Both MP versions, but I have set Fences before
on stable versions of Software and this same hardware and all worked OK.

Hope this makes sense, but I am out of ideas - and confusing myself - after spending a couple of hours on this this afternoon.

Perhaps someone can check actions the Fence under this Beta, or give me a pointer if I am doing something wrong Or confirm that something is still “off” or out of sync with MP and this Beta software.

Current logs are too large, if needed I can redo flight with shorter time.

I am planning on loading 3.6.0 rc-1 on my Pixhawk 2.4.8 quad later, but weather may prevent fling today.

Thanks,
Joe

1 Like

3.6 RC1 on Ph 2.1 Crash
I flew RC1 on my DIY quad (Ph 2.1, groundfacing Lidar, IR-Lock) and ran into the following problems:

  • SmartRTL: Copter comes back always about 1-2 meters lower than the original flight path. Since I was flying at a hillside, the copter would have crashed into the hill each time if I hadnt switched back into normal flight mode on return.
  • newLoiter: the copter is heavily oscillating on roll axis and is basically not flyable. It appears like all PID settings are screwed - see log. (on 3.5, everything was perfect with the old Loiter). Interestingly however, the copter flies perfectly fine in PosHold and Stabilize. What can cause this? Does NewLoiter require a new tuning?
  • Land: the copter goes straight down at full descend speed w/o going into slow descend as before with 3.5. A failsafe land due to low battery finally let the copter crash on the ground. (see log)
  • minor issue: SmartRTL is not reported in the log browser (I guess thats because MP is still behind the new 3.6 functionality)

Log:
https://1drv.ms/u/s!AnKeW8KMoCcyk2tMqk8FuiuoAaXJ

One observation in the log file for me is that there is always an offset of about 2 meters in altitude between the baro readings and the rangefinder readings. The setup and parameter settings are unchanged since 3.5, and everything was perfeclty tuned before.

Several flights on my Solo with 3.6-RC1 this weekend. It sucks only have one solo and one charger. The rest of my fleet and equipment are in storage from the fire. So a little slow going.

  • Mostly tuning in the new loiter so far. I found backing the accel values down a bit made for smoother performance. I think I have accel at 175 and braking accel at 200. From 30mph, it slows to a stop quickly but gently. The maneuver isn’t even noticeable on the camera. With the old loiter, that hard stop was very noticeable on camera.

  • I used the new LAND_ALT_LOW parameter to take it down to about 15 feet instead of 30. Speeds up the landing process significantly. Good thinking on that parameter. I’ve always wanted that but always forgot to ask or PR it myself.

Tested chibios on my beater quad noticed compass call startup finished and failure sounds are not working. Also for others the new battery failsafes parameter need to be checked. I’m using 4s all the defaults are set for 3s. I had to re set them all correctly.

That’s always been the case. The defaults are just that… defaults. You need to set them for what you’re vehicle and use-case requires.

@rmackay9 Fantastic news! I am particularly interested in testing the winch for lowering packages. Would you provide any information on that? What kind of winch/device should we use? Best :slight_smile:

Tested the latest in beta tonight (May 3 22:30) on my Skyviper and nothing worked. I couldn’t even get it to Arm. I switched back to the SV firmware and had no issues. The messages I was getting were the TMODE messages. I’ve attached the log. I’m wondering if I need to do a “Reset default parameters” on the APWeb, because I also got a battery failsafe warning at 3.9V. Battery is only 3.7. I thought parameters weren’t suppose to be updated on firmware updates. Maybe because there were a lot of new paramaters?

When i switched back to the SV firmware all my parameters i had set were in there…strange.

Log: https://drive.google.com/file/d/1cUVRM_tcmbg9bXgLIoOLBFJQEb0MCvdD/view?usp=sharing

Then I switched to “master” (which i was already flying from a few weeks ago) and I could get it to arm and fly, but it kept losing Bind with the transmitter after a few minutes…

Really the defaults should be turned off, and set every time, however older versions of copter shipped with the 3S numbers, and changing it at this point would break a larger number of users.

Today I load chibios onto Pixhawk 2.1 and had some strange behaviors.

relay switch does not work
motors connected at Aux-ports doesn’t run smooth some kind of short zero input value
tested with oneshot125 and Dshot at kiss 32a
changing flight mode doesn’t work well, stabilize to althold good - but was not able to go back to stabilize
with Nuttx it works
Oneshot at Main or Aux Ports - Motor smooth
Relay at Aux 6 good

@rmackay9 @ChrisOlson

After about two weeks of testing, I used the CUAV Pixhack nano + Kbar 5.3.4 Pro configuration on my T-rex 500Pro DFC in my spare time, in Pix+FBL mode;And in another T-rex 700DFC Using the configuration of the CUAV Pixhack V3 above, it was very embarrassing to test the flight performance of the latest 3.6rc1 FW and it felt great overall.

The new Loiter model is really good, the maneuver is very agile, the loose rods stop immediately, Loit-related parameters are also very effective. In the forward flight route, it was discovered that during the forward flight, the rudder was operated and the aileron was linked to achieve a beautiful arc turn. This was also the case in the Poshold mode. The rudder turn would not be operated as before, and the aircraft would have to use inertia. The side drift is very far.

Then, at the same time bring two problems:

1.In the Loiter mode, the Pix+FBL system operates the rudder to perform an in-situ spin. After 2 or 3 laps, the aircraft will seriously nod forward and backward, rather than a stable level of spin. Is it caused by rudder operation linkage? If it is not in the front flight, the operation of the rudder is still linked to the aileron, it is not suitable, and the aircraft cannot rotate steadily. I don’t know if it was caused by the spin correction that comes with the FBL system. I need to test and verify it under the standalone Pixhack system.

  1. or Pix + FBL system, under 3.6rc1 FW, Acro mode, after the power self test, the swash plate will be severely tilted to the right and back. Switch to stable mode, the swash plate will restore a certain level, but there will still be a certain degree of tilt. When this causes manual takeoff, pilots must make timely corrections to take off safely. I tried to close Hover_Roll to 0, and the problem still exists. And this problem has not occurred on an independent Pix system, is it also caused by the FBL system.


It is likely some sort of piro compensation in the FBL unit causing this. I have done numerous full-stick piros with ArduPilot/Pixhawk with no problems.

Roger that!

I also suspect that this may be caused by the “self-rotation correction” of the FBL system. Let me do another comparison test.

Thanks, Olson

Skyviper in master Issue opened and confirmed here:


thanks khancyr

Hardware bug Nuttx: Retractable legs disabled when using 3.6-rc1 on Octo build. switched back to 3.5 and it works I even moved to a new aux but no dice.