Ah, I see. You’re building the code yourself (not using the custom build server) which means you can use “git checkout Copter-4.4”. Alternatively you can use “git checkout ArduCopter-beta”.
It seems antiGravity works pretty cool, 4.4.0-beta2 (commit ID: 07f11531fd )
Detailed info, please check link below.
1 Like
I can confirm KDEcan is working with this release.
Correction- I got to the field to do some testing and it’s not seeing any of the ESCs. Going back to 4.2.7 which is the last version that works.
OK, thanks for the report. I’ve added this to the 4.4 issues list and I hope that TomP can help us investigate the issue.
Actually it looks like TomP’s KDECAN rewrite did not make it into 4.4. If you’re feeling brave perhaps you could test “latest” instead? I’m not sure if you’ll actually want to fly it because “latest” changes each day and sometimes contains bugs but a bench test would be very helpful. It’s possible we may be able to backport this to 4.4.
1 Like
Tom and I chatted on the discord a bit. It does work with the nightly build. I flew a bit without any issues. If it’s possible to backport it to 4.4 that would be very helpful as I have a demo coming up soon. Thanks!
I got out last night right before dark and managed to fly a few batteries. This log here is a 6" pixracer that I tried the yaw dterm autotune on and had no joy getting it to work again. There was little to no wind and I let it run quite a while but in MP is never got above AutoTune: Yaw(D) Rate D Up 0%. Here is the tlog for that flight in case it was useful. I also had a little short radio failsafe on crossfire that cleared but it does to me seem that once I have my radio turned on and crossfire connected mavftp will always fail repeatable multiple times on whenever you connect the battery while having the radio transmitter on. I also got a gps unhealthy the whole time which is the first time I have had that with this quad and I had multiple times where my gps lost contact on testing rtl as can be seen in the above posted log and tlog/log. In general things seems to fly well! The issues with gps can be due to constellation and it seemed the loss of gps on rtl almost always happened at pretty darn close to the same location each time. Who knows I was flying in the LANNC waiver zone (with a valid waiver) right on the approach to our airport runway. I normally fly a lot in uncongested areas so this was my first time with a lot of interference plus one of the hospitals main radiology department is about 1/8 mile from there. Here is another log where I tried autotune but didn’t let it run to long as I think I had a failsafe with the EKF and aborted. And the last log is just me generally flying around and messing around.
I took two quads to fly but did not try autotune on the second as I forgot a antenna for my ground station and I like to monitor it via the messages screen. MP was not wanting to play well with UDP connection and the pixracer wifi module so I didn’t run atuotune. But wanted to test it on the latest beta and didn’t see and issues although I didn’t give it a good workout as it was getting dark, log attached here.
Both quads are 6" with pixracer and tbs crossfire on 6.19. I didn’t get as much of a chance to fly everything I wanted as time was constrained. Also if anyone has any feedback on the notch filters I have enable I am all ears. I will give the new FFT tool a try see what I come up with but this is not a strong skill of mine that and log analysis hahaha!
1 Like
@Leonardthall thinks that YawD might need a non-zero starting point - I haven’t had a chance to test as yet. But you could start by setting it conservatively to something like 0.001 and then try again.
So I would need to set the ATC_RAT_YAW_D to 0.001?
Yes, exactly
More words
1 Like
@andyp1per When I autotune yaw D do I have to previously set ATC_RAT_YAW_FLTD equal to the other axis FLTD or do I leave it at zero?
You should start with it set to the same as the others. So definitely not 0.
Makes sense! I did not see any info about setting that parameter (which is default at zero) so I thought it would be better to confirm. Thanks
Strange things happened with booth versions- 4.3.5 and 4.5.0 from custom build server.
We have in some points GPS loss.
But not total- from 20 sats I have 11-13 and HDOP up to 1.2.
And I have gps or compass glitch, EKF variance, Althold.
But GPS pos is ok, Nsats ok, hdop ok.
If I leave copter in Althold for 10-20 sec- I have “Glitch cleared” and I can switch to Loiter for long time.
When I try to fly again- I have in few sec Glitch- Althld again.
Ok. No problem. I see in log abnormal speed “pulses” so EKF generate Glitch.
But why in same area and same time I have no problem with RTL???
Copter just flying home without any errors.
I tested lot of times. Forward fly in Loiter stable ALthld and even DeadReconig started. Back flight in RTL -no problem.
I tryed relax EKF.
In fact I make copter stronger to variances and innovations.
But it doesn’t fix this strange.
Also who can help me switch off Compass realighment in fly?
I switch off compass calibrating in flight, in EK3 Compass YAW reset… it looks like I switched off everything about.
But first I see copter YAW rotation, compass changed course, after that “GPS or Compass error”
I know that it’s GPS error!
How can I say it to AP?
How I can say "if you see GPS or Compass error- be sure. It’s GPS. Leave compass alone! 
My GPS is unthrust usually.
So compass and baro are 1-st priority in flight.
And it’s very bad that I have “Emergency YAW realigned” - I flying 83 deg course, after realign I have course 186… WHY???
I can’t have a thrue compass?
I make Comp-Mot calibration and adjust it manually. So at any copter movement in Althold (bigger curent and interference)I have up to 1-2 deg short term deviations only.
And wnen I fly in good GPS area- I can do anything with copter- no variances, no errors…
What you describe is not an issue related to the firmware versions, or at least highly unlikely.
You should probably start your own discussion instead of continuing this in the 4.4 Beta discussion.
A .bin log would make it easier to identify the cause.
GPS glitches are not necessarily an issue with the GPS itself, but more a disagreement about position and heading. High vibrations, poor HDOP, poor compass calibration or interference can all cause that message.
HDOP should be below 1.0 to be good, typically 0.8 to 0.6
Ensure your current sensor is accurate (and voltage) then do a flight with circles and figure 8’s and some up/down throttle. Then we can use Magfit to refine the compass calibrations.
You right about wrong topic.
Sorry about
Hi All
I’ve just loaded beta v4 in an attempt to get serial passthrough telemetry going.
Setup is as per below:
Pixhawk fmuv2 board
Radiomaster TX16S
TBS Crossfire Micro Tx V2
TBS Crossfire Nano Rx
Mission Planner Settings:
RC_OPTIONS = 288
RSSI_TYPE = 3
SERIAL1_BAUD = 115
SERIAL1_PROTOCOL = 23
I am able to do Radio Calibration just fine, ie, I can fly the drone but when I go to detect New Sensors, I get only the 13 “default” sensors and no GPS sensors.
Is this part of the bug * Serial passthrough fixed or am I missing a setting somewhere.
Hi @gbubb,
Serial passthrough is described here on the wiki but the short-form explanation is that it allows easier configuration of some sensors and devices (e.g. GPS, gimbal, etc) by allowing an external non-ardupilot configuration program (for example UBlox’s ucenter) to pass whatever serial data it wants back-and-forth with the sensor.
I guess the “detect New Sensors” must be a page in the TBS Crossfire telemetry system? I wonder if maybe @andyp1per knows about this.
FmuV2 is feature limited for CRSF telemetry.
What actual flight controller do you have?
Thanks @rmackay9 and @dkemxr for the feedback.
The “detect sensors” is actually a feature of the Radiomaster TX16S transmitter.
Dave, excuse my ignorance but I’m not 100% sure which board it is. I think I saw QGC showing it as PX4 but I am not convinced. It is a RadioLink Pixhawk. Is there a way I can check within QCG or MissionPlanner to see the exact board and version?
Hi @gbubb,
This can be seen in the banner which is displayed whenever the ground stations requests the full parameter list from the vehicle. This is an example of the banner displayed for one of my copters… so it’s a CubeOrange running ArduPilot-4.5.0-dev.
In general we don’t recommend the RadioLink flight controllers and there are some warnings on the Radiolink MiniPx wiki page here.