-
Notifications
You must be signed in to change notification settings - Fork 1
Controller
Mehul Goel edited this page Apr 9, 2025
·
17 revisions
Our current controller is based off of the Stanley Controller. An in-depth explanation of the controller can also be found later in this file.
At a high level, the controller takes in two different inputs:
- The state of the buggy at hand, which should include the position in easting, northing, the speed of the buggy, the heading of the buggy, and how the heading rate. These will henceforth be references as
$(p_x, p_y, v, \psi, \dot{\psi})$ . This should be inputted at 100Hz - The trajectory that should be followed. This comes from the
path planner, and is a new path generated at 10Hz
There is one non-debug output topic from the system, which is the steering command, capped between
-
dist- A parameter which is the initial guess to where we are on the path, is not that important as after the first iteration of the loop, we find a more accurate index -
controllerName- tells the ROS node what the name of the node is, i.e. SC_controller, SC_NAND_controller, NAND_controller -
traj_name- the name of the initial path we will be following -
stateTopic- the ROS topic name of the buggy state input. -
trajectoryTopic- the ROS topic name of the trajectory input -
controller- which controller we are using, as of right now the only option is Stanley. -
useHeadingRate- a boolean flag that if set to false, means that we don't need the input$\dot{\psi}$ , and will be further explained in the stanley controller section.
Before we allow the controller to publish steering outputs, we wait for the init checks. Below is a list of all the possible init checks:
- Has the controller ever received an odom input
- Is the covariance of the system relatively small (
$<1m^2$ ), in relation to the easting and northing position - Compared to the closest position on the path, are we faced the right direction. This is if the offset between both is in between
$[-\pi, \pi]$