Difference between revisions of "Project ROS"

From MAE/ECE 148 - Introduction to Autonomous Vehicles
Jump to: navigation, search
(Controlling the Donkey Car Using ROS Nodes)
(Controlling the Donkey Car Using ROS Nodes)
Line 135: Line 135:
Our central subscriber node is named '''controls_receiver.py''', and utilizes Python as the language of operation. The controls_receiver node makes use of the '''actuator.py''' file located in the same folder.
Our central subscriber node is named '''controls_receiver.py''', and utilizes Python as the language of operation. The controls_receiver node makes use of the '''actuator.py''' file located in the same folder.
To run this node, make sure roscore is running:
To run this node, make sure roscore is running. On the terminal:
Then run the command:
rosrun (package location) controls_receiver.py
By default, if you are using '''driving_donkey''' as the name for the package:
rosrun driving_donkey controls_receiver.py
'''Additional Nodes'''
'''Additional Nodes'''

Revision as of 17:00, 23 March 2018

What is ROS?

Getting Started with ROS


For reference, a list of commonly-used, core ROS commands and functions have been compiled for your convenience and can be accessed HERE.

Controlling the Donkey Car Using ROS Nodes

Utilizing the Donkeycar framework, in theory, should be simple: a direct publisher-subscriber connection should suffice to directly operate and control the Donkeycar. To accomplish this, the following is implemented:

  > A publisher node to receive specified keyboard inputs and post them to the controls topic for subscribers to draw from.
  > A subscriber node to receive values posted to the controls topic and send them to the motors to operate the Donkeycar.

Specified details are described below. All of the following code can be found on GitHub at the following repository:

Winter 2018 "driving_donkey" ROS Package

Main Publisher Node: keyboard_inputs

Our central publisher node is named keyboard_inputs.py, and utilizes Python as the language of operation. This publisher node is organized such that additional keyboard-input features can easily be implemented for future projects.

The backbone of this node is built from the curses library, a powerful set of functions leveraging user keyboard inputs. Please note that this publisher node utilizes the curses library, so if you do not have it downloaded on your RPi (or similarly, if you receive an error stating that "import curses" failed), run the command:

  pip install curses

This will install the curses library on your machine.

Documentation for the curses library can be found HERE. We highly recommend taking a look through the various functions available through this library, to understand the scope of its functionality as well as to inspire potential add-ons to the current set of curses functions implemented in our publisher node.

In general, this program takes in a specified keyboard input (namely, the arrow keys, q, or spacebar) to modify the servo and speed control motors' PWM values. A list of currently-accepted keyboard inputs is shown below:

  > q: Shutsdown the user interface and node. NOTE: This command must be used in place of CTRL-C.
     Attempting to use CTRL-C to exit the node will effectively crash the terminal window.
  > spacebar: Fast stop. Pressing this immediately resets the speed control PWM to its neutral value.
  > left/right arrow: Decreases/Increases the servo (steering) motor PWM values posted to the controls topic
  > up/down arrow: Decreases/increases the speed control motor PWM values posted to the controls topic

Let's break down the code to see exactly what is going on. The first thing to note is that this file references the config.py file utilized in our traditional Donkey framework:

  from config import *

From here, the script pulls the max/neutral/min steering/throttle PWM values determined from the original Donkeycar calibration. Make sure an (updated) copy of this file identical to the one in your d2 folder exists in the same directory where keyboard_input.py exists. The next thing to note is that the type of message we'll be uploading to the controls topic is a double-precision float set of arrays:

  from std_msgs.msg import Int16MultiArray

This allows us to post all the PWM values simultaneously to our topic without having to send multiple messages. Each PWM value will be held in a different element of the array. This also allows to easily expand the scope of our message to send additional commands to the topic, should future features be implemented (for example, a binary on/off switch to initialize stereo vision). The next few sets of lines initialize the curses UI. Specific documentation of these commands may be found in the curses library link posted above. The next important line is the initialization of our safety timeout value:

  no_response_max_time = 5000 # milliseconds

Every time a keyboard input is triggered, a built-in counter within the curses framework resets to 0. This timer then counts the number of milliseconds before another keyboard input occurs; if no input is detected within the specified time (in this case, 5000 ms = 5 seconds), the interrupt-style function screen.getch() outputs -1 (in contrast to 'q', 'b', or any other character on the keyboard). This allows us to create a case that does something in the case that we experience a user timeout, i.e.: screen.getch() == -1. For our purposes, this will be a safety switch that automatically resets both the steering and throttle to its neutral positions (more on that below). The next important lines are the initialization of important parameters:

  rate = rospy.Rate(100) # 100hz
  steering_neutral = round((STEERING_RIGHT_PWM + STEERING_LEFT_PWM)/2.0)
  throttle_neutral = THROTTLE_STOPPED_PWM + 10
  steering_scale = 15

