Documentation

/NGOS

/Signals

/Shells

/Cmds

/Ctrl

/HALs

/Conf

/Params

/Behaviors

/Receiver

/GPS

Next Chapter

The NG Behavior Control

Introduction

In essence every UAV has a known set of behaviors and you expect it to behave according to these! This is nothing new.

Now imagine that these behaviors are not a fix set of rules, but imagine you could customize these behaviors according to your needs. Let's say a behavior rule consists of a behavior condition, which when it evaluated as true makes sure that an associated behavior action gets executed. If you think it through you will see that every and all of the current UAV features can be mapped to behaviors! You need calibration on channel 5? You want your cam to make a photo when channel 8 goes to 100%? You would like to turn on the lights, when you have reached 10m or more... and... and... and...

I think you got the point...

... we can model every and all UAV features to one or more behavior rules.

We implemented the concept on the NG. You can define arbitrary behavior rules. Each behavior rule consist of a behavior condition, which when it evaluates to true will trigger an associated behavior action.

Conditions and actions are arbitrary functions implemented seperate in the NG framework. The implemented console commands show behaviors, show conditions and show actions are used to inspect the currently defined behaviors as well as the predefined conditions and actions. Users are able to define custom new behaviors using the predefined conditions and actions with the command behavior add <...> Each condition and action can receive user chosen parameters. These allow further customization.

{i} Behavior conditions and actions are simple methods. Implementing them is a simple job for developers.

Behavior Conditions

The command list conditions lists all currently available behavior conditions.

This will look similar to:

You can use each of these conditions to build Behavior Rules. Every condition can receive zero to two integer arguments.

Behavior Actions

The command list actions lists all currently available behavior actions.

This will look similar to:

Each of these actions can be used to build Behavior Rules. Every action can receive zero to two integer arguments.

Behavior Rules

Inspecting the current Behavior Rules

The command list behaviors displays the list of currently defined behavior rules. A behavior rule consists of a behavior condition and a behavior action. Arbitrary behavior conditions and behavior actions can be programmed and implemented in a modular way by developers. The user is able to manipulate the behavior rules by adding and deleting behavior rules shown in this list.

The output of the command list behaviors looks like this:

Adding a Behavior Rule

The command behavior add <condition>([arg1][,arg2]]) <action>([arg1[,arg2]]) defines a new behavior rule. The required argument <condition> represents a behavior condition as shown by the command list conditions. The required argument <action> represents a behavior action as shown by the command list actions. Both, condition and action, can optionally receive one or two integer arguments.

Adding a new behavior rule is simple and looks like this:

Deleting a Behavior Rule

The command behavior delete [index] removes one of the existing behavior rules shown by the command list behaviors. The argument [index] represents the behavior slot number of the behavior rule to delete.

The output of the command delete behavior 14 looks like this:

Example Behavior Rules

New Style In-flight Calibration

The new in-flight calibration works a bit different than the old style calibration.

To trigger the calibration it's best to have a trigger button. Then you can setup the following behavior:

# behavior add when.rc.stick.edge.and.pot(right,any,0) ctrl.calibrate.acc.by.stick(right)

This will configure your inflight calibration to be triggered by pot0 when the right stick reaches any of the 4 edges of the right stick. It will then use the right stick's position (top,left,bottom,right) to turn the measured acceleration vector of gravity towards that side resulting in your copter no longer drifting into the inversed direction.

Essentially this means that when your copter drifts towards left, then you pull pot0, press your right stick towards right, hear 1 or 3 beeps (half way, full way) and release pot0 to complete this operation.

/!\ Attention: Make sure that you release pot0 only after you have put your right stick back into center position!

Old Style In-flight Calibration (deprecated)

{i} Note: This calibration style is outdated and should no longer be used. It will produce horizontal flight, but will influence the guessed angles which results in suboptimal angle guessing in dynamic flight. Please use the above new style calibration!

In-flight calibration rc.calibrate.bearing() stores the current output of your remote-control stick (for nick/roll) as leading to a stable flight position. After Calibration, if you don't touch the nick/roll stick, the NG will behave as in the moment you inflight-calibrated it.

To trigger inflight calibration, you need a free remote control-channel with a switch on your remote. I had such a switch on channel 5, so I set pot0 to channel 5 (swapped it against channel8/pot3):

# set RC.ch.pot3 8

