Human override

[fselius]

In case the companion computer goes crazy we need to be able to assume manual control using the remote controller. Find out how this can be achieved. Started a topic http://ardupilot.com/forum/viewtopic.php?f=25&t=12019 , no replies yet. This is a high priority item.

@efiShtain @serbuh @noamyogev84 @shadows89

[noamyogev84]

Our big problem is, that with rc/override the APM does not know who is actually streaming data on the channels, the companion computer or the transmitter. so in order to "take-over" the quad, we'll have to implement one of 2 suggestions (or maybe both ?? i dunno)

1. make sure the CMC is only sending data to channel 0-4, and use remaining channels to set up some constant value that we check constantly, so if a transmitter set it to a new value, we immediately reset all channels, stop any CMC process and take over by transmitter.
2. utilize a special module that simply kills whatever is needed in case of drone craziness, and this module (special node) is accessible via ssh from ground station..

what do you think?

[fselius]

It needs to be 'stronger' than that, in the Pixhawk level. For all we know the drone might be far enough so that we don't have a network connection (Thus no SSH or any access to the computer). I suggest trying to find people who worked on similar projects and see how they tackled this issue. By the way, flying using rc_override is sometimes called 'flying with joystick'. You can plug a joystick to your ground control station computer, it reads the joystick position and sends rc_override messages accordingly.

[fselius]

A very (very) crude way would be to attach a switch between the computer TX to the Pixhawk RX pins, only if channel 8 (Or any channel we aren't using) on the transmitter is HIGH data can flow.

[fselius]

We'll go with @noamyogev84 first suggestion, the module that publish RC Override messages will check if an unused channel is switched off and only then publish messages. This needs to go in the fact sheet risk management item @roeemz .

[noamyogev84]

Human Override is now implemented into the navigator class. @fselius @efiShtain

[fselius]

https://github.com/fselius/qtcopter/blob/0fe8d4b5c1ba65911804490475c468e5eb935be1/src/qtcopter/src/qtcopter/navigation/Navigator.py#L65L77 The method PublishRCMessage is defined twice. https://github.com/fselius/qtcopter/blob/0fe8d4b5c1ba65911804490475c468e5eb935be1/src/qtcopter/src/qtcopter/navigation/Navigator.py#L91 When checking if a read for the channel is recent enough, the 2 should be a JSON parameter as well.

[noamyogev84]

The method is overloaded, we still not sure how it will get its parameters hence the 2 versions.

[fselius]

That is a very nasty way to overload methods, you can comment out the method you aren't using.

[noamyogev84]

• [x] Human Override module tested with PreserveHeight.py module and is working correctly when another process (node) sends msgs that change the human override channel from outside
• [x] Run this simulation again with the real transmitter

@efiShtain @fselius @serbuh @shadows89

[fselius]

We'll test the human override module with the real drone after Tuesday's meeting. @noamyogev84 @serbuh @efiShtain @shadows89

[fselius]

@noamyogev84 How did it go?

[noamyogev84]

Human override test went ok, the result is that navigation module stops publishing immediately when channel 8 is modified with the transmitter. here are some conclusions:

1. The topic that we need to listen to is NOT rc/override, it's actually rc/in : we saw that we get no value change in the rc/override topic after we changed the value in channel 8 manually with the transmitter. so, any publish from the CMC will be to rc/override and the callback function will handle any change in rc/in channel.
2. When channel 8 is triggered, before we "cut off" any publish from the navigator, we publish one last rc/override msg with "NO_CHANGE" value to all channels, and that gives back the control entirely to the transmitter.

thanks to @shadows89 @serbuh for all the help + one free Russian language tutorial.

[fselius]

Excellent! Does rc/in topic outputs the values from the RC transmitter regardless of the RC override messages? Can we close this issue and move on to plan a computer controlled flight?

[noamyogev84]

Yes it does. when nothing is published to rc/override. I think this is done.

[fselius]

And if we are publishing to rc/override?

[noamyogev84]

No. When we publish to rc/override it literally override any other values from the transmitter. The solution is to keep channel 8 with "no value" for each publish msg. (And maybe more channels besides 0-4)

[noamyogev84]

mode change after human-override triggered guys can you please verify on our pixhawk what are the modes (regarding position hold) that are exposed? cos the simulator give me just 'ALT_HOLD' ans 'POSITION' and i'm not sure the last is what we want cos it doesn't maintains throttle. check it out:

also i understand that from version AC3.2 there is a 'POS_HOLD' mode, that maintains all channels inculding throttle : http://copter.ardupilot.com/wiki/flying-arducopter/flight-modes/poshold-mode/

so what do we have on our drone ? and what do you say about the GPS Lock stuff?

@serbuh @shadows89

[noamyogev84]

Update After our last experiment, we came to a conclusion that the human override needs to be split-ed to 2 scenarios:

1. human override (including all logic that comes with it) and change to a predefined mode.
2. the same, only with land mode triggered.

so now it's implemented. our switch in the RC has 3 states (low, mid, high) :

• low - will result in human override and land.
• mid - computer control is enabled.
• high - will result in human override and custom mode. e.g ALT_HOLD, POS_HOLD....

@serbuh

Thanks.