Our rospy rate is set to 100Hz -- thus messages are being published to the controls topic at a maximum rate of 100/second. This, of course, will rarely happen since messages are only going to be published when the user presses a key! Steering_neutral, throttle_neutral, throttle_max, throttle_min are all straightforward -- as mentioned earlier, these commands draw upon the config.py values to determine the bounds of potential PWM values to be posted to the topic. Lastly, steering_scale determines how much the PWM changes each time the user presses the right/left arrow keys. Next is our initialization of our publisher message:

  pwm_input = Int16MultiArray()
  pwm_input.data = [steering_neutral,throttle_neutral]

We initialize message pwm_input or type Int16MultiArray, which currently includes [steering, throttle] values set to their respective neutral values. These values will be dynamically updated and reposted to the controls topic as the user provides keyboard inputs. Additional parameters can easily be appended to the message by adding additional elements to the current array.

Now, onto the bulk of the script -- the case-based commands. In general, right/left and up/down keys do the same thing, but in a reverse direction, so only one of each will be documented here. The first part of the right key case checks to see if the current PWM is already maxed out -- if it is, nothing changes:

  elif char == curses.KEY_RIGHT:
       # print doesn't work with curses, use addstr instead
       if pwm_input.data[0] >= STEERING_RIGHT_PWM:
            # limit the steering max value (right side)
            pwm_input.data[0] = STEERING_RIGHT_PWM

If the current steering PWM falls between the MIN and MAX values, it will be changed by +steering_scale (+15):

            pwm_input.data[0] += steering_scale

The next chunk of text is purely for ease-of-use purposes. If a user is remotely controlling the car, they will be unable to visually see how far their wheels are turned -- that is, it will be hard to intuitively know how dramatic they are currently turning. Thus a visual aid was provided: Each time the right arrow is triggered, a '>' added to the screen so the user can see relatively how far over the user is turning. For example, if the node is currently posting a steering_PWM of neutral+3*steering_scale, the user would see the following on the terminal window:

  [         O>>>   ]

The reverse would be true for the user pressing the left arrow key.

The up/down cases are much more straightforward. Similar to the right/left case, the node checks to make sure the user input doesn't cause the resulting PWM throttle value to fall outside of its MIN/MAX range:

  elif char == curses.KEY_UP:
       if pwm_input.data[1] >= throttle_max:
            # limit the steering max value
            pwm_input.data[1] = throttle_max

Otherwise, the node adjusts its throttle PWM by +1

       pwm_input.data[1] += 1

Now, let's analyze the special cases. The first occurs when the user presses spacebar. This immediately resets the throttle to zero:

  elif char == ord(' '):
       # hard stop -- hitting spacebar resets the throttle PWM to neutral 
       pwm_input.data[1] = throttle_neutral

Lastly, the timeout case is utilized -- this resets both the steering and throttle PWMs to neutral:

  elif char == -1:
       # Increase the safety counter, in case connection is lost this will trigger a stop
       pwm_input.data = [steering_neutral,throttle_neutral]

In each case, the user terminal screen is updated to reflect the current state of the steering/throttle PWM values:

       screen.addstr(3, 0, \
                   'Currently outputting:'\
                   '[Steering PWM, Throttle PWM] = ')
       screen.addstr(3, 52, str(pwm_input.data))

The remainder of the code cleans up the curses platform in the case the node is exited.

LOGISTICAL CHALLENGES: We (sadly) found out that most laptop keyboards only accept 2 simultaneous keys at once, and can only read a single key continuously at a time. This holds problems when trying to quickly and dynamically control the car, such as rapidly changing steering from right to left, or trying to control both throttle and steering simultaneously (ex: holding both the right and up keys at once). This can be solved by utilizing an external/separate keyboard, but this is clearly not optimal. It would be practical to find an alternate solution to this problem.

Main Subscriber Node: controls_receiver

Our central subscriber node is named controls_receiver.py, and utilizes Python as the language of operation. The controls_receiver node makes use of the actuator.py file located in the same folder.

To run this node, make sure roscore is running. On the terminal:


Then run the command:

rosrun (package location) controls_receiver.py

By default, if you are using driving_donkey as the name for the package:

rosrun driving_donkey controls_receiver.py

Additional Nodes

NOTE: These nodes DO NOT CURRENTLY WORK. Our team was unable to solve the logistical bug issues that resulted when attempting to run these nodes. Specific errors and their speculated causes are described below.


Potential Future Work