Setting integer 'RC.ch.pot3' to '8'

# set RC.ch.pot0 5

Setting integer 'RC.ch.pot0' to '5'

My switch has two positions, it delivers (according to loop dsl dsl0) -100% or -100% depending on its position. So we use the when.flying.rc.pot.binary() behavior condition:

# behavior add when.flying.rc.pot.binary(0,1) rc.calibrate.bearing()
# behavior add when.flying.rc.pot.binary(0,1) rc.calibrate.throttle()

http://vimeo.com/15107083 shows this in action.

As feedback, you get a double beep when you trigger this action during fligth. For debugging, you can of course use the actor.play.melody(x) action.

Inflight HAL Change on a tristate switch

The be able to change the used HAL in-flight, you could add the following behaviors:

# behavior add when.rc.pot.tristate(3,2) ctrl.set.hw.hal(quadX)
# behavior add when.rc.pot.tristate(3,1) ctrl.set.hw.hal(quad)
# behavior add when.rc.pot.tristate(3,0) ctrl.set.hw.hal(quadR)

These behaviors allow you to use a tristate button on pot3 to change the HAL used in-flight.

Teacher/Student with two RC and two receivers on a binary switch

If you attach two receivers to your NG, you may do teacher/student without a teacher/student cable and without changes to your remote control.

Just add the following behavior rules and attach two receivers:

# behavior add when.rc.pot.binary(1,0) rc.trainer.mode(teacher)
# behavior add when.rc.pot.binary(1,1) rc.trainer.mode(student)

This will allow you to switch between teacher and student control by using pot1 on the teacher or on the student remote control.

You could use the following behavior rules:

# behavior add when.rc.pri.pot.binary(1,0) rc.trainer.mode(teacher)
# behavior add when.rc.pri.pot.binary(1,1) rc.trainer.mode(student)

to make sure only the teacher may switch between teacher/student mode using pot1, if you do not trust your student.

GPS Position Hold on a binary switch

If you have a compass and a GPS attached, you can activate GPS position hold at the current position using the following behavior rules:

behavior add when.rc.pot.binary(2,0) nav.position.hold(off)
behavior add when.rc.pot.binary(2,1) nav.store.and.position.hold(on)

These behaviors allow you to activate GPS position hold by switching pot2.

Altitude Hold on a binary switch

You can activate Altitude Hold using the following behavior rules:

behavior add when.rc.pot.binary(1,0) ctrl.altitude.hold(off)
behavior add when.rc.pot.binary(1,1) ctrl.altitude.hold(on)

These behaviors allow you to activate altitude hold by switching pot1.

Closed-Loop PT1 Compensation on a binary switch

To be able to switch PT1-compensation on and off in-flight, you can add the following behaviors:

behavior add when.rc.pri.pot.binary(5,0) ctrl.set.pt1.comp(off)
behavior add when.rc.pri.pot.binary(5,1) ctrl.set.pt1.comp(on)

This will allow you to switch PT1-compensation by using pot5.

Nick/Roll override of attitude compensated cam-holder

To be able to change nick and roll angles of your attitude compensated cam-holder on servo1 + servo2 of your CAMC or RCC you can define two channels to override the nick/roll angles.

behavior add when.rc.pot.changed(4) rcctrl.set.nick.corr(4)
behavior add when.rc.pot.changed(5) rcctrl.set.roll.corr(5)

These behaviors allow you to change nick and roll angles of your cam-holder on servo1 + servo2 using pot4 and pot5 which should be preferably potentiometers.

Setting controller parameters by behaviors

Release >=0.66 allows you to change any global or controller parameters by behavior.

The following command switches off the compass by binary switch.

behavior add when.rc.pot.binary(3,0) param.set(CTRL.use.compass,0)

With the following commands you can raise or lower I.z with the left stick

behavior add when.landed.rc.stick.right.delay(center,bottom,0) param.add(I.z,-10)
behavior add when.landed.rc.stick.right.delay(center,top,0)    param.add(I.z,10)

It is also possible to control a parameter by a poti on your remote control. The following command lets you control the parameter P.z with a poti on channel 4 in range 0 to 1000.

behavior add when.rc.pot.changed(4) param.map.rc(P.z,4,0,1000)

Documentation/Behaviors (last edited 2014-04-15 16:29:06 by PeterWolf)