Jkeller/update docs

configure.sh

@@ -0,0 +1,51 @@
+#!/bin/bash
+
+# setup
+
+SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
+BOLDCYAN="\e[1;96m"
+YELLOW="\e[;33m"
+ENDCOLOR="\e[0m"
+
+confirm_no() { #https://stackoverflow.com/questions/3231804/in-bash-how-to-add-are-you-sure-y-n-to-any-command-or-alias
+    read -r -p "${1:-Are you sure? [y/N]} " response
+    case "$response" in
+        [yY][eE][sS]|[yY]) 
+            true
+            ;;
+        *)
+            false
+            ;;
+    esac
+}
+
+
+# Generate user.config.json
+USER_CONFIG_JSON_SOURCE=${SCRIPT_DIR}/simulation/isaac-sim/docker/user_TEMPLATE.config.json
+USER_CONFIG_JSON_DESTINATION=${SCRIPT_DIR}/simulation/isaac-sim/docker/user.config.json
+
+echo -e "${BOLDCYAN}1. Generating Default IsaacSim Config ($USER_CONFIG_JSON_DESTINATION)${ENDCOLOR}"
+
+if [ -f $USER_CONFIG_JSON_DESTINATION ]; then
+    echo -e "${YELLOW}WARNING: The file $USER_CONFIG_JSON_DESTINATION already exists.${ENDCOLOR}"
+    confirm_no "Do you want to reset it to the default? [y/N]" && cp $USER_CONFIG_JSON_SOURCE $USER_CONFIG_JSON_DESTINATION
+else
+    cp $USER_CONFIG_JSON_SOURCE $USER_CONFIG_JSON_DESTINATION
+fi
+
+
+# AirLab Nucleus Login Config
+OMNI_PASS_SOURCE=${SCRIPT_DIR}/simulation/isaac-sim/docker/omni_pass_TEMPLATE.env
+OMNI_PASS_DESTINATION=${SCRIPT_DIR}/simulation/isaac-sim/docker/omni_pass.env
+
+echo -e "${BOLDCYAN}2. Configure AirLab Nucleus Login ($OMNI_PASS_DESTINATION)${ENDCOLOR}"
+
+echo "Go to https://airlab-storage.andrew.cmu.edu:8443/omni/web3/, log in, then right click on the cloud and click the \"API Tokens\" window to generate an API token and paste it here. Leave this blank if you want to skip this step: "
+if [ -f $OMNI_PASS_DESTINATION ]; then
+    echo -e "${YELLOW}WARNING: The file $USER_CONFIG_JSON_DESTINATION already exists, leave it blank to skip.${ENDCOLOR}"
+fi
+read -r -p "API Token: " API_TOKEN
+
+if [ ! -z "${API_TOKEN}" ]; then
+    sed "s/PASTE-YOUR-API-TOKEN/$API_TOKEN/g" $OMNI_PASS_SOURCE > $OMNI_PASS_DESTINATION
+fi

docs/getting_started.md

