Re the serial ports not working with 4.0.2-rc3, I discussed with Tridge and it’s possible that the SERIAL0_PROTOCOL has been set to a value other than 1 or 2 (for mavlink1 or mavlink2). Could you check this parameter and if possible set it to 2 and try again? Copter-4.0.2-rc4 includes a special check of this parameter at startup so you may also find that -rc4 works.
Thanks for the report.
This was my setting prior to going to rc3:
SERIAL0_BAUD,115
SERIAL0_PROTOCOL,2
I will try RC4
I suppose vibes could be better but they are not bad. I have a PixRacer on a 210 5" on a very compliant mount and vibes are very low. And you’re right, the dynamic notch filter feature is awesome.
Re RC_OVERRIDE_TIME, I have not specifically tested this but my understanding is that the autopilot will accept normal RC input (from a transmitter/receiver) until the GCS starts sending RC_OVERRIDE (or MANUAL_CONTROL) messages. Once these new messages start appearing it will continue using them until they stop for the number of seconds held in RC_OVERRIDE_TIME or if RC_OVERRIDE_TIME is -1 then it will keep on using them until the GCS specifically sends a specially formatted RC_OVERRIDE message to indicate it will no longer be sending them (i.e. the joystick has been disabled by the user)… once this happens the autopilot will revert back to regular RC input (from a transmitter/receiver).
So, to confirm, it sounds like that the FC will accept R/C PPM input until the the GCS sends RC-OVERRIDE messages. If the RC_OVERRIDE_TIME is set to -1, then the FC will NEVER respond to R/C input (PPM signals) again.
Wouldn’t it be safer if the FC responded to RC_OVERRIDE_TIME of -1 ONLY if the PPM input was below the R/C “failsafe” levels, and later, if the R/C input exceeded the “failsafe” levels, control would be restored to the R/C input? This would allow the user to possibly regain control if the GCS failed, went out of range, or had some other failure mode.
The autopilot will respond to R/C input if the GCS specifically tells it that the joystick (or whatever) has been disconnected. If the GCS doesn’t tell it this (i.e. if the vehicle just went out of range) then yes, you’re right, the autopilot will not respond to RC input.
I’m not actually sure why someone would ever want to set RC_OVERRIDE_TIME = -1. If this is set to some reasonable value (like 5 seconds) then the autopilot would fall back to using regular RC which seems like what you’re suggesting?
Yes, I have a TEENSY that “watches” the data from the GPS (it simply is a “tap” on the GPS data line), It looks at the GPS altitude, lat and lon and calculates (independently) the distance from the first GPS “fix” which I assume to be the takeoff point. It also watches the battery current with its A/D (again, from a “tap” on that line). It integrates to find the remaining battery percentage and - since it knows (more or less) how far the copter can fly based upon the remaining battery, if the distance to the takeoff point ever gets close to being further than the expected remaining flight distance, a RTL is triggered - sort of a foolproof failsafe. As built, the TEENSY doesn’t speak Mavlink, it simply takes the PPM signals and passes them through. To trigger a RTL, I change the width of PPM output channel #5 (only). I want to make certain that scheme will work under ALL conditions.
But still, I think that the user should be able to choose to whether or not to over-ride the R/C input if PPM channel #3 goes above the failsafe level. That way, you can fly with a joystick, but if something goes awry, you can still grab your handheld controller and maintain control.