I confirmed that gimbal is flashed to 3.4
Just for experiment - I set rate mode to 15deg/s, and applied max value on rc channel assigned.
It took 12s to make 180deg pitch travel (as expected), only it was in 12 steps - 1 per second 
It looks like that: https://www.youtube.com/watch?v=3-5cJSAWQeM
When PWM control is used, it is perfectly smooth.
A bit of investigation, and…
adding that:
That fixes issue with smoothness for me. Not sure why, I am too lazy to investigate to root cause.
Compiler optimization? Some C++ convoluted thing… no idea, but works.
Initialization still takes 60s for some reason (unless some control is applied and it swithes into targeting mode).
After fix, rate control 15deg/s: https://www.youtube.com/watch?v=Jz-gBOdMVX8
I upgraded to 4.6 beta 4, and just noticed in mission planner I am getting messages that say “Sending unknown message (45)”. Very similar to whats reported in this post as well:
Here’s a quick screenshot from Mission Planner. The copter is just sitting on my desk in a basement, so I expect the GPS position, etc to be bad, and I also had the controller off.
I didnt pay attention to see if I was getting this same issue in beta 3. I’ll take a look later and try to downgrade firmware to beta 3 or 2 and see if it is still there, but I wanted to mention it while it was on my mind.
This is a cube orange plus with custom firmware built from custom.ardupilot.org. When I built that firmware I added OpenDroneId under the Ident section, and under the rangefinder section I unchecked several of them to allow the firmware to build. Heres what I unchecked under the rangefinder section:
Thanks!
Just tidying this up for future readers; fix was merged here: AP_Proximity: LD19/LD06 data length sanity check fix by boa-pe · Pull Request #29375 · ArduPilot/ardupilot · GitHub
Thanks @Adam_Borowski
Hi @Tim_Archer,
thanks for the report re the “unknown message (45)”. It is due to a new version of MP being released with better video support that has triggered this message. It’s innocuous but of course annoying. I’m sure we can get a fix into -beta5.
FYI @robertlong13
Hi @Adam_Borowski,
Thanks for the PR, we will test it. I guess you’ve tested with the beta build installed by MP or QGC (or downloaded directly from firmware.ardupilot.org)? I just want to be sure that you didn’t only see this issue when you compiled the code yourself.
Yes. I have this issue with beta4 installed through MP. Also I checked that with latest master I build myself before this small change and after.
I suspect this is somehow caused by some convoluted behavior of implicit type conversion for switch. Tried to find quickly where this enum is defined, but I did not setup proper debug session.
I am testing on Matek H743-SLIM, perhaps this is that particular hardware related.
I just did simple test, as I suspected that resend_now is not set properly, but the only way that happening is switch falling into wrong mode, or default. So i just added this to default and that immediately fixed the issue, that is why I went this direction.
However that might need some proper debugging in the future, as this getMode is used same way in other gimals code.
Would be nice to get some confirmation this is actually happening, but not sure how many people can actually test it.
Neverthless, change is very minor and I would say very low risk and seems to be fixing this issue on my desk.
Also for future reference - without this change initialization takes 60s and You can do nothing with gimbal during that time. With this change initialization also takes 60s to get default mode applied, but onece you touch rc control and cause it to switch into targetting mode it starts to work earlier than this time period.
BTW - I also validated by setup by building beta4 myself and comparing hex file with the one I downloaded from firmware.ardupilot.org and the hex files are identical.
I did some additional testing and for sure beta4 is not working correctly with my gimbal, but… there has to be something that fixes that issues after beta4 release. I just build master without this small change and gimbal works fine, reverted to beta4 and 1s refresh issues is back. Sooo this “fix” is not the factor. I fixed it for me, as I was just not building beta4 but master testing it.
With this change or without it HEX files are identical, so I did not make sense. I had to check it.
Conculision some change after beta4 release fixes that issue.
I closed PR as nor required to fix anything.
Hi, am facing problem in Obstacle avoidance.
Arducopter Version 4.5.7 Obstacle avoidance radar sensor is UAV - R21F using CAN 12-HUB.
Board is CubeOrangePlus and using for Hexacopter. It works fine with Arducopter 4.4.4 but having problem in Arducopter version 4.5.7
I am getting PRX1 NO DATA ERROR.
Please send me the List of parameters you have configured for Arducopter V 4.5.7
You do realize, that parameters configured for my LD19 using serial port are totaly not relevant for Your setup using CAN?
Thank you so much for the reply. Yes right but atleast I can get some Idea from your parameters. Any suggestions from your side are welcome.
Thanks again
Do not want to be mean or something, but… google-> UAV - R21F → First search result: Obstacle avoidance with UAV - R21F
Did You try something from there?
Hi @developer123,
I’m not sure that ArduPilot officially supports the R21F radar. I don’t immediately see it on our rangefinder page.
I do see a discussion here though with links to some setup information.
It looks like the sensor’s output was written to be compatible with the TerraRanger Tower (e.g. PRX1_TYPE = 6) using a serial protocol but there’s also apparently a CAN interface.
Of course we’re always happy to support more sensors from more manufacturers but we probably need a bit of work to get it officially supported including creating a wiki page.
Apologies if I’m misunderstanding something
FYI @Adam_Borowski, @fandelxin
Yes I tried it but the result was the same.
Thank you so much for the reply. I appreciate it. I tried R21 video from the above given link but it does not work for me. Even I did not find it in the Rangefinder list.
please share with me if anything you find regarding this.
Thanks you again.
Not sure if it’s a firmware problem or just old MP limits, but you can get some parameters learned that are out of MP limits on first flights.
I got MOT_THST_HOVER like 0.1930 while MP limit is >0.2
Old MP Limits. Common to have MOT_THST_HOVER that low.
Two things to know about this. One is as @Allister said. Those limits are only useful today to detect a fat finger input mistake.
The 2nd is it will not learn a MOT_THST_HOVER below .125 If you have a craft with a thrust/weight that is below this (common) then you should set it manually from a log at hover and disable learning.
Thanks @Paul_Paku, @Allister, @dkemxr,
Thanks for the report and discussion. I’ve added this to the 4.6 issues list and we should be able to update the limit easily and include in -beta5
Here’s the PR to fix the MOT_THST_HOVER param desc. Thanks again for the reports!
Printed 3D frame LWPLA maiden flight, Stable flight mode.Terrain disabled due to Yaapu feedback squawking.
Raining today so limited.
3/12/2025 11:26:53 AM : IMU2: fast sampling enabled 9.0kHz/2.3kHz
3/12/2025 11:26:53 AM : IMU1: fast sampling enabled 8.0kHz/2.0kHz
3/12/2025 11:26:53 AM : RCOut: DS600:1-4 PWM:5-8
3/12/2025 11:26:53 AM : mRoPixracerPro 0036002F 33305103 36363234
3/12/2025 11:26:53 AM : ChibiOS: 88b84600
3/12/2025 11:26:53 AM : ArduCopter V4.6.0-beta4 (dbb9b75f)
My GPS works better now then the older firmware version. " tested "
Mini GPS uBlox MAX M10S
Very nice performance overall.