@@ -22,12 +22,7 @@ Install [Docker Desktop](https://docs.docker.com/desktop/install/ubuntu/). This
 
 ## Configure
 
-Follow the instructions in `docker/isaac-sim/omni_pass.env` to configure the required settings for your Omniverse Nucelus Server token.
-To generate a token, follow the NVIDIA docs [here](https://docs.omniverse.nvidia.com/nucleus/latest/config-and-info/api_tokens.html). See here for more information:
-https://airlab.slite.com/app/docs/X8dZ8w5S3GP9tw
-
-Also set the default OMNI_SERVER and accept the license terms. (Basti: The omni_server variable doesn't seem to work. The content browser might have to be edited manually the first time. To do that click:
-"Add new connection ..." and enter airlab-storage.andrew.cmu.edu:8443 in the server field. Also if there is a localhost it should be removed since we are not running a local Nucleus server.
+Run `./configure.sh` and follow the instructions in the prompts to do an initial configuration of the repo.
 
 ## Docker Images
 

docs/robot/autonomy/3_local/controls.md

@@ -4,3 +4,50 @@ The controller should publish control commands directly to topics defined by the
 
 ## Trajectory Controller
 
+### Overview
+
+The trajectory controller takes in a trajectory and publishes a tracking point, which a controller should make the drone fly to, and a look ahead point, which a planner should plan from. The trajectory controller can interpret a trajectory as a standalone complete track, like a figure eight or racetrack pattern for tuning controls, or as separate segments that should be stitched together, for example trajectories output by a local planner.
+
+The trajectory controller tries to keep the tracking point ahead of the robot in a pure pursuit fashion. The robot's position, the red X in the figure below, is projected onto the trajectory. A sphere, shown in 2d as the cyan circle, is placed around this projected point and the intersection between the sphere and the forward point on the trajectory is used as the tracking point, the blue X. The lookahead point, the orange X, is a fixed time duration along the trajectory.
+
+![Trajectory Controller](trajectory_controller.png)
+
+### Modes
+
+There are several modes that the trajectory controller can be placed in with a service call to the `set_trajectory_mode` service:
+
+#### TRACK
+
+This interprets a trajectory published on `trajectory_override` as a complete trajectory that the controller will follow. It is usually used for taking off, landing, and tuning controls on fixed trajectories like figure eights, racetracks, circles, etc...
+
+#### ADD_SEGMENT
+
+This interprets a trajectory published on `trajectory_segment_to_add` as a segment of a trajectory which will get stitched onto the current trajectory at the closest point to the start of the new segment. This is usually published by a local planner. Ideally it is published at the location of the lookahead point, which is a fixed time ahead of the tracking point. This fixed time should be greater than the time it takes to plan. For example, if the lookahead point is one second ahead of the tracking point, the local planner should be always take less than one second to plan otherwise the tracking point would already be past the start of the plan. If this happens, the trajectory will fail to be stitched and will be ignored.
+
+#### PAUSE
+
+This causes the tracking point to stop where it is.
+
+#### REWIND
+
+This makes the tracking point go backwards along the trajectory. This mode is usually used to make the drone blindly backtrack along its trajectory to get it out of a situation it is stuck in.
+
+#### ROBOT_POSE
+
+This makes the tracking point and lookahead point always be at the same position as the drone's odometry. This is useful for before takeoff, when the robot may be carried around so that the location where the takeoff starts is at the drone's position.
+
+### PARAMS
+
+- `tf_prefix` - The tf names published are prefixed with the string in this parameter. Tfs are published at the tracking point and lookahead point. There are stabilized version, the same but with zero pitch and roll, of these two tfs that are also published.
+
+- `target_frame` - The tracking point and lookahead point are published in this frame.
+
+- `look_ahead_time` - How far ahead of the tracking point the lookahead point will be in seconds.
+
+- `min_virtual_tracking_velocity` - If the velocity on the trajectory is less than this, the tracking point will just move forward in time instead of using the sphere to keep the tracking point ahead of the drone. The units are m/s.
+
+- `sphere_radius` - This is the radius of the sphere used to determine the position of the tracking point. Making it larger pushes the tracking point farther ahead.
+
+- `search_ahead_factor` - To search for the point on the trajectory that intersects with the sphere, the algorithm checks a certain distance ahead along the trajectory. This distance is given by `sphere_radius * search_ahead_factor`. If the trajectory zig zags a lot relative to the size of the sphere its possible that the algorithm wouldn't iterate far enough along the trajectory to find the point where it intersects with the sphere. If a large value for this parameter is used it and the trajectory loops back on itself, it is possible that this would cause the tracking point to jump ahead and skip a porition of the trajectory. In almost all cases, this parameter shouldn't need to be changed.
+
+- `traj_vis_thickness` - The thickness of the trajectory visualization markers.

docs/robot/autonomy/5_behavior/behavior_executive.md

@@ -0,0 +1,19 @@
+# Behavior Executive
+
+The behavior executive reads which actions are active from the behavior tree and implements the behavior which these actions should perform and sets the status of the actions to SUCCESS, RUNNING, or FAILURE. It also sets the status of conditions as either SUCCESS or FAILURE.
+
+A typical way of implementing the behavior for an action is the following in the 20 Hz timer callback:
+
+```
+if(action->is_active()){
+  if(action->active_has_changed()){
+    // This is only true when the when the action transitions between active/inactive
+    // so this block of code will only run once whenever the action goes from being inactive to active.
+    // You might put a service call here and then call action->set_success() or action->set_failure()
+    // based on the result returned by the service call.
+  }
+
+  // Code here will get executed each iteration.
+  // You might call action->set_running() while you are doing work here.
+}
+```

simulation/isaac-sim/docker/.gitignore

@@ -1,2 +1,3 @@
 omni_pass.env
-.bash_history
+.bash_history
+user.config.json

simulation/isaac-sim/docker/docker-compose.yaml

@@ -53,6 +53,7 @@ services:
       - ~/docker/isaac-sim/logs:/root/.nvidia-omniverse/logs:rw
       - ~/docker/isaac-sim/data:/root/.local/share/ov/data:rw
       - ~/docker/isaac-sim/documents:/root/Documents:rw
+      - ./user.config.json:/root/.local/share/ov/data/Kit/Isaac-Sim/4.1/user.config.json:rw
       # developer stuff
       - .dev:/root/.dev:rw # developer config
       - .bashrc:/root/.bashrc:rw # bash config