From 7e4f0ca19da97fdd545524df1a16de3061d9fb10 Mon Sep 17 00:00:00 2001 From: Will Heitman Date: Wed, 21 Sep 2022 23:09:03 -0500 Subject: [PATCH] Fix Interface link, add Egan to Planning --- docs/_site/assets/js/search-data.json | 4 ++-- docs/_site/feed.xml | 2 +- docs/_site/planning/planning-overview.html | 2 +- docs/_site/system-overview.html | 2 +- docs/planning/planning-overview.md | 2 ++ docs/system-overview.md | 2 +- 6 files changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/_site/assets/js/search-data.json b/docs/_site/assets/js/search-data.json index d9bde48d0..36ad2149c 100644 --- a/docs/_site/assets/js/search-data.json +++ b/docs/_site/assets/js/search-data.json @@ -115,13 +115,13 @@ },"19": { "doc": "Planning", "title": "Planning overview", - "content": " ", + "content": "Maintained by Egan Johnson . ", "url": "/navigator/planning/planning-overview.html#planning-overview", "relUrl": "/planning/planning-overview.html#planning-overview" },"20": { "doc": "Planning", "title": "Table of contents", - "content": ". | Planning overview . | The Strategy | Zone Features | Calculating the Trajectory: Assigning speed to the path | Zone sources | . | . “Planning” refers to the part of the system that synthesizes perception and scenario information into an actionable decision that can be handed to controls. Our current control stack is designed for Demo 2 tasks, at its applicability to other tasks is limited. ", + "content": ". | The Strategy | Zone Features | Calculating the Trajectory: Assigning speed to the path | Zone sources | . “Planning” refers to the part of the system that synthesizes perception and scenario information into an actionable decision that can be handed to controls. Our current control stack is designed for Demo 2 tasks, at its applicability to other tasks is limited. ", "url": "/navigator/planning/planning-overview.html#table-of-contents", "relUrl": "/planning/planning-overview.html#table-of-contents" },"21": { diff --git a/docs/_site/feed.xml b/docs/_site/feed.xml index 3f0e2833e..d8c7c14dd 100644 --- a/docs/_site/feed.xml +++ b/docs/_site/feed.xml @@ -1,4 +1,4 @@ -Jekyll2022-09-21T23:01:09-05:00http://localhost:8083/navigator/feed.xmlNavigatorNavigator is an open-source autonomous driving system developed by Nova, an applied research group at UT Dallas.Welcome to Jekyll!2022-09-05T21:27:33-05:002022-09-05T21:27:33-05:00http://localhost:8083/navigator/jekyll/update/2022/09/05/welcome-to-jekyll<p>You’ll find this post in your <code class="language-plaintext highlighter-rouge">_posts</code> directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run <code class="language-plaintext highlighter-rouge">jekyll serve</code>, which launches a web server and auto-regenerates your site when a file is updated.</p> +Jekyll2022-09-21T23:08:27-05:00http://localhost:8083/navigator/feed.xmlNavigatorNavigator is an open-source autonomous driving system developed by Nova, an applied research group at UT Dallas.Welcome to Jekyll!2022-09-05T21:27:33-05:002022-09-05T21:27:33-05:00http://localhost:8083/navigator/jekyll/update/2022/09/05/welcome-to-jekyll<p>You’ll find this post in your <code class="language-plaintext highlighter-rouge">_posts</code> directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run <code class="language-plaintext highlighter-rouge">jekyll serve</code>, which launches a web server and auto-regenerates your site when a file is updated.</p> <p>Jekyll requires blog post files to be named according to the following format:</p> diff --git a/docs/_site/planning/planning-overview.html b/docs/_site/planning/planning-overview.html index aba27fa4b..5b3b47761 100644 --- a/docs/_site/planning/planning-overview.html +++ b/docs/_site/planning/planning-overview.html @@ -1,4 +1,4 @@ - Planning - Navigator Planning | Navigator Skip to main content Link Search Menu Expand Document (external link)
This site uses Just the Docs, a documentation theme for Jekyll.

Planning overview

Table of contents

  1. Planning overview
    1. The Strategy
    2. Zone Features
    3. Calculating the Trajectory: Assigning speed to the path
    4. Zone sources

“Planning” refers to the part of the system that synthesizes perception and scenario information into an actionable decision that can be handed to controls. Our current control stack is designed for Demo 2 tasks, at its applicability to other tasks is limited.

The Strategy

The current strategy generates a determined path (i.e. spatial trajectory), which it assigns velocities to based on the situation. There are currently three modifying factors on assigned velocity: the speed limit, the curvature of the path (to avoid taking sharp turns at high speeds), and most importantly zones.

A “zone” is a closed polygon that limits the speed that the vehicle can have when passing through the enclosed space. They are generated from a variety of sources, and are used to control the vehicles behavior: if any node wishes to stop the vehicle from entering an intersection, for example, they would enclose the intersection with a zone of speed 0.

Zone Features

  • Zones are defined by the points describing an enclosed polygon and a non-exceed speed
  • Any single zone is homogenous, meaning the non-exceed speed is constant within the zone
  • Zones may overlap. In this case, the lowest non-exceed speed must be obeyed
  • Zones may have a speed of 0
  • Zones don’t evolve through time: instead, a new zone must replace the old zone

Calculating the Trajectory: Assigning speed to the path

The path is turned into a trajectory by assigning speed. The trajectory should be safe, comfortable, and possible, and should obey the zones. The process for assigning velocities works as follows:

  1. For each point, set its speed to the speed limit of the lane
  2. For each point, calculate the local curvature of the path. Using the path curvature, limit the speed for that point so that the lateral acceleration of the vehicle is never more than a configured maximum
  3. For each zone, determine if it intersects with the trajectory. If it does:
    1. The trajectory is a discrete path, so the first point affected may be further from the edge of the zone than we would like. To observe the speed limitation starting from the very edge of the zone, insert a new point to the trajectory where it intersects the zone (both entering and exiting)
    2. Set the speed of this new point to the lowest speed among its adjacent points the zone
    3. For all points within the zone, set the speed to no greater than the zone speed
  4. Do a backwards pass of the trajectory, and lower the speed of each point so that the speed of the next point (next in time, previous point in the pass) can be achieved with comfortable deceleration. The only time this may not be physically obtainable is immediately in front of the vehicle when it is moving too fast: in this case, lower the speed anyway and let the controller sort it out
  5. Do a forwards pass of the trajectory, and lower the speed of each point so it can be reached from the previous point using a comfortable acceleration

Although the path itself may extend from the origin to the destination, only the points within a certain horizon of the vehicle need to be considered for the trajectory.

Notice that aside from step 1, the speed is never increased. The vehicle should be cautious, meaning that if there is a reason to go slow and a reason to go regular speed, the reason to go slow wins as a rule of thumb. Since this is true, as long as acceleration/deceleration smoothing is done last, the other steps can be done in any order.

void MotionPlannerNode::send_message() {
+     Planning - Navigator       Planning | Navigator                 Skip to main content   Link      Search      Menu      Expand      Document       (external link)    
 
       
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
  
 
 
  Planning overview 
 
Maintained by Egan Johnson
 
  Table of contents 
 
     
  1. The Strategy
    2.  
  2. Zone Features
    3.  
  3. Calculating the Trajectory: Assigning speed to the path
    4.  
  4. Zone sources
    5.  
 
“Planning” refers to the part of the system that synthesizes perception and scenario information into an actionable decision that can be handed to controls. Our current control stack is designed for Demo 2 tasks, at its applicability to other tasks is limited.
 
  The Strategy 
 
The current strategy generates a determined path (i.e. spatial trajectory), which it assigns velocities to based on the situation. There are currently three modifying factors on assigned velocity: the speed limit, the curvature of the path (to avoid taking sharp turns at high speeds), and most importantly zones.
 
A “zone” is a closed polygon that limits the speed that the vehicle can have when passing through the enclosed space. They are generated from a variety of sources, and are used to control the vehicles behavior: if any node wishes to stop the vehicle from entering an intersection, for example, they would enclose the intersection with a zone of speed 0.
 
  Zone Features 
 
     
  • Zones are defined by the points describing an enclosed polygon and a non-exceed speed
    •  
  • Any single zone is homogenous, meaning the non-exceed speed is constant within the zone
    •  
  • Zones may overlap. In this case, the lowest non-exceed speed must be obeyed
    •  
  • Zones may have a speed of 0
    •  
  • Zones don’t evolve through time: instead, a new zone must replace the old zone
    •  
 
  Calculating the Trajectory: Assigning speed to the path 
 
The path is turned into a trajectory by assigning speed. The trajectory should be safe, comfortable, and possible, and should obey the zones. The process for assigning velocities works as follows:
 
     
  1. For each point, set its speed to the speed limit of the lane
    2.  
  2. For each point, calculate the local curvature of the path. Using the path curvature, limit the speed for that point so that the lateral acceleration of the vehicle is never more than a configured maximum
    3.  
  3. For each zone, determine if it intersects with the trajectory. If it does: 
       
    1. The trajectory is a discrete path, so the first point affected may be further from the edge of the zone than we would like. To observe the speed limitation starting from the very edge of the zone, insert a new point to the trajectory where it intersects the zone (both entering and exiting)
      2.  
    2. Set the speed of this new point to the lowest speed among its adjacent points the zone
      3.  
    3. For all points within the zone, set the speed to no greater than the zone speed
      4.  
     
    4.  
  4. Do a backwards pass of the trajectory, and lower the speed of each point so that the speed of the next point (next in time, previous point in the pass) can be achieved with comfortable deceleration. The only time this may not be physically obtainable is immediately in front of the vehicle when it is moving too fast: in this case, lower the speed anyway and let the controller sort it out
    5.  
  5. Do a forwards pass of the trajectory, and lower the speed of each point so it can be reached from the previous point using a comfortable acceleration
    6.  
 
Although the path itself may extend from the origin to the destination, only the points within a certain horizon of the vehicle need to be considered for the trajectory.
 
Notice that aside from step 1, the speed is never increased. The vehicle should be cautious, meaning that if there is a reason to go slow and a reason to go regular speed, the reason to go slow wins as a rule of thumb. Since this is true, as long as acceleration/deceleration smoothing is done last, the other steps can be done in any order.
 
void MotionPlannerNode::send_message() {
     if (ideal_path == nullptr || odometry == nullptr) {
         // RCLCPP_WARN(this->get_logger(), "motion planner has no input path, skipping...");
         return;
diff --git a/docs/_site/system-overview.html b/docs/_site/system-overview.html
index f042bf37d..2e4f79071 100644
--- a/docs/_site/system-overview.html
+++ b/docs/_site/system-overview.html
@@ -1 +1 @@
-     System overview - Navigator       System overview | Navigator                 Skip to main content   Link      Search      Menu      Expand      Document       (external link)    
 
       
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
  
 
 
  System overview 
 
Maintained by Will Heitman
 
  Table of contents 
 
     
  1. Design
    2.  
  2. Subsystems 
       
    1. Example
      2.  
     
    3.  
 
  Design 
 
Navigator is designed to be:
 
     
  • Simple, with components that are easy to use an extend 
       
    • When a more powerful but complex algorithm is used, a simpler alternative should also be present
      •  
     
    •  
  • Modular, with nodes that can be swapped, added, and updated with the help of ROS2 
       
    • Since nodes are all built using standard C++ and Python libraries, code is future-proofed.
      •  
     
    •  
  • Open source, with all of our code licensed under the highly permissable MIT license 
       
    • Our dependencies are also open-source
      •  
     
    •  
 
  Subsystems 
 
Navigator's general structure
 
Navigator is split into five main subsystems:
 
     
  • Sensing, where raw sensor data from cameras, GNSS, and more is filtered before being passed along
    •  
  • Perception, which uses the filtered sensor data to build a rich understanding of the car’s surroundings
    •  
  • Planning, which uses this rich understanding, plus the desired destination, to decide how the car should act on a high level
    •  
  • Controls, where the desired action is compared to the car’s current state and low-level action is calculated
    •  
  • Interface, where the low-level action is sent to the steering wheel and pedals.
    •  
 
We also have some important code to support testing, visualization, and simulation. Simulation plays a big role in our development, and you can find an overview of it here.
 
  Example 
 
Our sensing system takes in a red blob from our front camera and does some white balancing to make the image more clear. The perception system identifies this red blob as a stop sign and generates a bounding box with the coordinates of the stop sign relative to the car. The planning system determines that we must set our speed to zero at the stop sign. The controls system notes that our car is still moving, and calculates that we must decelerate a certain amount. Finally, our actuation system converts this desired deceleration into a brake pedal command, which is sent out to the pedal’s motor.
 
 
 
 
  
+     System overview - Navigator       System overview | Navigator                 Skip to main content   Link      Search      Menu      Expand      Document       (external link)    
 
       
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
  
 
 
  System overview 
 
Maintained by Will Heitman
 
  Table of contents 
 
     
  1. Design
    2.  
  2. Subsystems 
       
    1. Example
      2.  
     
    3.  
 
  Design 
 
Navigator is designed to be:
 
     
  • Simple, with components that are easy to use an extend 
       
    • When a more powerful but complex algorithm is used, a simpler alternative should also be present
      •  
     
    •  
  • Modular, with nodes that can be swapped, added, and updated with the help of ROS2 
       
    • Since nodes are all built using standard C++ and Python libraries, code is future-proofed.
      •  
     
    •  
  • Open source, with all of our code licensed under the highly permissable MIT license 
       
    • Our dependencies are also open-source
      •  
     
    •  
 
  Subsystems 
 
Navigator's general structure
 
Navigator is split into five main subsystems:
 
     
  • Sensing, where raw sensor data from cameras, GNSS, and more is filtered before being passed along
    •  
  • Perception, which uses the filtered sensor data to build a rich understanding of the car’s surroundings
    •  
  • Planning, which uses this rich understanding, plus the desired destination, to decide how the car should act on a high level
    •  
  • Controls, where the desired action is compared to the car’s current state and low-level action is calculated
    •  
  • Interface, where the low-level action is sent to the steering wheel and pedals.
    •  
 
We also have some important code to support testing, visualization, and simulation. Simulation plays a big role in our development, and you can find an overview of it here.
 
  Example 
 
Our sensing system takes in a red blob from our front camera and does some white balancing to make the image more clear. The perception system identifies this red blob as a stop sign and generates a bounding box with the coordinates of the stop sign relative to the car. The planning system determines that we must set our speed to zero at the stop sign. The controls system notes that our car is still moving, and calculates that we must decelerate a certain amount. Finally, our actuation system converts this desired deceleration into a brake pedal command, which is sent out to the pedal’s motor.
 
 
 
 
  
diff --git a/docs/planning/planning-overview.md b/docs/planning/planning-overview.md
index 15a511468..67802496d 100644
--- a/docs/planning/planning-overview.md
+++ b/docs/planning/planning-overview.md
@@ -5,7 +5,9 @@ nav_order: 4
 ---
 
 # Planning overview
+{: .no_toc }
 
+*Maintained by Egan Johnson*
 ## Table of contents
 {: .no_toc .text-delta }
 
diff --git a/docs/system-overview.md b/docs/system-overview.md
index cba424d68..b7b4dad5a 100644
--- a/docs/system-overview.md
+++ b/docs/system-overview.md
@@ -35,7 +35,7 @@ Navigator is split into five main subsystems:
 - [**Perception**](/navigator/planning/planning-overview), which uses the filtered sensor data to build a rich understanding of the car's surroundings
 - [**Planning**](/navigator/planning/planning-overview), which uses this rich understanding, plus the desired destination, to decide how the car should act on a high level
 - [**Controls**](/navigator/controls/controls-overview), where the desired action is compared to the car's current state and low-level action is calculated
-- [**Interface**](/navigator/interfaces/interfaces-overview), where the low-level action is sent to the steering wheel and pedals.
+- [**Interface**](/navigator/interface/interface-overview), where the low-level action is sent to the steering wheel and pedals.
 
 We also have some important code to support testing, visualization, and simulation. Simulation plays a big role in our development, and you can find an overview of it [here](/navigator/interfaces/interfaces-overview).