Jetson RACECAR Build – Software Install

The software install for the Jetson RACECAR is a multi-step process. Looky here:


There are a couple of different ways to install the software for the Jetson RACECAR. The MIT RACECAR repository on Github has instructions on how to directly install their software from a conveniently provided disk image. For the purposes of the Jetson RACECAR, we will build the entire software stack which includes flashing the Jetson RACECAR with JetPack, and loading ROS. This process takes a couple of hours depending on your Internet connection speeds.

The procedures here to prepare the Jetson RACECAR for software development have all been covered on JetsonHacks before, but the difference here is that we string them all together.

For the purposes of this development project, we added a 120GB SSD with a cable to the RACECAR. Looky here:


In this article, the Host PC refers to a PC that is running Ubuntu. The Jetson RACECAR is the Jetson onboard the RACECAR itself. In the current RACECAR, this is a Jetson TX1. The PC is used to run JetPack, an installer which flashes the Jetson RACECAR with Linux 4 Tegra (L4T) and various useful libraries. Article references are provided for more detailed instructions.

Note: We’re working on the Jetson RACECAR side of the install, there is also a PC Host side which will come later in the series.

Before we start installing the software, we partition and format the SSD. We start with:

$ sudo parted /dev/sda/ mklabel gpt

and then create a partition and format using the Disks app.

Once the SSD is prepared, we set the SSD as the root directory, as described here. We’re then ready to start building our software development environment on the RACECAR.

Here’s the software installation sequence:

On the Host PC:

  • Use JetPack from a Host PC to flash the Jetson with L4T. We’re using a Jetson TX1, so we select that option in the installer.
  • We use JetPack to install all of the specialized libraries listed, but do not choose to compile the samples.

On the Jetson RACECAR

If you are familiar with Jetson software development, there are not any surprises here. If you’re new to all this, read through the linked articles and watch the associated videos to become familiar with the subject matter.


With the prepared development environment, now we can start building the actual Jetson RACECAR packages for ROS so that we can start to command the car to do our bidding!

Off to Part II


  1. It is very intelligible and clear. If publications are in the same style, then it will be one of the best instructions for projects.

  2. Hello Jim, thanks for the instruction.
    Sorry for my ignorance. I’m a bit lost in terms of the big picture of the RACECAR project, so I have some questions. First, what’s is the purpose of IMU?. Second, why do we need a router on board that platform? Is that for telemetry or debugging or something else? Lastly, in the end what do we have to control? The steering servo and ESC’s throttle or just the steering servo? Sorry for asking many questions Jim, been a while under the rock, suddenly wake up and everything change šŸ˜€

  3. The IMU provides orientation information, which is used when calculating robot poses.
    The router is used at MIT for better linkage to a base station as it travels through the tunnels. It may not be needed in other situations.
    The Jetson controls the steering and throttle.
    Thanks for reading!

  4. For vesc minimum voltage – 8 volts to have an inventory on tension for support of stable operation of vesc (in case of start consuming current maximum and tension on battery will fall) it is necessary to use at least lipo 3S battery (12 volts). at these batteries maximum voltage of 12,6 volts, the minimum 8 volts, i.e. what is necessary for VESC. Then by calculations ( for a speed reduction and support of the minimum level of warranties for VESC from combustion it is necessary to use other motor with the maximum KV 1500 – 2800, it will restrict of course maximum speed, but will allow to use small speed. But even in this case in the BLDC mode the sound of the motor will be loud and high, and will use the FOC mode risky as very small inductivity of a winding of the engine will lead to Mosfet failure. Perhaps I in what that am mistaken in the calculations as MIT RaceCar works, but on MIT RaceCar there is no complete information – what engine is used what gear ratios in transmission what tension of battery for a supply of the motor (or I couldn’t find this information).

  5. Hi Jim, I had an epiphany regarding the IMU. In multirotor, they always concern about the placement of such a sensor. They said it has to be right in the center of gravity (or mass/thrust/whatever). Does this apply to racecar/j case?

    • The main reason that they tend to be concerned about the placement of the IMU on a multi rotor is the proximity to a motor, which can effect the magnetometer readings. If you have multiple motors, then it makes sense to place it in the center of of all the motors. In the case of RACECAR/J, the motor is at the back of the vehicle. Ideally the IMU would also be away from the motor on the LIDAR. Hope this helps.

      • Ok Jim thank you so much for that information.

        Now, I’ve been a while trying to understand racecar/j and other similar project out there. Please correct me if my understanding is way off. So, there are 2 different approaches to build this project, first nvidia’s way (end to end learning) like what Tobias did and second one is MIT’s or UPENN’s way (RACECAR and F1/10). Is that correct Jim?

Leave a Reply

Your email address will not be published.