Introduction
This guide provides example use case scenarios and is intended to be read along with the Deployment Considerations document. The examples here explore CUWB System configurations and options in the context of real-world applications.
Each example focuses on a specific aspect of system planning and is not intended to cover every detail of a full deployment. See CUWB Case Studies, for a comprehensive look into an existing installation.
LPS Calculations
Many of the examples below calculate the Locations Per Second (LPS) for either MultiRange or MultiTime modes. The formulae for those calculations are as follows:
LPS MultiRange
LPS MultiTime
Note that each mode has an upper limit on the total locations per second for the CUWBNet in that configuration. For more information on LPS, please see LPSMultiRange or LPSMultiTime
Robotic Vacuum
Robotic vacuum cleaners are a common household item that bridge the gap between technology and everyday life. As such, they are a rich target for research and development by robotics researchers and companies alike. In the following example, we describe how the CUWB System could be used in both a low and high LPS mode to achieve different goals.
The tracking area represents a typical household floor plan with rooms such as a kitchen, living room, and multiple bedrooms. In the following examples our users would like to use the CUWB RTLS to find a lost vacuum and research the effectiveness of the vacuum’s cleaning path. The following are some basic parameters for the system:
| Parameter | Description |
|---|---|
| Speed | Vacuum speed approximately 0.15 - 0.3 m/s |
| Area | 200 sq.m |
| Anchor Array | 8 anchors, reasonable LoS, approximately 1 anchor per room/hallway |
| Tags | 1 tag (on the vacuum) |
Scenario A: Lost Vacuum Tracking
The user wants to track the robotic vacuum while monitoring the last known room the vacuum visited. Thus, when the vacuum is ‘stuck,’ the user can easily identify the location and render assistance.
Speed and LPS Considerations
The robotic vacuum is relatively slow and retrieving it doesn’t require live data. The user needs the last known location and the accuracy of the location can be relatively sloppy. Location accuracy in the range of +/-0.5 meters would work well for identifying whether or not the vacuum is in a room.
Our user chooses MultiRange mode for this application, with a low refresh rate of 5Hz providing CUWB Position data once every 200mS. They do a quick survey of their anchors taking quick measurements of the anchor locations that are accurate to within 0.1 meter. That level of accuracy works well since MultiRange mode isn’t as sensitive to survey as MultiTime mode. The user doesn’t worry about anchor-to-anchor communications through rooms.
The LPS for this simple setup is 5, which is well under the maximum limit and would allow the user to add more devices.
User Application
In order to make use of the CUWB RTLS our user creates a user application that works alongside the CUWB RTLS consuming output position data.
The application defines zones for each room and evaluates the position data contemporaneously to determine the current room in which the vacuum is located. When the vacuum is “lost”, our user can now look at data from the application to determine the current location.
Additional features can be added to the application to improve usability such as: hysteresis for room transitions, notifications based on time in room, heatmaps, etc.
Scenario B: Vacuum High-Precision Cleaning Path Analysis
Our user has been watching their robotic vacuum cleaner as it works through various rooms in their household and has determined that there must be a better, more efficient, path to clean the floor. To prove that their algorithm is better the user will install a CUWB RTLS to analyze position data and generate efficient cleaning patterns for their tracking area.
Speed and LPS Considerations
The user wants very precise location at high data rates so they select MultiTime mode for the CUWBNet mode. They carefully survey the anchors to ensure best performance, and select installation locations where anchors can hear one another over UWB.
The vacuum doesn’t move very fast, but it can perform quick rotations. To capture the quick rotations and analyze the cleaning pattern, they select a high beacon rate of 100Hz locating the tag once every 10mS. These settings provide the user with a large amount of data over very short time spans and enable precise tracking of quick movements.
Given the 8 Anchors at 10 Hz and a single tag at 100Hz the LPSMultiTime is 180, leaving plenty of room in the UWB Schedule to add tag. For example, it might be informative to place 3 tags on the vacuum in a triangle pattern allowing for determination of the vacuum’s orientation.
Filtering
Filtering is a mathematical process applied to the output data that makes the data more precise, at the cost of latency. In this scenario, the user configures the CUWB Manager for filtering with a smoothing factor of 20. The tag continues to transmit at 100 Hz, the CUWB Manager continues to output position data at 100Hz, but the data will represent an average of the last 20 locations.
The CUWB Manager can be configured to use different filtering algorithms, for more information please see CUWB Manager Filtering
User Application
To make use of the CUWB RTLS data, our user creates a program that attaches to the CUWB output CDP Stream and listens for XYZ position data. The data is timestamped and logged into a database where it can be retrieved for post analysis.
Return to Deployment Considerations - Subject Speed & LPS
RC Basher Competition
Radio Controlled (RC) cars and trucks are enjoyed by enthusiasts and professionals alike. In this scenario, our fictional operator will use CUWB RTLS technology to remove the subjectiveness from the human observer during RC bashing competitions. Unlike RC Racing where competitors face off using both on-road and off-road vehicles in timed competitions, RC “bashing” competitors control their vehicles to perform stunts and tricks in an arena filled with jumps and whoops. This application demonstrates the effectiveness of the CUWB System and hardware when configured using high LPS rates to monitor fast vehicles that rapidly change direction.
RC bashing competitions occur in arenas that include a variety of jumps. Judges monitor the race and score competitors based on the ‘tricks’ they perform. Tricks typically involve jumps, and forward or backward flips. Our operator would specifically like to implement a high-jump and long-jump competition and automate the scoring.
Here are some parameters our operator might be faced with in this scenario:
| Parameter | Description |
|---|---|
| Speed | RC Basher velocity 30-35 m/sec |
| Arena | 100 m x 100 m |
| Anchor Array | 12 anchors with Line of Sight (LoS) to the arena |
| Tags | 20 tags, 10 competitors with 2 on each basher (front and rear) |
The operator runs a judging application that uses CUWB location data from the RC basher to determine whether a racer has crossed a designated jumping platform. Once a basher is determined to be at a jump platform, the software measures the point at which the vehicle reported z-height returns to the ground in the case of the long-jump, or the maximum z-height in the case of the high jump.
System Configuration and LPS
The desired LPS for any installation is influenced by the object’s speed, the quickness with which the object can change direction, and by application requirements. In this particular application our operator needs extremely high data rates to determine when the RC basher has crossed the jump platform, e.g., a data rate of 1Hz would allow the speedy vehicle to cross the platform and return to the ground only recording a point or two of data. Our operator configures the tags to use 100Hz beacon rates allowing them to measure rapid motions and ensure they can capture the apex of any jump.
The two tags will use 200 LPS of air time. This exceeds the recommended maximum of LPS for MultiRange, so the operator chooses to configure the system in MultiTime Mode. MultiTime Mode for this setup uses 2120 LPS leaving headroom for more tags providing precise output location.
MultiTime mode requires that the operator carefully survey the anchors and ensure that the anchor array is contiguous, i.e., each anchor can hear UWB signals from multiple other anchors with no breaks in the array. Our operator installs 8 anchors on poles located around the arena and an additional 4 tags on short poles 0.5m above the ground. The ground anchors provide z-axis diversity, allowing the CUWB Engine diverse input data to more accurately calculate height.
The locations of the anchors and jump platforms are surveyed using a total station.
User Application
The CUWB RTLS provides XYZ position data to our operator at 100Hz per tag, but it does not handle the scoring, or display of the competition. Our operator creates a User Application that connects to the configured user data output port to capture and process the position data. The application implements a geofence to determine when a vehicle is near a jump platform. Once the competition starts, the application determines when a vehicle has crossed a jump platform and displays the height, airtime, and distance information on a large scoreboard.
In addition to scoring, our operator uses the CUWB Viewer to display live data from the race to spectators. The CUWB Viewer is configured for an overhead view of the race, and the operator has imported objects to represent features of the course providing a more realistic view.
Return to Deployment Considerations - Subject Speed & LPS
American Football
Analytics and sports go hand-in-hand. In American football, analysts frequently look at player routes, play accuracy, and much more to improve the overall game. In the following examples our analysis will use the CUWB RTLS to track player activity during, as well as the motion of the ball throughout the game.
In preparation for deploying the CUWB System our analyst must consider a large number of elements: the size of the field, number of players and footballs, data sample rates, etc.
| Parameter | Description |
|---|---|
| Player Speed | 10 m/sec |
| Ball Speed | 27 m/sec |
| Area | 110m x 48.8m with a 6m sideline perimeter |
| Anchor Array | 12 anchors with good Line of Sight |
| Player Tags | Total of 184 - 22 active and 70 bench players, each player wears 2 tags |
| Ball Tags | 6 footballs per game |
Scenario A: Tracking Team Players
Football teams consist of 11 active players and numerous backup players, coaches, and staff. The analyst is focused on tracking players so staff and coaches are excluded from being tagged.
In this scenario our analyst will track bench players at a slower data rate of 1Hz, while tracking active players at 50Hz. By doing this they have rich data for fast movements ‘on-field’, while providing sufficient tracking ‘off-field’ to know where players are located. A user application will need to be created that will use the CUWB API to switch a player tags role from the slower rate to the faster rate when they transition from off-field to on-field.
Device Considerations
There are a total of 46 players per team, 11 players ‘active’ in the field and 35 dressed and available for play. Each player wears 2 tags allowing analysts to determine the orientation of the player in addition to speed and heading. The total number of tags in the tracking area is 184 consisting of 44 ‘in-field’ tags and 140 ‘off-field’ tags.
Using the LPSMultiTime formula the CUWB system with this configuration is using a total of 2200 LPS for active players alone. Adding off-field players and air time for anchors the total system LPS usage works out to 2460. That is under the maximum LPSMultiTime(#lps-calculations) and thus safe to operate with allowances for tags transitioning from on-field to off-field.
User Applications
Our analyst will be collecting CUWB RTLS tracking data and running various analytics on the overall performance of players. Tag will also need to transition from an off-field 1Hz role to on-field 50Hz role.
To achieve these goals the analysts creates a User Application that subscribes to the CUWB RTLS user data stream. As data for each tag is received, the data is pushed into a cloud database where the analyst does post analysis of the game. The application also evaluate each incoming position and operates as a geofence determining whether at tag is on-field or off-field and uses the CUWB API to transition tags from one role to the other as necessary.
Scenario B: Tracking the Football
In this scenario our analyst would like to see the progress and path of the football allowing them to run analytics on downs, progression of play, and even potentially to automate scoring.
Device Considerations
Each football is tagged internally and tags are reinforced to withstand impacts from kicking and throwing. Multiple balls are needed per game and a total of 6 balls are tagged for use.
The football is a dynamic object, it changes direction and speed rapidly during play. Footballs can reach speeds up to 27m/sec. To ensure accurate path tracking our analyst selects a location rate of 100Hz for each ball. The high data rate allows the analyst to filter the data if desired, while capturing the dynamic movement.
Scenario C: Bringing it together
In both scenario A and B, the total system capacities are below the MultiTime maximum. The analyst could decide to track both the players and the football, requiring a total system capacity in LPSMultiTime of 3060. The combined LPSMultiTime is still below the maximum allowable and provides the flexibility to add more active tags as needed or tweak data rates for off-field players.
Scenario D: Additional Capacity
To expand the system capacity further, multiple sets of RF settings can be used with the CUWB RTLS. The user could have the off-field players on their own slower CUWBNet on Channel 5 and the active fielded players on a faster CUWBNet on Channel 9. This would require the user to add anchors to the anchor array, but would allow both CUWBNets to have the full 3300 LPS capacity available.
Return to Deployment Considerations - Subject Speed & LPS or Count or Geolocation
Drone Show
Drone shows and drone art are quickly gaining traction as an alternative to firework and other pyrotechnic displays, both indoors and outdoors. In this example a done show operator tracks drones during a show and uses the location data to create drone patterns and 3D images.
The drone show operator wants to create a drone show performance inside an airplane hanger. In order to generate beautiful and exact geometries, drones in a drone show must have precise tracking. Outdoors, this is typically done with GPS, however, the building structure of the airplane hanger blocks the GPS signal. The CUWB RTLS system might be used for a large scale drone show with some of the following parameters:
| Parameter | Description |
|---|---|
| Speed | 20 m/sec |
| Area | 90m x 100m Indoor |
| Anchor Array | 16 spaced on a grid with good LoS |
| Tags | 392 tags, one for each drone in the show |
Device Considerations
This is a fairly large drone show consisting of 400 drones each of which will be given a UWB tag. The drones can move rapidly, up to 20m/s, but they typically have on-board navigation and stabilization systems so the location data rate isn’t as critical.
To maximize the number of locations our user selects a beacon rate for each tag of 8Hz. The drones will be located more frequently than typical GPS update rates so this setup should work well. Given a nominal anchor data rate of 10Hz, the LPSMultiTime for the setup is 3296. Our user has configured the system near the limits in order to provide maximum performance for her show.
Return to Deployment Considerations - Count
Ballet Dancers
The CUWB System can be used in a wide variety of applications, integrating with existing technologies, equipment, and automation. In this example we have an artistic director who would like to track ballet dancers during a full production of Tchaikovsky’s The Sleeping Beauty.
The CUWB system not only allows the director to review actors’ blocking, but also can be integrated with the lighting systems to turn on/off equipment when actors enter a section of the stage, or to automate followspots. This example demonstrates the use of CUWB systems tags in an environment where tag size and battery life heavily impact the system.
There are many considerations the director must understand to successfully integrate the CUWB RTLS into their show:
| Parameter | Description |
|---|---|
| Runtime | 2hr 40min show run-time, with extensions due to intermissions |
| Additional Time | 4hrs of warmup, pre-performance, and system checks |
| Area | Stage dimensions 27m x 31m including wings, with anchors installed in rigging |
| Anchor Array | 35 anchors - 25 mounted above the stage, 10 mounted backstage |
| Tags | 100 total tags - 25 lead dancers with up to 4 tags each, |
Size Considerations
Tags that are placed on people should generally be small and unobtrusive. This is especially true when incorporated into wardrobe items for performances. For this performance the tags are integrated into the performer’s costume using sewn pouches designed by the costume department. The pouches allow tags to be removable for laundering, recharging, and quick change during the performance.
Each dancer wears tags on both hips and both shoulders to maintain good LoS to overhead anchors while minimizing bulk or discomfort. Antennas for the devices are oriented upward along the dancer body toward the ceiling.
Charging Considerations
The tags must operate continuously for 8-10 hours to cover warm-up through curtain call. Since tags are removed post-performance, the team uses overnight bank chargers to recharge multiple tag sets at once. Tags may use high beacon rates, provided battery capacity supports full runtime.
Return to Deployment Considerations - Size or Power & Charging
Warehousing and Factory Environments
The CUWB RTLS is scalable for use in large environments like those found in warehousing or factories. These enterprise-level applications can benefit significantly from real-time tracking whether it be simple tracking of assets or cost savings through analytics. The following two example scenarios present potential use cases of the CUWB System across large scale deployments.
The scenarios described below for tracking forklifts and monitoring equipment are operated in the same warehouse using a single CUWB RTLS instance.
Scenario A: Forklifts
Understanding the paths taken by forklifts in warehousing and factory environments can be critical to efficiency and the overall safety of the workforce. This scenario demonstrates how a forklift could be tracked through a facility using the CUWB RTLS enabling logistics coordinators to analyze efficiency and improve safety. Some considerations:
| Parameter | Description |
|---|---|
| Area | 25000+ sq.meters, fairly open with LoS blocked by racking |
| Tags | A single tag is mounted to each forklift |
| Anchors | 70 Anchors using roughly 20 meter spacing |
| Performance | ~10 cm for analytics and geofencing |
Tag Considerations
The forklift tags are mounted near the overhead guard, positioned away from moving parts and operator controls. The mounting scheme provides good site lines to the anchor array in an area that is relatively protected. For the purpose of this example the tags are not powered from the forklift and are charged infrequently during maintenance shifts.
The forklifts require durable tags with extended battery life. The factory works with a local vendor to fabricate custom mounting brackets that secure the tags in place and allow for charging access without removal. They remain mounted and are recharged during scheduled forklift maintenance cycles. The tag bracket includes a direct-access charging port to simplify this process.
Anchor Considerations
The anchor array will be installed in the ceiling of the facility and thus anchors have good LoS to one another. The facility needs precision in the range of 10cm to allow for analysis of the data and geofencing applications. To achieve this the operators decide to install the anchors with 20 meter spacing, and add anchors in areas where visibility from the forklift to the anchor array is highly occluded.
User Application Considerations
The facility operators implement a user application that subscribes to the CUWB RTLS position data, processes the data, and pushes it to a cloud based database. The logistics team for the facility is able to query the database, determine forklift pathways, areas of congestion, and locations where forklift operators are forced to linger. This allows them to rearrange material, and racking to increase overall facility efficiency.
Additionally the facility operators create a geofence application that subscribes to the CUWB RTLS data and monitors for forklift presence in personnel pathways. Whenever a forklift is identified near a pathway warning lamps within the area are automatically enabled warning personnel that there is a vehicle in the area.
Return to Deployment Considerations - Size
Scenario B: Assets and Equipment
In addition to tracking and analyzing forklifts our facility operators would like to track high-value equipment. This is equipment that is mobile, or periodically moved for storage. Our facility managers would like to reduce instances of lost equipment and optimize time spent retrieving equipment. The facility is same facility in scenario A above with the following considerations:
| Parameter | Description |
|---|---|
| Area | 25000+ sq.meters, fairly open with LoS blocked by racking |
| Tags | 0.1 Hz, once every 10 second repeat rate |
| Anchors | 70 Anchors using roughly 20 meter spacing |
Tag Considerations
The equipment our facility manager would like to track is deployed at least once every six months, and maintenance would like for the tags to last at least that long between charge cycles. To achieve the long battery life, the tags are configured to use 0.1 Hz beacon rate. The facility can choose to use either a rechargeable battery or a replaceable battery depending on what works best for the maintenance team.
User Application Considerations
As with Scenario A above, the facility operators implement a user application that subscribes to the CUWB RTLS position data, processes the data, and pushes it to a cloud based database. When the high-value equipment is needed facility operators use a tool that queries the database for the last known position of the equipment. The tool provides a simple interface for querying the database, and allows users to associate tags with new equipment as needed.
Additionally, for equipment that is critical to facility operations implement a geofencing utility that notifies staff whenever certain equipment is moved.
Return to Deployment Considerations - Power & Charging
Cricket Players
The CUWB RTLS can be used for analytics and tracking in a variety of different sports. One sport that presents a particular challenge is cricket. In this example, a cricket league manager would like to track players during an exhibition cricket match at the London Oval. This application demonstrates the need to carefully plan anchor placement to ensure appropriate coverage given the large ranges between devices.
Our user will need to consider the following parameters:
| Parameter | Description |
|---|---|
| Area | Oval pitch is approximately 150 meters in diameter |
| Anchor Array | 20 Anchor array placed on the bounding perimeter |
| Tags | 22 total tags, one for each player |
The cricket pitch presents a unique challenge for RTLS due to the sheer size and open structure. Anchors cannot be placed on the pitch without interfering with play, and anchors across the pitch from one another are >150m apart meaning they are out of UWB range. In this deployment, anchor placement and spacing is driven largely by anchor-to-anchor connectivity and visibility onto the pitch.
A tag worn by a player in the close-infield of the pitch should be heard by a majority of the anchors. The CUWB tag hardware effective UWB range, including improved antenna design and built-in low noise amplifiers (LNAs), exceeds 80 m in good LoS conditions. As the player moves through the infield into the outfield their tag will move out of range of the anchors on the far side of the pitch.
Regardless of the player’s location on the pitch, the manager needs to ensure that each tag is within range of at least 5 anchors. The manager also wants redundancy. When the player’s bodies block LoS in a particular direction there are enough anchors in other directions to achieve good performance.
To achieve these goals, 20 anchors are placed around the perimeter of the field. Each anchor is spaced roughly 24 meters from its neighboring anchor. Any given anchor is within range of 6 other anchors satisfying requirements for anchor synchronization. Each anchor covers a ~160-meter diameter area, enough to support full coverage of the field.
The final anchor count may vary based on mounting feasibility, required tracking precision, and redundancy.
Tag Size and Mounting Considerations
Return to Deployment Considerations - Range
Office Space
Office organization can be difficult, especially when it comes to effective layout for cubicles and common areas. In the following scenarios the CUWB System is used to help analyze cubicle layouts and automatically mark rooms or areas as occupied.
These examples identify key considerations when using the CUWB RTLS in indoor environments, and explore a real-world use case for MultiRange mode.
Scenario A: Cubicle Layout
In this scenario an office manager has several large open areas in their building where they would like to layout cubicle setups. The areas are nearby one another, but aren’t necessarily visible to each other. The company culture is unique in that there are no assigned seats and employees choose their work area when they arrive.
The office manager would like to track which workspaces are occupied most frequently and use that information to inform cubicle layout.The goal is to evaluate workspace usage patterns across the four cubicle zones where each zone has a different layout, e.g., open rows, pods, partial partitions.
The following are some parameters the office manager has defined:
| Parameter | Description |
|---|---|
| Area | 4x 110 square meter areas 10 cubicles per area |
| Accuracy | +/-0.5 meters, enough to identify which cubicles usage |
| Repeat Rate | 1 Hz or less, high frequency data isn’t necessary |
| Tags | 30 tags, one for each employee |
| Anchor Array | 20 anchors, 5 per area |
The CUWB RTLS in MultiRange mode works well for this application. High accuracy isn’t necessary, the office manager just needs to identify which cubicles are occupied. The output LPS is extremely low requiring only 30 LPS for the tags.
To ensure sufficient coverage and minimize blind spots, the system uses 5 anchors in each area. Anchors are placed at the corners of each area placing them roughly 10 meters apart. An additional anchor is added in the center to ensure coverage and reduce LoS issues. To simplify setup, the system survey is done quickly by counting the number of ceiling tiles between anchors. The system is set up in MultiRange, and there is no need for UWB communication between anchors in the different areas. No anchors are placed in connecting hallways, or non-office areas.
Workers grab a tag from the reception area at the beginning of the day. The repeat rate of the tags is low, and they are configured for wake on shake. In this configuration they last an extremely long time and charging can be handled on an as needed basis.
A user application is built that monitors CUWB Position output data, and logs that data to a database. Over time, a rich dataset is collected that allows the office manager to trial various cubicle arrangements and improve the overall effectiveness of their workforce.
Return to Deployment Considerations - Range
Scenario B: Conference Room Usage
In this scenario the office manager would like to automatically indicate whether or not a conference room is currently occupied. Conference rooms are spread across floors and it is impractical for the manager to cover their entire building with anchors.
| Parameter | Description |
|---|---|
| Area | 6 conference rooms spread across floors |
| Accuracy | +/- 5 meters |
| Repeat Rate | 1 Hz or less, high frequency data isn’t necessary |
| Tags | 30 tags, one for each employee |
| Anchor Array | 6 anchors, one for each conference room |
As with scenario A above, the CUWB RTLS in MultiRange mode works well for this application. The accuracy needed from the CUWB System is low and the total LPS is well within limits. A single anchor is mounted in the ceiling of each conference room, and is quickly surveyed by counting drop ceiling tiles. Multiple anchors are not necessary, the conference room system won’t use XYZ output location, but rather proximity to a given anchor.
Workers grab a tag from the reception area at the beginning of the day. The repeat rate of the tags is low, and they are configured for wake-on-shake. In this configuration they last an extremely long time and charging is handled on an as needed basis.
The office manager sets up a clever lighting system to indicate conference room occupancy. The lighting system is controlled by an application running on one of their servers. The application subscribes to the CUWB RTLS output stream and monitors distance measurements to determine occupancy based on the proximity of tags to the anchor mounted in each conference room.
Return to Deployment Considerations - MultiRange
Laser Tag
Laser tag is a recreational sport where participants wear infrared sensitive equipment to ‘tag’ one another during play. Players enjoy a variety of events like ‘free for all’ and team events such as ‘capture the flag’ or ‘team battle’. In this example a laser tag operator tracks players during competition and displays the data for an audience, enhancing the overall experience of the sport.
This example demonstrates how the CUWB RTLS can be used in a highly dynamic and challenging environment. There are a large number of players that move rapidly through an arena where LoS between the player and anchors within the environment can be easily blocked. The following are some considerations our operator will need to understand:
| Parameter | Description |
|---|---|
| Area | 900 sq.m arena roughly 30 x 30 meters |
| Accuracy | Operator would like <0.1m accuracy for display |
| Speed | Players sprint from area to area and move/spin rapidly |
| Tags | 48 total - 1 helmet tag, 2 shoulder tags, 1 rifle tag per player |
| Anchors | 16 Anchors in a dense installation |
Anchor Considerations
The CUWB RTLS anchors have a maximum range that is much larger than the laser tag arena so our operator isn’t worried about anchor-to-anchor communication. For best results each tag should be visible by more than 5 anchors; more anchors results in better accuracy and improved tolerance for occlusions between the tag and anchor. Our operator decides they need 8 anchors to cover the space generally, but they double that number to 16 because the arena contains a large number of obstacles that block line-of-site from the tracking area to the anchor array.
During planning our operator carefully walks through the arena identifying locations where anchors can be installed that maximize visibility. They also identify difficult areas of the arena where a player might be hidden from a majority of anchors and plan to install additional anchors to cover those areas.
Tag Considerations
Our operator plans to use the CUWB RTLS position data to display the location of players along with the rough direction that they are facing. To achieve this they place a tag on the rifle, letting them know which direction is ‘forward’ for the player. They also place a tag on the player’s helmet. The two tags would be enough to find the center of the player and orient the rifle, but our operator is cautious and wants redundancy. To achieve redundancy additional tags are placed on each shoulder. Thus, when a player is crouched, or hiding, near an obstacle that occludes the helmet the additional tags may be visible to the anchor array.
Players move rapidly through the arena sprinting from area to area. The operator would like to track these rapid movements while also displaying smooth motion in their audience map. They choose a tag beacon rate of 40 Hz, and plan to smooth the output data for display to their audience. The high data rate allows them to track the rapid movements providing head room for smoothing without much latency.
Teams consist of 10 players per side with 2 alternates, totalling 24 players for a single session. Each player wears 4 tags: one on the helmet, two for the shoulders, and one for the player’s rifle. At 40Hz the 48 total tags use 1920 LPSMultiTime. The anchors will be configured for the default 10Hz making the total LPS usage for this system 2080.
User Application
Initially our operator uses the CUWB Viewer to track tags around the arena and evaluate system performance. In order to deploy for their audience, they build a mapping application that uses the CUWB RTLS smoothed output Position data. The mapping display incorporates elements from the arena and colors the tags based on the gameplay type.
The operator maintains excess equipment to ensure devices are charged and handle potential damage. They create a management backend for the mapping application that uses the CUWB API and allows them to quickly add or remove tags as teams work their way through play sessions.
Return to Deployment Considerations - MultiTime