The software install for the Jetson RACECAR is a multi-step process. Looky here:
Background
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:
Installation
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
- Download the Linux kernel source for the Jetson RACECAR.
- Build a custom kernel.
- Load driver for Stereolabs ZED camera.
- Install Robot Operating System (ROS).
- Create a Catkin Workspace. We name this one ‘racecar-ws’
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.
Conclusion
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!
17 Responses
It is very intelligible and clear. If publications are in the same style, then it will be one of the best instructions for projects.
That is very useful information for me. Thanks for reading!
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 😀
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!
Good afternoon. I decided to study information on control of vesc 3351R from Traxxas. also I found here such message. (http://vedder.se/forums/viewtopic.php?f=7&t=598). You are sure that application of vesc is the good idea? This expensive solution with very big risk degree to burn VESC.
You can always just use a stock ESC if you are concerned. At MIT, they’ve been using the VESC for more than a year and have not had any issues. The MIT RACECAR group has posted their VESC settings here: https://github.com/mit-racecar/hardware/tree/master/vesc
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 (http://scriptasylum.com/rc_speed/top_speed.html) 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).
At MIT, they use the TRAXXAS 2923X battery. 3000mAh (NiMH, 7-C flat, 8.4V).
I do not know what the term “tension” means in this context.
The RC car is: https://traxxas.com/products/models/electric/6804Rslash4x4platinum
Specs: https://traxxas.com/products/models/electric/6804Rslash4x4platinum?t=specs
The RC car is not modified, and uses the stock pinion/spur ration of 13/54 and Velineon® 3500 Brushless motor.
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?
I’ll write this up in a separate article.
Thanks Jim. Take your time.
Thank you for your fast response. I am planning on using the Jetson TX2, an Intel RealSense camera, and a Sabertooth Basher RC car to create a mapping of a room/area and navigate autonomously(driving around MIT’s underground tunnels would certainly be nice as well!).
How much of this tutorial should I look into? I am unsure if building the kernel would be required.
Thanks!
Sounds like a fun project! I don’t know enough about how you will interface to the hardware to help. One of the reasons a new kernel module is need is to interface with devices that report as /dev/ttyACM* Both the VESC motor controller and the Sparkfun IMU do this. There’s a lot of software on the MIT style build, you can read through it just so you’re familiar as to what other people are talking about. Thanks for reading, and send some pictures of your project further down the road!
This series is my new “Game of Thrones”, in terms of binge-watching. Is an external SSD totally necessary? Could I get by with, say, a largeish SD card (or even the onboard Jetson flash), or is there some I/O throughput problem that the faster SATA interface solves? Thanks!
Oh my, you’re making me nervous. I might have to add another character to kill of in a later episode. Fortunately Season 2 is about RACECAR/J which is already online. We’re just about to start Season 3 with a new FlatNose variant build of the RACECAR/J.
Typically people use the SSD for two reasons. First, it’s much faster than the internal eMMC or SD card. Second, and more importantly, they use the SSD to gather data so they can train their neural networks. The more data, the better. A good sized SSD helps in that task, especially when you’re capturing video, depth, and lidar streams.
USB is kinda in the middle between the eMMC and SATA, but competes with the depth camera for bandwidth, so it’s not a good solution in that configuration.