Skip to content
Aerin Brown edited this page Jun 21, 2025 · 10 revisions

Booting Up Drive

Booting up drive requires running three ROS nodes. You will need two terminals that are connected to the Jetson--these will run the drive_firmware_node and the drive_control_node. Then, the base station will run the gamepad_input_pub to get the controller input from your computer. You can also use the launch file under control to run both the drive_firmware_node and the drive_control_node with one terminal

To confirm that this is working, you can check for input by echoing the gamepad_input_drive, drive_speed_input, and/or drive_speed_input topics. They should all respond dynamically to your controller input.

Controller Layout

The control schema relies on a geared speed system where the rover will decelerate to 0 when receiving no input. It has two steering modes: tank and dynamic. Here is the full schema mapped:

Triangle -> switch between standard and tank control schemas

Standard Schema

X -> accelerate forward

O -> accelerate backward

Square -> acknowledge faults (if the rover ever stops responding, hit this!)

Left Trigger (L2) -> gear down (decrease max speed)

Right Trigger (R2) -> gear up (increase max speed)

Left Shoulder Button (L1) -> tank turn left

Right Shoulder Button (R1) -> tank turn right

Left Analog Stick -> dynamic steer (point wheels in direction stick points)

Tank Control Schema

Square -> acknowledge faults (if the rover ever stops responding, hit this!)

Left Analog Stick -> control speed of left wheels

Right Analog Stick -> control speed of right wheels

Control Scripts

Human drive controls consist of five primary scripts: the two drive-specific ros nodes plus three function library scripts.

steering.py provides functions to translate input into an array of wheel instructions to allow the rover to steer. Wheel_orientation_rotation() takes joystick input and interprets it as an array of angles to pass to the steering motors on the wheels. This is the function that takes the wheels and points them in a new direction. Rover_rotation() takes a button input and provides an array of wheel speeds in the form [top right, top left, bottom left, bottom right]. This is the function that causes the rover to turn tank style. Note that this is a longer function, since the direction the wheels are pointing influences which wheels need to run forward and which need to run backward.

speed_control.py provides a speed_controller class that monitors the wheel acceleration and speed for the rover. To tune the rover speed, adjust the attributes assigned in init. Gears provides a list of dictionaries that control the gears the rover locks to. The current (2025-05-31) physical maximum wheel speed is 3200 rpm. Acceleration_rate, as per its name, determines how quickly the rover speeds up. However, do note that this can also be affected by history_size, since that determines the number of previous speeds that are averaged to smooth acceleration. A bigger history size means a lower acceleration rate, regardless of what the acceleration_rate attribute is. Decceleration_rate determines how quickly the rover stops when the user stops acceleration, while downshift_deceleration_rate determines how quickly we slow down when we gear down. Note that to control turning speed, you need to look at drive_control_node.py, not speed_control.py. This file only affects straight-line motion.

drive_control_node.py takes input from the controller and uses the two files previously discussed to convert them into rover speeds. It contains an attribute that affects turning speed, which is currently (2025-05-31) set to the maximum speed. It publishes the speeds to the drive_speed_input ros topic.

drive_firmware_node.py takes the wheel speeds from the drive_speed_input ROS topic and converts it to instructions the firmware can understand. It calls the functions in driveCANCommunication.py, which send specific messages to the CAN buses. Talk to electrical for more details on this.

Clone this wiki locally