F1/10 intro

Overview:

The F1/10 platform is a modified Traxxas Rally Racer, (a 1/10th scale formula race car capable of speeds up to 40mph). The ground platform is equipped with the following sensors: Razor 9-DOF IMU, Hokuyo LIDAR, and ZED 3D camera. These sensors are responsible for localization, mapping, and odometry. A Jetson TK1 development board serves as the primary computational unit. The TK1 runs Ubuntu Linux, and we develop applications for the car using ROS Indigo. ROS provides a communication protocol between processes, language-independent build and management of applications, and a rich library of open-source packages that implement common components of robotics (e.g. perception, planning, and hardware drivers.) The modded car also includes an external battery pack, a Teensy microcontroller to provide outputs to the Traxxas electronic speed controller (ESC), and a wireless access point (WAP) that facilitates remote access to the car.

Background knowledge to review/learn:

• C/C++
• Python
• ROS framework http://wiki.ros.org/ROS/Introduction and tutorials for using it and building custom packages http://wiki.ros.org/ROS/Tutorials (note we are using ROS version: indigo) (and we use catkin to build packages)

Components:

• NVIDIA Jetson TK1 (runs Linux4Tegra OS, which is essentially Ubuntu 14.04) (http://elinux.org/Jetson_TK1) -- controls pretty much everything
• Teensyduino (on a custom circuit board) -- responsible for outputting PWM signals to the low-level motor controller that came with the racecar; load its firmware using Arduino; existing Arduino library and serial ROS package used to open up ROS communication
• Hokuyo

Demos from Fall 2016:

*** Preliminaries: connect to battery pack (and PicoStation), turn TK1 on, make sure it's connected to the correct network, unplug peripherals, turn on power to motors (this last step should be done very last just to be safe, like after ROS nodes are setup) ***

*** To SSH: ssh ubuntu@192.168.1.1 ***

• Remote keyboard control
  • In each of the following terminals, SSH into the TK1 and source the setup.bash file
    1. roscore
    2. rosrun rosserial_python serial_node.py /dev/ttyACM0 (this is what allows us to talk to the teensyduino)
    3. rosrun week1tutorial talker.py
    4. rosrun week1tutorial keyboard.py
  • Use the arrow keys (while in the keyboard.py terminal) to control the car. Use the 'backspace' key as an e-brake. Hit 'q' to quit the keyboard.py program. For all other programs (in the other terminals), CTRL-C will quit their applications.
  • Optional: open another terminal and run rostopic echo /drive_pwm to view the PWM values being sent to the teensyduino (and subsequently to the low-level motor controllers). This can be used to confirm any app is sending correct commands to the wheels, even when the motors are powered off. This testing technique should be used in initial development to ensure the car won't run itself into walls or off tables.
• Object following for an orange sign
  • In each of the following terminals, SSH into the TK1 and source the setup.bash file
    1. roslaunch zed_wrapper zed.launch
    2. rosrun rosserial_python serial_node.py /dev/ttyACM0
    3. rosrun week1tutorial talker.py
    4. rosrun cs431demo objectTracker
  • Walk around with the orange sign in front of the ZED camera to guide the car. The car will reverse if the sign is "too close" so you can use this to back the car up out of a corner for example.

Breaking down the code for the keyboard demo:

Messages

• Two primary message types:
  • drive_param: (float32) velocity, angle
  • drive_values: (int16) pwm_drive, pwm_angle
• drive_param is published on the drive_parameters topic (from keyboard to talker)
• drive_values is published on the drive_pwm topic (from talker to Teensy)
• drive_values can only take on integer values [0,2^16], but we restrict it further to [6554,13108], which is the range of values we experimentally determine is appropriate to drive the car (i.e. values corresponding to the appropriate min/max velocity and angle)
• drive_param can take on any values we choose, but if we don't standardize this range, we must be careful to use this message type consistently across different pieces of code and packages.
  • In the F1/10 tutorials, they use [-100.0,100.0] as the range. But last semester, I changed it to [9480,10080] (pwm vals, essentially) for velocity values and [-10,10] for steering.
  • Currently talker.py serves as the "translator" between the two messages types (mapping from one range of values to the appropriate pwm range of values).
• Nicole's tested values for PWM (should re-evaluate):
  • Stop range: [9560,10000], use 9780 as the stop value
  • Forward range: [10000,10080]
  • Reverse range: [9480,9560]

Teensy specifics

• Arduino structure consists of a setup function and main loop. Use setup to initialize stuff. Use the main loop to call the ROS node spinOnce() function (which will process the next message in the queue and call the corresponding callback function). These callback functions should be defined outside of these Arduino setup/loop blocks.
• We use the Teensyduino purely to output a PWM signal. Hence the critical functions we call are analogWrite_(). These functions will set up how our PWM signal looks.
• Everytime a drive_values message is received, the PWM signal's duty cycle will be adjusted according the the message's values. Note the duty cycle will not change until another analogWrite(). Hence, the angle pwm signal remains at this new duty cycle until the next incoming message. However, I modified the code so that an additional timer would reset the velocity pwm signal duty cycle to the "stop" value.

Note to self:

• We are only using single-thread at this time, so in the Arduino code, the timer cb and message cb functions can only execute one at a time. We know the timer cb takes finite amount of time and should not block anything. But it is possible that the message cb can block the timer long enough to matter if the function is made even more complex.