Copter-4.0.1-rc3 available for beta testing

ArduCopter Copter 4.0
,
21

can i get the steps in details on how you start it all up?
also a tlog from MP should show if rc override packets are being sent

1 Like
22

@Dave84,

I see, you’re asking us to increase the update rate used by the TerraRangeEvo from 100hz to 600hz. I’ve had a quick look at the driver and there is a configuration setting for 600hz so it might not be difficult to update the rate. 100hz update rate seems fine though for object avoidance (the SF40C lidar I’ve been using is only 4hz) so I think we should figure out if the update rate is really the issue.

23

ok… I’ll do again some test using evo 60m and 600hz and I will post you the logs…

24

I’m seeing the same behavior with a Pixhawk Cube running the 4.0 firmware. MP and my own GCS both work fine with 3.6, but fail to override the RC with 4.0. I haven’t looked at MAVLink definitions yet used in 4.0 to see if they changed from 3.6. I’ll put some debug statements in SITL to see if the override messages are getting received correctly.

25

Connect to SITL or a Pixhawk running the latest Copter-4.0 branch with MP. Connect a XBox controller to MP, assign channel 1-4 to the joy sticks and enable the controls. The display in MP shows that joystick is functioning correctly. Switch over to RC calibration and move the joy sticks around. There is no response and no green bars at all with any of the 4 control channels.

With 3.6, everything works as expected.

I’ll add some debug statements to SITL to see if the overrides are getting received and processed correctly.

26

@rmackay9 @Michael_Oborne I added some debug statements to the GCS_MAVLINK::handle_rc_channels_override method. It appears that the correct override data for the first four channels is getting to this method, but rc_channels message sent back to the GCS do not have the correct values.

On a hunch, I changed my value of rc_override_time from -1 to 60, which fixed the issue. So there is a bug related to setting no timeout for the rc_override_time.

in RC_Channel::has_override there are these lines:

   const float override_timeout_ms = rc().override_timeout_ms();
    return is_positive(override_timeout_ms) && ((AP_HAL::millis() - last_override_time) < (uint32_t)override_timeout_ms);

Looks like it may need to check for the special case where override_timeout_ms == -1.

This fixed it:

bool RC_Channel::has_override() const
{
    if (override_value <= 0) {
        return false;
    }
    const float override_timeout_ms = rc().override_timeout_ms();
    return override_timeout_ms < 0 || (is_positive(override_timeout_ms) && ((AP_HAL::millis() - last_override_time) < (uint32_t)override_timeout_ms));
}
2 Likes
27

Nice catch and thanks for the quick PR to fix it! I made some comments on your PR, mostly administrative housekeeping. And instead of override_timeout_ms < 0, it is safer and cleaner to use our math function IS_NEGATIVE(override_timeout_ms).

2 Likes
28

@rrr6399,

Really nicely done. Thanks very much for the report, investigation and fix! You did it all :-).

I think we can get this merged to master in the near future and then release with Copter-4.0.2

3 Likes