Demo

Getting Sample Data

We provide some sample data from the Intel Realsense T265.

You can download either a small zip file ~600 MB or a large one (more data, including both cameras & IMU) at ~3.3 GB. Both contain multiple datasets that can be used for anchor creation and querying.
Small dataset
Large dataset

Running a simple example

Create an anchor

Start the node on your own account:

roslaunch asa_ros asa_ros.launch account_id:="YOUR_ACCOUNT_ID" account_key:="YOUR_ACCOUNT_KEY" account_domain:="mixedreality.azure.net"

Alternatively, you can set the values for the account parameters in the asa_ros.launch launch file and then run it with:

roslaunch asa_ros asa_ros.launch

Play back the data (in a new terminal) if you've unzipped the bag files in your Downloads folder:

cd ~/Downloads
rosbag play bag6_small.bag

Wait for it to finish playing.

rosservice call /asa_ros/create_anchor '{anchor_in_target_frame: {header: {frame_id: camera_odom_frame}}}'

As a parameter, you need to at least specify the odometry reference frame that this anchor should be created with respect to (in this case, camera_odom_frame). This will set the anchor_in_target_frame transform to the identity.

You can also specify the new anchor's transform using:

rosservice call /asa_ros/create_anchor '{anchor_in_target_frame: {header: {frame_id: camera_odom_frame}, transform: {translation: {x: 1, y: 1, z: 1}, rotation: {x: 0, y: 0, z: 0, w: 1}}}}'

which will place the anchor at (1,1,1) with respect to the world coordinate frame.

It's also possible to provide a different frame to create the anchor relative to, using the target_frame parameter:

rosservice call /asa_ros/create_anchor '{target_frame: camera_link, anchor_in_target_frame: {header: {frame_id: camera_odom_frame}, transform: {translation: {x: 1, y: 1, z: 1}, rotation: {x: 0, y: 0, z: 0, w: 1}}}}'

which will create the anchor at (1,1,1) with respect to the camera_link frame. The target frame defaults to the world frame if it's not provided.

Using a non-world target frame can be useful to place a visualization of the anchor (axes at its origin) close to the position where the anchor features have been triangulated. However, the actual position of the anchor origin is arbitrary and will not affect localization accuracy.

You can get the ID of the created anchor by calling:

rostopic echo /asa_ros/created_anchor

Or if you just want to see the latest created anchor:

rostopic echo /asa_ros/created_anchor -n 1

It is also possible to recover the id of the last anchor that was created, even after the node is shut down. The last created anchor id is cached to $HOME/.ros/last_anchor_id (or /tmp/last_anchor_id if $HOME is not defined). By setting the query_last_anchor_id_from_cache parameter to true, the node will automatically search for the last created anchor (by reading its id from the cache), so the user does not need to manually copy the anchor ids around.

Query an anchor

Start the node on your own account. The easiest is to enter the anchor ID you want to track as the anchor_id parameter:

roslaunch asa_ros asa_ros.launch account_id:="YOUR_ACCOUNT_ID" account_key:="YOUR_ACCOUNT_KEY" account_domain:="mixedreality.azure.net" anchor_id:="YOUR_ANCHOR_ID"

If you've set your account parameters in the launch file, you can simply run:

roslaunch asa_ros asa_ros.launch anchor_id:="YOUR_ANCHOR_ID"

As before, play a rosbag:

rosbag play bag7_small.bag

You can then see the pose of the found anchor by calling:

rostopic echo /asa_ros/found_anchor

Or just once:

rostopic echo /asa_ros/found_anchor -n 1

It will also be published on to the TF tree, so you can see it in rviz:

TF frames of Anchors shown in RVIZ.

To find a new anchor not at the start of execution, you can also call the find_anchor service:

rosservice call /asa_ros/find_anchor "anchor_id: 'YOUR_ANCHOR_ID_HERE'"

If the service is called again before a previous call returns, the new request will override the first.

If you want to search for multiple anchors in an environment, you have two options.

You can enter a comma-separated list of anchor IDs, to the parameter or the service call, and the SDK will search for all of them and return once it can localize to one of them. This approach can be useful if you've created a set of anchors within a single session and you want to localize to them, since anchors created in a single session will be connected in the cloud. It's also possible for anchors to be connected over multiple sessions, but this requires them to be created carefully; more information about this can be found in the ASA Docs.
If your anchors were created such that they are not connected (e.g. isolated anchors created in different sessions), then you can only localize to one of them at a time. To accomplish this within the SDK framework, you can search for a list of them each time, and you will receive a localization to whichever anchor is found first. However, this may result in unexpected results unless you don't care which anchor you localize to. Instead, a better approach is to search for anchors with sequential calls to the find_anchor service, only moving to the next anchor after the previous one has been localized. In most cases, it is more convenient to take care during anchor creation to ensure connected anchors so that the approach in 1. can be used.