Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simulator gives MANUAL CONTROL LOST #9569

Closed
hamishwillee opened this issue May 31, 2018 · 17 comments
Closed

Simulator gives MANUAL CONTROL LOST #9569

hamishwillee opened this issue May 31, 2018 · 17 comments

Comments

@hamishwillee
Copy link
Contributor

hamishwillee commented May 31, 2018

When running simulator there are lots of warnings “Manual Control Lost” and shortly afterwards “Manual Control Regained”. We shouldn't be getting these warnings because we don't have manual control (Simulator) and COM_RC_IN_MODE is set by default such that RC fails should be ignored.

This can be replicated Gazebo Standard VTOL (Macbook pro) and on jmavsim or Gazebo multicopter on Linux computer running Ubuntu 16.04.

I can reproduce on Ubuntu on any build in the last couple of weeks. Simply start the simulator and then putting my computer into lock mode. After COM_RC_LOSS_T the manual control lost message is output in QGC. Undoing lock regains control. I THINK this happens at other times, but I cannot reporduce that.

FYI @RomanBapst. Reported by Ivo Dresher on slack here: https://px4.slack.com/archives/C0V533X4N/p1527595988000400

image

@hamishwillee
Copy link
Contributor Author

A temporary workaround is to set COM_RC_LOSS_T timeout to maximum.

@ivodre
Copy link
Contributor

ivodre commented May 31, 2018

Thanks Hamish for creating the defect report. For me setting NAV_RCL_ACT to "RC Auto Recovery" helped. With that setting when MANUAL CONTROL LOST happened this had no influence on the simulation. I had COM_RC_LOSS_T at 0.5s all the time.

@stale
Copy link

stale bot commented Jan 22, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

1 similar comment
@stale
Copy link

stale bot commented Jun 25, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale
Copy link

stale bot commented Jul 9, 2019

Closing as stale.

@stale stale bot closed this as completed Jul 9, 2019
@julianoes
Copy link
Contributor

I believe this is fixed, please re-open if it's still an issue.

@echoGee
Copy link
Contributor

echoGee commented Jul 12, 2019

@julianoes : On which version is this fixed ? Is this fixed without setting COM_RC_LOSS_T timeout to maximum?
I can still reproduce this issue

@julianoes
Copy link
Contributor

@echoGee

Simply start the simulator and then putting my computer into lock mode.

What do you mean lock mode?

@echoGee
Copy link
Contributor

echoGee commented Jul 15, 2019

I am not sure what is Iock mode, assumed it meant hold mode. But I can reproduce the issue in stabilized or hold mode.

@julianoes
Copy link
Contributor

@echoGee

I'm confused. I don't see that and I use SITL/HITL all the time. Is it SITL or HITL?

@hamishwillee what do you mean with?

What do you mean lock mode?

@hamishwillee
Copy link
Contributor Author

@julianoes
By lock mode, I mean Windows screen lock mode. This can be invoked by doing Ctrl + Alt + Delete and then selecting Lock. Or it happens after a computer has been left alone for a timeout.

I haven't seen this issue for a while, but it may be because I disabled automatic locking of my computer when I am absent.

@julianoes
Copy link
Contributor

Aha, I'd say that's expected because the OS basically stops and the time slips. With lockstep it should not happen anymore though.

@hamishwillee
Copy link
Contributor Author

IN that case, from my perspective this is closed.

@echoGee
Copy link
Contributor

echoGee commented Jul 22, 2019

I can reproduce this on Ubuntu 16.04 with docker. Is it due to too much processor hogging ?

@julianoes
Copy link
Contributor

@echoGee what PX4 version?

@echoGee
Copy link
Contributor

echoGee commented Jul 28, 2019

Version is 1.8.2

@julianoes
Copy link
Contributor

Right, in that case it's probably because the simulation runs too slowly on your computer. I can only recommend to use 1.9 where we have lockstep for exactly this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants