How to create a location injection policy using Location Engine Config

Summary

This article shows how to create a location injection policy using Location Engine Configuration. Locations are injected automatically for objects that have not been located recently, but are known to be present in a cell.

Prerequisites

You should know the information in the following articles:

• How to detect object presence using Location Engine Config
• How to get a list of types

Guide

Before you start, remember to:

• Make sure you have a valid dataset with the "UPresence" module installed.

• Set managed_base_type (see section 3 here for details) to UBase::Object before starting Location Engine Config.

• Start the Location Engine Configuration tool and check that the "Presence" tab is shown.

• Set some sensors to forward uplinks and/or chirps.

Setting up the policy

In Location Engine Config, create a policy as follows:

The following dialog appears:

Click OK and the policy is added to the list:

Rules about location injection

Object presence

Remember that for locations to be injected, the object must be known to be present in the cell. It must be found in the MessageWasHeard relation of the Ubisense.UPresence.Association schema.

Multiple policies

If a tag is heard by presence sensors from multiple location injection policies, you cannot predict which policy will be applied. Policies have no information about each other, so relative signal strengths between different policies do not affect which policy is used.

Inheritance

Location injection policies (and presence aging / location aging policies) are inherited according to the normal inheritance semantics, and can be overridden at descendants. If a policy is defined for a type T it will be inherited by any descendant U of T, unless U defines a policy, in which case the policy for T will be invisible to U and its descendants.

Location injection policies can be defined for different cells. In general, smaller cells will take precedence over larger ones, but only after inheritance has been taken into account.

Example

If you have 2 Location Engine cells A and B, both containing uplink-forwarding sensors, define:

1. A location injection policy for UBase::Object, Site, 90 seconds.
2. A location injection policy for ULocationEngine::Tag, Cell A, 45 seconds.

Location methods

The location methods are:

• Random: Put the tag at a random position in the extent of the cell that owns the policy.
• Strongest RSSI: Put the tag at the position of the sensor with the strongest RSSI in the cell that owns the policy, clipped to the extent of that cell.
• Weighted RSSI: Put the tag at a position that takes account of the relative RSSI values in the cell that owns the policy, clipped to the extent of that cell.
• Neat: Put the tag at the same position/orientation of a UPresence::Anchor object within the cell that owns the policy.

Neat location injection

To make a "Neat" location injection policy work, create some object type with a visualization, for example a car. Assign the representation to the UPresence::Anchor type as well:

Create some UPresence::Anchor objects:

Place the anchors in exactly the position and orientation that you want cars to go on the map (make sure you don't have a location aging policy set on UBase::Object):

Now you can remove the visualization from the UPresence::Anchor type so they don't appear on the map:

Your "neat" policy will now place objects at the anchor positions:

When anchor positions are full, objects are positioned with a small offset so you can see when there is more than one object there.