What’s the actual error message?
1 Like
Something is wrong with your MOT_SPIN_ARM and MOT_SPIN_MIN values. Likely the min value is less than the arm value. ARM should be less than MIN. This has always been the case but now it’s part of the arming checks. See item 7-r above.
3 Likes
Yes, thanks. Went on the Ardupilot fb forum and said the same thing. So MOT_SPIN_ARM became from 0.08 to 0.03 and MOT_SPIN_MIN became 0.03 to 0.08, it worked without really understanding these 2 setting values.
Hello,
Does the “–enable-opendroneid” is enabled in this release?
Regards,
RemoteId support is included in 4.3. You’ll need to compile your own firmware though as described in the video on the AP RemoteId wiki page. Support isn’t included by default because the US regulations include a “tamper resistant” requirement which means some additional configuration is required.
1 Like
I got an internal error after updating to 4.3.0, flow of control
Maybe you @rmackay9 could take a look, you seem to know alot ablut the firmware changes. My craft flew fine on 4.2.x
@rmackay9, I may be doing something incorrectly, but 4.3 seems to not update the S-Bus output when commanded by the Herelink. We use the S-Bus to control a Gremsy gimbal angle. I used an O-Scope to look at the S-Bus data stream, and none of the PWM channels change when the scroll wheel is used, or the joy sticks are manipulated. I don’t think it is a Herelink problem, because when I downgraded the cube to 4.1.5 (our latest tested version) the S-Bus performs properly with channels changing based on inputs. Is there some parameter you need to set for the S-Bus signals from the Orange Cube to mirror the RC control inputs? I posted in the developer channel, but I don’t seem to be getting any traction. We were planning to go into production shortly and need to get the S-Bus issue resolved. Thank you!
1 Like
Hi @Bridgerman,
OK, I’ve added it to the 4.3 issues list.
I suspect you don’t want to change the setup close to production but in case you didn’t see it we have an improve Gremsy driver in 4.3.
@rmackay9 ,
Possibly loosely related to Bridgerman’s finding, after upgrading to 4.3 from 4.1.5, I am receiving the following prearm error: RNGFND1_PIN=103, set SERVO3_FUNCTION=-1.
Pin 103 is of course the SBUS port, which I’m using to read an analog ultrasonic rangefinder - this works fine in 4.1.5, and the sensor data is being read correctly* in 4.3. Servo 3 is the third motor on the quadrotor, so obviously disabling that wouldn’t be good, haha.
Thanks!
Regards,
-Luke
*Edit: while data is being read, the reported ranges are not correct in 4.3, and were in 4.1.5; going to roll back to 4.1.5, to see if it’s just a coincidental hardware issue, or something else. Should have mentioned, this is on an Orange Cube.
**Confirmed that rolling back to 4.1.5 produces normal/correct rangefinder values (calculated range and voltage).
hi
I have a downward-facing LW20C rangefinder, I like to know what can this new param PRX_IGN_GND help me with.
I also like to know how critical the TKOFF_SLEW_TIME setting is.
When I load 4.2.3 params onto a 4.3.0 drone, I get this error in MP:
Is this something I should worry about? I set up a notch filter in 4.2.3 but do I have to do it again?
They were not found because the default for INS_HNTCH_ENABLE is 0. If you were to enable it 1st, which will then load all the optional parameters, and then load the 4.2.3 file you wouldn’t see that.
I rarely load a parameter file for any reason. But if you do then go thru the Full Parameter list and make sure everything is right.
1 Like
Okay, so basically it is a quirk of MP. One would think that to load params from a file, you would enable the “parent” params first and then set the “children” params that were dependent on those. As it is, after loading the params I see the “INS_HNTCH_ENABLE” is set to 1 (the box is filled in green) but “INS_HNTCH_ATT” etc do not exist.
Right. Refresh parameters and then try again if you want to load the file. A long time ago before there were Main and sub-parameters this issue, if you want to call it that, didn’t exist 
I suppose the “load from file” routine would have to be revised to load it once, refresh parameters and load it again within one function. Perhaps there is a down side to that but not immediately seeing it.
2 Likes
We fixed a bug with the RSSI pin voltage scaleing, it’s voltage was reported 3 times too big. You will have to divide your set offsets by three and scale factor times by three for it to come good again. (if you have linear or inverted scaling type, hyperbola you would divide the scale by three)
This is the PR:
The pre-arm is a bug because we have a two pin 103’s. One it a analogue input (the one your using), the other is a digital output shared with main 3 that would be conflicting. We should have a fix for the next release.
So this is a bug in the prearm logic, not an actual hardware conflict? If so, is there a workaround, or should I just avoid using the pin 103 analog input for the time-being?
Thanks!
Regards,
-Luke
Correct, just a bug in the pre-arm. Fix here:
Unfortunately the only way to get past is to turn off arming checks, which is not a good idea. As you say you could swap to another pin, or wait for the fix to make it into the next release. Sorry.
No worries, I agree, arming checks stay on. I just picked up a little serial LIDAR, so this just is the nudge I needed to get that wired in, it’s all good!
Regards,
-Luke
Sorry for taking so long to investigate this but I’ve confirmed that at a basic level at least the SBUS output on a CubeOrange is working. The way I tested was to:
- connected the CubeOrange’s SBUSo port to the RCIN port
- set BRD_SBUS_OUT = 1 (50hz)
- rebooted the autopilot
- re-connected with MP and check the Data screen’s Messages tab and saw “RCInput: decoding SBUS(1)”
This last message means that the autopilot is receiving a valid SBUS input which means that the SBUS output is also valid.
I then turned on MP’s live graphing of “ch10in” and used MP’s Servo/Relay tab to channel the Ch10 output (which is fed back in as ch10 input) and again it seems OK.
My guess is that the problem is the SERVOx_FUNCTION for the SBUS channels that you’re trying to feed into the Gremsy gimbal. I suspect if you use MP’s tuning screen and try to graph the servo output (e.g. “ch10out”) you’ll find that they’re also not moving with the RC input. So the issue is not actually the SBUS output but the way the servo output is configured.
Could you provide an onboard log?
Hello
After version AC4.3.0, my GPS device with NMEA output is no longer usable.
Is it no longer supported for GPS devices with standard NMEA output?
thanks