Car Overview

Detailed overview, setup instructions, and documentation of the steps we did can be found here*.

Getting started on developing and testing for the car:

Assuming you are working with an assembled car (more or less following the steps outlined here predominantly, with the help of these steps), you might be wondering how you should...

• Set up your local machine:
  • Install ROS (Kinetic or Indigo) on Ubuntu (use VM if needed, Nicole uses Ubuntu 14.04 with Parallels on OS X)
  • Your favorite IDE (or not) for Python or C++
• Implement a new "task" application:
  • What components will you need (e.g. LIDAR, IMU, motors)? Understand existing message types for interfacing with these. Consider writing a launch file to initiate all the necessary scripts/processes for running each of these components.
  • Is there an existing ROS package for achieving what you want to do (e.g. SLAM)?
  • Write a program as usual in your choice of Python or C/C++. Can use standard libraries and import additional libraries, the main difference within the ROS framework is adding in ROS libraries (which provides objects like ROS nodes and methods for communication between ROS processes).
• Build a "driver" (an application that interfaces with the hardware component and likely processes its output data if it is a sensor):
  • What libraries do you need (e.g. OpenCV)?
  • If there is custom firmware involved (e.g. the Arduino code for Teensyduino), make sure that you're bridging the two sides (e.g. setting consistent baud rates or using the same libraries to enable passing ROS message types or creating ROS nodes).
  • This is much like writing any task application, but your mindset is to keep this application as reusable as possible for a single component (e.g. stereo camera) or class of component.
• Add/swap out a part:
  • Physical mount: we now have a couple sensor mount design options to take inspiration from (and many loose parts that can be reused/repurposed). If it's more than a minor change, consider re-designing the sensor mount altogether.
  • Configure the component: follow the manufacturer's instructions for configuration. If the new part has its own microprocessor (e.g. the IMU or Teensyduino), you will likely need additional software like Arduino IDE to write/edit/load the firmware. (Other components like the LIDAR or Picostation still required some initial configuration to set up IP addresses or choose mode of operation.)
  • Configure your machine: using the serial port? Figure out the name of the port assigned to your component; consider creating an alias.
  • Driver: if your goal is to get it running as quickly as possible, then first search for ROS packages that support interfacing with this component (e.g. we use the razor_imu_9dof package for our IMU and rosserial_python to exchange ROS messages with the Teensyduino).
  • For any of these steps where you need to import/install libraries/software on the car's computer, just bear in mind that the Jetson TK1 runs an ARM processor, which is not always supported (when looking for support, I find it useful to search "how to install xx on Rasperry Pi").
• Debug!
  • Hardware rarely runs as smoothly as you want (consistently). Run older stable code (e.g. the remote keyboard control app) to isolate the problem (e.g. communication error on the ROS layer, malfunctioning auxiliary part like Teensyduino, or bad physical connector.) If anything goes wrong, you should get familiar with the build procedure to understand how each component and interconnection works.
  • Software: if you're writing a new app, you can test/debug by 1) watching the messages passed on ROS topics, 2) running it in a simulator like Gazebo (doable but somebody needs to set this up), 3) keeping the car on a stand so that it can't wreck itself (or keeping the motors off altogether).

Running a Koord/StarL application on the car:

• The primary step remaining is to develop a waypoint following controller for the car in ROS (this would become the equivalent of the ArduPilot on quadcopter).
• To run the firefighting app as we do on the quadcopter:
  • Ensure the waypoint following ROS app takes waypoints as inputs
  • Publish an "ack" message (which the Java program will be waiting for) when the car has reached the given waypoint
  • Sketch of the needed ROS program:
    1. Subscribe to the topic publishing waypoints
    2. Subscribe to the topic publishing the car's current position (i.e. from VICON or Decawave; alternatively, can write a separate app that estimates the car's pose from available sensors (e.g. IMU, camera, motor encoder))
    3. Publish to topic for acks to StarL
    4. Publish to topic for inputs to motor controller (currently topic name is called "drive_parameters", with message type "drive_param")
    5. Create/initialize a ROS node for this application
    6. When a waypoint message is received, implement controller to guide the car towards the waypoint (likely using feedback with err = ref_waypoint - curr_waypoint).
    7. When |err|<epsilon, publish an ack and wait until next waypoint is received.

*Some of this has been ported to the wiki in our corresponding repo, with the addition of some work that Tanya completed.