I just tested 3.4RC1 with my R/C receiver disconnected from the Pixhawk. (We’re only flying simple automated missions via the GCS.) During Guided Takeoff the copter will go to full left Yaw and during Land, a hard over pitch and roll, as well as, yaw will be commanded. This is likely due to a zero input being interpreted as the equivalent of PWM=1000 for Yaw, Pitch and Roll rather than 1500. I can override this behavior with R/C overrides from the GCS, but I feel that the default settings for these controls should be sane (no control) rather than maximum (left, down, etc.)
I’ve documented some of these problems in an earlier version of 3.4 here as well:
It has a number of different scenarios in one log:
1.) No Yaw override for the first guided takeoff leading to the large yaw rotation response
2.) Yaw override for the second guided takeoff leading to zero yaw rotation response
2.) First Land had no pitch or roll R/C override leading to a large pitch and roll response
3.) Second Land was with pitch and roll R/C overrides
The easiest way to duplicate the issue is to unplug the R/C receiver from the Pixhawk and perform a guided takeoff or landing using purely Mavlink commands. The copter will crash so make sure you’re close to the ground when you perform the commands. Be ready to disarm quickly as well.
Also, its not sufficient for all R/C receivers to simply turn off the R/C transmitter. The Spektrum AR8000 remembers the last R/C settings and sends those by default if the R/C is off. The Spektrum satellite receiver does not remember the the R/C settings and is either sending all zeros or no response at all.
Thanks for providing the log. Sorry it took me a while to answer back, I had to check some things (thanks @LuisVale for the help testing it). I didn’t look in detail to the full log because the issue seems to be the same for all four cases so I checked more carefully the first one.
Short answer: what you are trying to do is not going to work.
Long answer: because you want to use Guided without a RC connection you have disabled throttle failsafe. That means that any input that comes in will continue to be accepted. When you don’t have any RC receiver connected we get the last value that Pixhawk received (in case it never received any RC input it will be 0, which matches what you see in the log). Although we do detect that no further input was received, and because you don’t have throttle failsafe, that means the last received values will continue to be used. The other problem is that you are using RC override values for throttle: that means we have input… And that’s when the zeros will be read - because we don’t separate if the new input is just for one of the channels, we assume that when we receive input it is for all channels.
Theoretically it could work if you use commands instead of RC overrides, but I’m not sure it will (because if you never connected a receiver the values will probably be zero anyway). I think this is something that can be improved but, the way I see it, it is such a small user-case that it won’t be on top of anyone’s todo list. Probably when more companion computers start being used this will get more attention.
Now, when you have an RC receiver connected that is a different story: if your receiver is sending values there is no way for us to tell if those are good values or not. It’s up to you to configure the receiver in a way that suits your needs.
@OXINARF Thanks for testing and for your response. The problem does occur with no R/C overrides as well. I think part of the problem is that all variables are initialized to 0, which would be fine if yaw, pitch and roll were scaled from -500 to 500. Unfortunately, they are scaled in the code from 0 to 1000. So given the scaling, I’m proposing that yaw, pitch and roll be initialized to 500 (PWM=1500 or (min+max)/2 ) rather than 0. Also, sending a release of R/C overrides should not initialize the parameters to 0, there should be a flag that indicates the override condition to eliminate the ambiguity.
I think that would have to be done in PX4IO firmware, not my area. You can open an issue in GitHub asking for an enhancement for this - it doesn’t guarantee it will be done, but at least it is documented.
It doesn’t, it is the IO processor that sends 0. Have you tried to connect the receiver and transmitter, with all the normal central values and then physically disconnecting it? It should stay with those central values.
I’ll take a look at the radio.cpp, RC_Channel.cpp and GCS_Mavlink.cpp code to work around the issue.
If the IO processor is sending a 0 that should be an indication that the receiver is not connected since it should be sending values between 1000 and 2000 (except for the throttle where the receiver may send a lower value like 970 to indicate that the receiver lost link with the transmitter.)
If I leave the Spektrum AR8000 receiver connected, it will send the last received R/C values (trimmed if no input from the user). If I use the Spektrum satellite receiver, it sends no response or 0s. (Not sure exactly, but I know it doesn’t send trimmed values and has yields the same response as disconnecting it completey.)
I’ll try that when I get a chance this week. Doing the testing is a bit risky and I may end up doing another repair. Right now, I always send a “release R/C overrides” message before arming so that may muddy the results.
Shouldn’t a PWM value = 0 indicate that the R/C receiver is not present?
It appears that there is a separate data structure in RCInput.cp that tracks whether the overrides have been set, but the message used to indicate releasing overrides uses 0 as the value for PWM for the given channel. Is it possible that when a release is commanded that the R/C values are not reset to trim values (~500 for roll, pitch and yaw). If there are no R/C overrides present, then any 0 value R/C PWM values should be ignored, right?
You don’t need to risk anything. You have a GCS connected right? Just check the rcin values.
It could be sending 0 on purpose. Of course if we setup a min value, everything below that value shouldn’t count - but that’s what throttle failsafe is there for and you have disabled it. Maybe the easier way for you to workaround is to add a new failsafe action: continue if in Guided
Overrides are tracked separately from RC input so when the override ends there is no need to reset any RC value.
At least for the AR8000, the FS throttle has to be explicitly set to a value below 1000 like 950 or so. Are there receivers that send a 0 to indicate a loss of R/C transmitter signal?
The R/C input should be reset to trim values when there are no overrides and the R/C is detected as being off to avoid catastrophic behavior. I think there is an assumption that if there are no overrides that the R/C is on.
That’s one way to look at it. The way we handle it is if we are in RC failsafe we don’t use the rcin values. The issue is that you disabled the failsafe, so it tells the system it can use the rcin values. Like I said before, it isn’t that it can’t be done, it is that the system isn’t prepared for it.
I just ran a test where I disconnected the receiver while the transmitter was on. All RCIN values went to exactly zero.
I imagine there are others who would like to fly without an R/C. Its not necessary to override the R/C controls with the GCS if you’re doing AUTO or GUIDED missions.
R/C failsafe does not make sense when you’re flying without an R/C. What is the alternative other than overriding all the R/C channels explicitly with the GCS? (That’s what I’m doing now, but then need to put in logic to detect if the R/C is turned on in an emergency situation.)
What is the rationale for not setting the R/C values to trim if there are no overrides and the R/C transmitter is turned off, the receiver is not sending the last known values or there is no receiver at all?
There has been an interest by even people like Chris Anderson for years. What’s the hold up?
Reply by Chris Anderson on November 26, 2014 at 10:36pm
"I haven’t touched RC sticks for months. I just use Droidplanner (and
AC3.2 with EKF turned on) and often just over Bluetooth – it’s the
ideal mobile-first experience, especially when you’re doing auto
missions like mapping, scanning and dronies."
Like I mentioned, I can do it now by overriding the R/C. With a few small changes to default settings, overriding would not be necessary to prevent unexpected crashes.
Isn’t 3DR still using a branch of Ardupilot in the Solo? I read somewhere that they were merging in the 3.4 features into the Solo branch.
I’ve been reviewing the source code and have compiled it successfully with Eclipse and the nice tool chain bundle. When I figure out all the RC related logic, I’ll create a PR. Its just going to take me more time that the team than has been looking at the code already.
In the mean time, I’ll just override the R/C controls with my GCS.
