From d94850778b9c48747919c832c4958d105270c4f9 Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 21:09:57 -0600 Subject: [PATCH 1/8] Updating Workspace Setup page based on changes to f1tenth_system. --- getting_started/driving/drive_workspace.rst | 141 ++++++++++---------- 1 file changed, 70 insertions(+), 71 deletions(-) diff --git a/getting_started/driving/drive_workspace.rst b/getting_started/driving/drive_workspace.rst index 9083371..f58a6e7 100644 --- a/getting_started/driving/drive_workspace.rst +++ b/getting_started/driving/drive_workspace.rst @@ -21,81 +21,64 @@ Connect to the **TX2** either via SSH on the **Pit** laptop or a wired connectio On the **TX2**, setup your ROS workspace (for the driver nodes onboard the vehicle) by opening a terminal window and following these steps. -#. Clone the following repository into a folder on your computer. +#. Create a ROS workspace folder, here called ``f1tenth_ws``, and cd into the ``src`` folder of the workspace: .. code-block:: bash - $​ ​cd​ ~/sandbox (or whatever folder you want to work ​in​) - $​ git ​clone​ https://github.com/f1tenth/f1tenth_system + $ mkdir -p f1tenth_ws/src + $ cd f1tenth_ws/src -#. Create a workspace folder if you haven’t already, here called ``f1tenth_ws``, and copy the ``f1tenth_system`` folder into it. +#. Clone the ``f1tenth_system`` repository into the workspace: .. code-block:: bash - $​ mkdir -p f1tenth_ws/src - $​ cp -r f1tenth_system f1tenth_ws/src/ + $ git clone https://github.com/f1tenth/f1tenth_system -#. You might need to install some additional ROS packages. +#. Use ``rosdep`` to install all of the dependencies: - For ROS Kinetic: + .. code-block:: bash - .. code-block:: bash - - $​ sudo apt-get update - $​ sudo apt-get install ros-kinetic-driver-base - - For ROS Melodic: - - .. code-block:: bash - - $​ sudo apt-get update - $​ sudo apt-get install ros-melodic-driver-base + $ sudo apt-get update + $ sudo rosdep init + $ rosdep update + $ rosdep install --from-paths . -i -y #. Make all the Python scripts executable. .. code-block:: bash - $​ ​cd​ f1tenth_ws - $​ find . -name “*.py” -exec chmod +x {} \; + $ find . -name “*.py” -exec chmod +x {} \; -#. Move to your workspace folder and compile the code (catkin_make does more than code compilation - see online reference). +#. Move to your workspace folder and compile the code (``catkin_make`` does more than code compilation - see online reference). .. code-block:: bash - $​ catkin_make + $ cd .. + $ catkin_make #. Finally, source your working directory into your shell using .. code-block:: bash - $​ source devel/setup.bash + $ source devel/setup.bash Congratulations! Your onboard driver workspace is all set up. -.. - Workspace Content Breakdown - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Examine the contents of your workspace and you will see 3 folders. In the ROS world we call these **meta-packages** since they contain package. - - * algorithms - * simulator - * system - - #. Algorithms contains the brains of the car which run high level algorithms, such as wall following, pure pursuit, localization. - #. Simulator contains racecar-simulator which is based off of MIT Racecar’s repository and includes some new worlds such as Levine 2nd floor loop. Simulator also contains f1_10_sim which contains some message types useful for passing drive parameters data from the algorithm nodes to the VESC nodes that drive the car. - #. System contains code from MIT Racecar that the car would not be able to work without. For instance, System contains ackermann_msgs (for Ackermann steering), racecar (which contains parameters for max speed, sensor IP addresses, and teleoperation), serial (for USB serial communication with VESC), and vesc (written by MIT for VESC to work with the racecar). - - We will be focusing on the **System** folder in this section. :ref:`Going Forward ` will utilize the firsit two folders - **Algorithms** and **Simulator**. - .. _udev_rules: 2. Udev Rules Setup ---------------------- -When you connect the VESC and a USB lidar to the Jetson, the operating system will assign them device names of the form ``/dev/ttyACMx``, where ``x`` is a number that depends on the order in which they were plugged in. For example, if you plug in the lidar before you plug in the VESC, the lidar will be assigned the name ``/dev/ttyACM0​``, and the VESC will be assigned ``/dev/ttyACM1​``. This is a problem, as the car’s ROS configuration scripts need to know which device names the lidar and VESC are assigned, and these can vary every time we reboot the Jetson, depending on the order in which the devices are initialized. +When you connect the VESC and a USB lidar to the Jetson, the operating system will assign them device names of the form ``/dev/ttyACMx``, where ``x`` is a number that depends on the order in which they were plugged in. +For example, if you plug in the lidar before you plug in the VESC, the lidar will be assigned the name ``/dev/ttyACM0``, and the VESC will be assigned ``/dev/ttyACM1``. +This is a problem as the car’s ROS configuration scripts need to know which device names the lidar and VESC are assigned, and these can vary every time we reboot the Jetson, depending on the order in which the devices are initialized. -Fortunately, Linux has a utility named ​udev​ that allows us to assign each device a “virtual” name based on its vendor and product IDs. For example, if we plug a USB device in and its vendor ID matches the ID for Hokuyo laser scanners (15d1), ​udev​ could assign the device the name ``/dev/sensors/hokuyo`` instead of the more generic ``/dev/ttyACMx​``. This allows our configuration scripts to refer to things like ``/dev/sensors/hokuyo`` and ``/dev/sensors/vesc​``, which do not depend on the order in which the devices were initialized. We will use udev to assign persistent device names to the lidar, VESC, and joypad by creating three configuration files (“rules”) in the directory ``/etc/udev/rules.d``. +Fortunately, Linux has a utility named ``udev`` that allows us to assign each device a “virtual” name based on its vendor and product IDs. +For example, if we plug a USB device in and its vendor ID matches the ID for Hokuyo laser scanners (``15d1``), ``udev`` could assign the device the name ``/dev/sensors/hokuyo`` instead of the more generic ``/dev/ttyACMx``. +This allows our configuration scripts to refer to things like ``/dev/sensors/hokuyo`` and ``/dev/sensors/vesc``, which do not depend on the order in which the devices were initialized. +We will use udev to assign persistent device names to the lidar, VESC, and joypad by creating three configuration files (“rules”) in the directory ``/etc/udev/rules.d``. -First, as root, open ``/etc/udev/rules.d/99-hokuyo.rules`` in a text editor to create a new rules file for the Hokuyo. Copy the following rule exactly as it appears below and save it: +First, as root, open ``/etc/udev/rules.d/99-hokuyo.rules`` in a text editor to create a new rules file for the Hokuyo. +Copy the following rule exactly as it appears below and save it: .. code-block:: bash @@ -117,58 +100,74 @@ Finally, trigger (activate) the rules by running .. code-block:: bash - $ sudo ​udevadm control --reload-rules - $ sudo udevadm trigger​ + $ sudo udevadm control --reload-rules + $ sudo udevadm trigger Reboot your system, and you should find three new devices by running .. code-block:: bash $ ls /dev/sensors - $ hokuyo​ vesc + $ hokuyo vesc and: .. code-block:: bash $ ls /dev/input - $ joypad-f710​ + $ joypad-f710 If you want to add additional devices and don’t know their vendor or product IDs, you can use the command .. code-block:: bash - $ sudo ​udevadm info --name= --attribute-walk + $ sudo udevadm info --name= --attribute-walk -making sure to replace ```` with the name of your device (e.g. ttyACM0 if that’s what the OS assigned it. The Unix utility ​dmesg​ can help you find that). The topmost entry will be the entry for your device; lower entries are for the device’s parents. +making sure to replace ```` with the name of your device (e.g. ttyACM0 if that’s what the OS assigned it). +The Unix utility ``dmesg`` can help you find that. +The topmost entry will be the entry for your device; lower entries are for the device’s parents. .. _lidar_setup: 3. Testing the Lidar ---------------------- -This section assumes that the lidar has already been plugged in (either to the USB hub or to the Orbitty's ethernet port). If you are using the Hokuyo 10LX or a lidar that is connected via the ethernet port of the Orbitty, make sure that you have completed the :ref:`Hokuyo 10LX Ethernet Connection ` section before preceding. - -Once you’ve set up the lidar, you can test it using ​urg_node​/hokuyo_node (replace the hokuyo_node by the urg_node if you have 10LX with Ethernet connection: https://github.com/ros-drivers/urg_node.git), ​rviz​, and ​rostopic​. - -A. If you're using the 10LX: - - * Start ``roscore​`` in a terminal window. - * In another (new) terminal window, run ``rosrun urg_node urg_node _ip_address:="192.168.0.10"​``. Make sure to supply the urg node with the correct port number for the 10LX. - * This tells ROS to start reading from the lidar and publishing on the ​/scan​ topic. If you get an error saying that there is an “error connecting to Hokuyo,” double check that the Hokuyo is physically plugged into a USB port. You can use the terminal command ``lsusb​to`` check whether Linux successfully detected your lidar. If the node started and is publishing correctly, you should be able to use ``rostopic echo /scan​`` to see live lidar data. - * In the racecar config folder under ``lidar_node`` set the following parameter in sensors.yaml: ``ip_address: 192.168.0.10``. In addition in the ``sensors.launch.xml`` change the argument for the lidar launch from ``hokuyo_node`` to ``urg_node`` do the same thing for the ``node_type`` parameter. - -B. If you're using the 30LX: - - * Run ``roslaunch racecar teleop.launch`` in a sourced terminal window, by default, the launch file brings up the hokuyo node. - -Once your lidar driver node is running, open another terminal and run ``rosrun rviz rviz​`` or simply ``rviz`` to visually see the data. When ``rviz​`` opens, click the “Add” button at the lower left corner. A dialog will pop up; from here, click the *By topic* tab, highlight the *LaserScan* topic, and click *OK*. You might have to switch from viewing in the ``\map`` frame to the ``laser`` frame. If the laser frame is not there, you can type in ``laser`` in the frame text field. - -``rviz`` will now show a collection of points of the lidar data in the gray grid in the center of the screen. You might have to change the size and color of the points in the LaserScan setting to see the points clearer. - - * Try moving a flat object, such as a book, in front of the lidar and to its sides. You should see a corresponding flat line of points on the ​rviz​ grid. - * Try picking the car up and moving it around, and note how the lidar scan data changes, - -You can also see the lidar data in text form by using ​``rostopic echo /scan`` ​. The type of message published to it is sensor_msgs/LaserScan​, which you can also see by running ``rostopic info /scan​`` . There are many fields in this message type, but for our course, the most important one is ​ranges​, which is a list of distances the sensor records in order as it sweeps from its rightmost position to its leftmost position. +This section assumes that the lidar has already been plugged in either to the USB hub or to the Orbitty's ethernet port. +If you are using the Hokuyo 10LX or a lidar that is connected via the ethernet port of the Orbitty, make sure that you have completed the :ref:`Hokuyo 10LX Ethernet Connection ` section before preceding. + +Once you’ve set up the lidar, you can test it using ``urg_node``, ``rviz``, and ``rostopic``: + + * Start ``roscore`` in a terminal window. + * In another terminal window run either: + * For the Hokuyo 10LX: ``rosrun urg_node urg_node _ip_address:=""`` replacing ```` with the IP address of your sensor; or + * For the Hokuyo 30LX: ``rosrun urg_node urg_node _serial_port:="/dev/sensors/lidar"`` + * This tells ROS to start reading from the lidar and publishing on the ``/scan`` topic by default. + * If you get an error saying that there is an “error connecting to Hokuyo,” double check that the Hokuyo is physically plugged into a USB port or the Orbitty's ethernet port. + * If you are using a 30LX, You can use the terminal command ``lsusb`` to check whether Linux successfully detected your lidar. + * If the node started and is publishing correctly, you should be able to use ``rostopic echo /scan`` to see live lidar data. + * In another terminal window run ``rosrun rviz rviz`` or simply ``rviz`` to visually see the data. + * When ``rviz`` opens, click the “Add” button at the lower left corner. + * In the dialog window that pops up, click the *By topic* tab, highlight the *LaserScan* topic, and click *OK*. + * In order to view the lidar data, you may need to switch the Global Frame from ``map`` to ``laser``. This is done in the left pane under Global Options > Fixed Frame. + * If ``laser`` is not in the drop-down menu, you can type ``laser`` in the frame text field. + * ``rviz`` will now show a collection of points of the lidar data in the gray grid in the center of the screen. + * You might have to change the size and color of the points in the LaserScan topic settings to see the points more clearly. + * Try moving a flat object such as a book in front of the lidar and to its sides. You should see a corresponding flat line of points on the ``rviz`` grid. + * Try picking the car up and moving it around, and note how the lidar scan data changes. + * You can also see the lidar data in text form by using ``rostopic echo /scan``. + * The type of message published to that topic is ``sensor_msgs/LaserScan``, which you can also find by running ``rostopic info /scan``. + +4. Configuring the F1TENTH Software for Your Lidar +-------------------------------------------------- + +If you are using a Hokuyo UST-10LX: + + * In the file ``f1tenth_system/f1tenth_racecar/config/sensors.yaml``: + * Replace the line that starts with ``serial_port: `` with the text ``ip_address: ""`` replacing ```` with the IP address of your sensor + +If you are using a Hokuyo UTM-30LX: + + * the F1TENTH software stack should already be configured to use the port ``/dev/sensors/hokuyo`` so no changes are needed if you are using this port. + * if you are using a different port, you will need to change the line that starts with ``serial_port: `` in ``f1tenth_system/f1tenth_racecar/config/sensors.yaml`` to point to the serial port to which your Hokuyo is connected. With all of the parts connected now, we can move on to driving with a joystick! From cc20c2aa3d60f3853bd97c5605aa90ce2ecb5503 Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 21:24:27 -0600 Subject: [PATCH 2/8] Updating and cleaning up Manual Control page based on changes to f1tenth_system. --- getting_started/driving/drive_manual.rst | 46 ++++++++++++++---------- 1 file changed, 27 insertions(+), 19 deletions(-) diff --git a/getting_started/driving/drive_manual.rst b/getting_started/driving/drive_manual.rst index 30ce67a..e9bb5e3 100644 --- a/getting_started/driving/drive_manual.rst +++ b/getting_started/driving/drive_manual.rst @@ -23,37 +23,45 @@ We want to minimize the number of accidents so before we begin, let's first insp #. Plug the USB dongle receiver of the **Logitech Joypad** into the **USB hub**. #. Make sure you have the VESC connected. #. Ensure that both your car and laptop are connected to a wireless access point if you need the car connected to the Internet while you drive it. Otherwise, go back and go through :ref:`System Configuration `. -#. Make sure you’ve cloned the ``f110_system`` repository and set up your working directory as explained in the :ref:`previous section `. -#. This section uses the program ``tmux`` (available via apt-get) to let you run multiple terminals over one SSH connection. You can also use VNC​ if you prefer a GUI. +#. Make sure you’ve cloned the ``f1tenth_system`` repository and set up your working directory as explained in the :ref:`previous section `. +#. This section uses the program ``tmux`` (available via ``apt-get``) to let you run multiple terminals over one SSH connection. You can also use VNC if you prefer a GUI. 2. Driving the Car ---------------------- #. Open a terminal on the **Pit** laptop and SSH into the car from your computer. -#. Once you’re in, open a terminal window and run ​``$tmux`` so that you can spawn new terminal sessions over the same SSH connection. -#. In your tmux session, spawn a new window (using ``Ctrl-B`` and then ``C``) and run ​``$roscore``​ to start ROS. -#. Navigate to other free terminal using ``Ctrl-B`` and then ``P`` or ``N`` by switch to previous or next session, or using ``Ctrl-B`` and then the number of the session, navigate to your workspace that we set up before, run ``$ catkin_make`` and source the directory using ``$ source devel/setup.bash``. -#. Run ``$ roslaunch racecar teleop.launch​`` to launch the car. - * If you see an error like this: ``[ERROR] [1541708274.096842680]: Couldn't open joystick force feedback!`` It means that the joystick is connected. - * If this gives you a segmentation error and it’s caused by compiling the joy package (which you can check by running the joy node on its own), this could be because you are using the joy package from the ROS distribution (i.e., installed with apt-get). Remove that by ``sudo apt-get remove joy`` and ``catkin_make`` in your workspace, and sourcing the setup bash again. This should compile and use the joy package that’s in the repo. - -#. Hold the LB button on the controller to start controlling the car. Use the left joystick to move the car forward and backward and the right joystick for steering. - - * If nothing happens or if the right joystick is not mapped to steering, your might joystick might be in a different mode, press the *mode* button to change the mode. - * If nothing happens, one reason can be that the ``joy_node`` is listening for inputs on the ``js0`` port, but the operating system has assigned a different port to it, like ``js1``. Edit the ``yaml`` file which specifies which port to listen to. You can tell what file that is by reading the launch file (and following the call tree to other launch files). +#. Once you’re logged in, open a terminal window and run ``tmux`` so that you can spawn new terminal sessions over the same SSH connection. +#. In your ``tmux`` session, spawn a new window (using ``Ctrl-B`` and then ``C``) and run ``roscore`` to start ROS. +#. Navigate to other free terminal using ``Ctrl-B`` and then ``P`` or ``N`` to switch to the previous or next session, or using ``Ctrl-B`` and then the number of the session. +#. Navigate to your workspace that we set up before. +#. Run ``catkin_make`` and source the directory using ``source devel/setup.bash``. +#. Run ``roslaunch f1tenth_racecar teleop.launch`` to launch the nodes for tele-operation. + * If you see a warning like this: ``[WARN] [1541708274.096842680]: Couldn't open joystick force feedback!``, it means that the joystick is connected. +#. Hold the LB button on the controller to start controlling the car. Move the left joystick up and down to move the car forward and backward and to the right and left to steer. + * If nothing happens or if the right joystick is not mapped to steering, your joystick might be in a different mode. Press the *mode* button to change the mode. * Note that the LB button acts as a “dead man’s switch,” as releasing it will stop the car. This is for safety in case your car gets out of control. - * You can see a mapping of all controls used by the car in ``f110_system/racecar/racecar/config/racecar-v2/joy_teleop.yaml``. For example, in the default configuration, axis 1 (left joystick’s vertical axis) is used for throttle, and axis 2 (right joystick’s horizontal axis) is used for steering. If you need to check which axis correspond to what buttons/axis on the joystick, run the joy node, when the joystick is connected, you can see the index of the button/axis that's changed. + * You can see a mapping of all controls used by the car in ``f1tenth_system/f1tenth_racecar/config/joy_teleop.yaml``. + For example, in the default configuration, axis 1 (left joystick’s vertical axis) is used for throttle, and axis 2 (left joystick’s horizontal axis) is used for steering. + If you need to check which axis correspond to what buttons/axis on the joystick, run ``rostopic echo /vesc/joy`` and watch which axes change when you move the controls on the joystick. Troubleshooting ------------------ Here are some common errors: -* **VESC out of sync errors**: Check that the VESC is connected. If the error persists, make sure you're using the right VESC driver node. Currently, the ``vesc`` package in the f110_system repo only supports VESC 6+. If you have an older implementation of VESC (for example the FOCBox), use the repo `here `_ instead. +* **VESC out of sync errors**: Check that the VESC is connected. +If the error persists, make sure you're using the right VESC driver node. +Currently, the ``vesc`` package in the ROS repositories only supports VESC 6+. +If you have an older implementation of VESC (for example the FOCBox), clone the repo `here `_ into your workspace and build it again to use this version. * **Serial port busy errors**: Your VESC might have just booted up, give it a few seconds and try again. -* **SerialException errors** ​and you’re using the 30LX Hokuyo​, the errors might be due to a port conflict: e.g., suppose that the lidar was assigned the (virtual serial bi-directional) port ``ttyACM0`` by the operating system. And suppose that the ``vesc_node`` is told the VESC is connected to port ``ttyACM0`` (as per ``vesc.yaml``). Then when the ``vesc_node`` receives joystick commands from ``joy_node`` (via ROS), it pushes them to ``ACM0`` - so these messages actually go to the lidar, and the VESC gets garbage back. So change the ``vesc.yaml`` port entry to ``ttyACM1``. (This whole discussion remains valid if you switch 0 and 1, i.e. if the OS assigned ACM1 to the lidar and your ``vesc.yaml`` lists ACM1). Note that everytime you power down and up, the OS will assign ports from scratch, which might again break your config files. So a better solution is to use udev rules, as explained in `this `_ section​. (See the source code of joy node for the default port for the joystick. You can over-ride that using a parameter in the launch file. See the joy documentation for what parameter that is). -* **urg_node related errors**: Check the ports (e.g. an ip address in sensors.yaml can only be used by 10LX, not 30LX, and vice-versa for the /dev/ttyACM​n​). -* **razor_imu errors**: Delete the IMU entry from the launch file - we’re not using an IMU in this build. +* **SerialException errors** when using the Hokuyo UTM-30LX and not using ``udev`` rules: These errors might be due to a port conflict: e.g., suppose that the lidar was assigned the (virtual serial bi-directional) port ``ttyACM0`` by the operating system and suppose that the ``vesc_node`` is told the VESC is connected to port ``ttyACM0`` (as per ``vesc.yaml``). +When the ``vesc_node`` receives joystick commands from ``joy_node`` via ROS, it pushes them to ``ACM0`` - so these messages actually go to the lidar, and the VESC gets garbage back. +To resolve this, change the ``vesc.yaml`` port entry to ``ttyACM1``. +Note that every time you power-down and -up, the OS will assign ports from scratch, which might again break your config files. +This is why using ``udev`` rules as explained in `this `_ section is recommended. +* **urg_node-related errors**: Check the ports (e.g. an ip address in ``sensors.yaml`` can only be used by 10LX, not 30LX, and vice-versa for the serial port). -Congratulations on building the car, configuring the system, installing the firmware, and driving the car! You've come a long way. Pat yourself on the back and high five your other hand. You can head over to `Learn `_ and try out some of the labs there. +Congratulations on building the car, configuring the system, installing the firmware, and driving the car! +You've come a long way. Pat yourself on the back and high five your other hand. +You can head over to `Learn `_ and try out some of the labs there. .. image:: img/drive02.gif :align: center From 56e82ed38286fbce40535135dac132681c611064 Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 21:31:50 -0600 Subject: [PATCH 3/8] Updating NX page to remove redunant instructions. --- .../software_setup/optional_software_nx.rst | 25 +++++++++---------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/getting_started/software_setup/optional_software_nx.rst b/getting_started/software_setup/optional_software_nx.rst index 2690906..f1af027 100644 --- a/getting_started/software_setup/optional_software_nx.rst +++ b/getting_started/software_setup/optional_software_nx.rst @@ -328,9 +328,12 @@ Creating a Swapfile Installing ROS -------------- -We use ROS to connect everything together and ultimately run the car. We'll need to set up the :ref:`ROS workspace `, set up some :ref:`udev rules `, and :ref:`test the lidar connection `. Everything in this section is done on the **Jetson Xavier NX** so you will need to connect to it via SSH from the **Pit/Host** laptop/computer or plug in a monitor, keyboard, and mouse. +We use ROS to connect everything together and ultimately run the car. +However, before continuing with the F1TENTH software, you'll need to do a few steps that are specific to the Jetson Xavier NX. +Everything in this section is done on the **Jetson Xavier NX** so you will need to connect to it via SSH from the **Pit/Host** laptop/computer or plug in a monitor, keyboard, and mouse. -These instructions are specific to setting up the software on the Jetson Xavier NX as the setup is a bit different than the TX2. Many thanks to `Jim from JetsonHacks `_ and `Josh Whitley from The Autoware Foundation `_ for figuring this out. +These instructions are specific to setting up the software on the Jetson Xavier NX as the setup is a bit different than the TX2. +Many thanks to `Jim from JetsonHacks `_ and `Josh Whitley from The Autoware Foundation `_ for figuring this out. 1. Install the Logitech F710 driver on the Jetson. @@ -348,18 +351,14 @@ These instructions are specific to setting up the software on the Jetson Xavier $ git clone https://github.com/jetsonhacks/installROS $ cd installROS $ ./installROS -p ros-melodic-ros-base - $ ./setupCatkinWorkspace.sh f1tenth_ws - - (This will setup a catkin workspace in the home directory named ``f1tenth_ws``) -3. We are now ready to install the F1/Tenth ROS packages +3. Create a ROS Workspace .. code:: bash - cd ~/f1tenth_ws/src - git clone https://github.com/f1tenth/f1tenth_system - find . -name '*.py' -exec chmod +x {} \; - cd .. - source devel/setup.bash - rosdep install -a -y -i - catkin_make + $ ./setupCatkinWorkspace.sh f1tenth_ws + $ cd ~/f1tenth_ws/src + + (This step will setup a catkin workspace in the home directory named ``f1tenth_ws``) + +After this, you can follow the existing instructions to set up the :ref:`ROS workspace ` (skipping step 1), set up some :ref:`udev rules `, and :ref:`test the lidar connection `. From 5fa4420ccf4b6ba4a023f198c0bbdf272d36b8b4 Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 21:33:53 -0600 Subject: [PATCH 4/8] Updating odom_calib based on changes to f1tenth_system. --- getting_started/odom_calib/index.rst | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/getting_started/odom_calib/index.rst b/getting_started/odom_calib/index.rst index 5c219bf..29fc0fa 100644 --- a/getting_started/odom_calib/index.rst +++ b/getting_started/odom_calib/index.rst @@ -16,9 +16,12 @@ One final step. **Approximate Time Investment:** 1 hour -Now that everything is built, configured, and installed, the odometry of the vehicle needs to be calibrated. The VESC receives input velocities in m/s and steering angles in radians. However the motor and servo requires commands in revolution per minute (RPM) and servo positions. The conversion parameters will need to be tuned to your specific car. +Now that everything is built, configured, and installed, the odometry of the vehicle needs to be calibrated. +The VESC receives input velocities in m/s and steering angles in radians. +However the motor and servo requires commands in revolution per minute (RPM) and servo positions. +The conversion parameters will need to be tuned to your specific car. -#. The parameters in `vesc.yaml `_ need to be calibrated. +#. The parameters in `vesc.yaml `_ need to be calibrated. #. Follow this great `Tuning Guide `_ that `Mushr `_ put together. From a9b540f62f8e558a9a27d24837ee72cf022ef19e Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 21:40:13 -0600 Subject: [PATCH 5/8] Updating drive_rosbag based on changes to f1tenth_system. --- going_forward/drive_rosbag.rst | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/going_forward/drive_rosbag.rst b/going_forward/drive_rosbag.rst index 2c3bcd7..de0c188 100644 --- a/going_forward/drive_rosbag.rst +++ b/going_forward/drive_rosbag.rst @@ -5,24 +5,24 @@ Recording Data on the Car .. note:: This section requires a fully built F1TENTH vehicle. -ROSbags​ are useful for recording data from the car (e.g. LIDAR, odometry) and playing it back later. This feature is useful because it allows you to capture data from when the car is running and later study the data or perform analysis on it to help you develop and implement better racing algorithms. +ROSbags are useful for recording data from the car (e.g. LIDAR, odometry) and playing it back later. This feature is useful because it allows you to capture data from when the car is running and later study the data or perform analysis on it to help you develop and implement better racing algorithms. -One great thing about ROSbags compared to just recording the data into something simpler (like a CSV file) is that data is recorded along with the topics it was originally sent on. What this means is that when you later ​play​ the bag, the data will be transmitted on the same topics that it was originally sent on, ​and *any code that was listening to these topics can run, as if the data was being generated live​*. +One great thing about ROSbags compared to just recording the data into something simpler (like a CSV file) is that data is recorded along with the topics it was originally sent on. What this means is that when you later play the bag, the data will be transmitted on the same topics that it was originally sent on, and *any code that was listening to these topics can run, as if the data was being generated live*. -For example, suppose I record LIDAR data being broadcasted on the ​/scan​ topic. When I later play the data back, the ``rostopic list`` and ``rostopic echo`` commands will show the LIDAR data being transmitted on the ​/scan​ topic as if the car was actually running. +For example, suppose I record LIDAR data being broadcasted on the ``/scan`` topic. When I later play the data back, the ``rostopic list`` and ``rostopic echo`` commands will show the LIDAR data being transmitted on the ``/scan`` topic as if the car was actually running. Here’s a concrete example of how to use ROSbags to acquire motor telemetry data and play it back. -#. Make sure both your computer and car are connected to the ​same network. On your laptop, open a terminal and SSH into the car. Once you’re in, run ​tmux​ so that you can spawn new terminal sessions over the same SSH connection. -#. In your tmux session, spawn a new window and run ``roscore​`` to start ROS. -#. In the other free terminal, navigate to your working directory, run ​catkin make​, and source the directory using ​source devel/setup.bash​. -#. Run ``roslaunch racecar teleop.launch​`` to launch the car. Place the car on the ground or on a stand and press the center button on your joystick so you can control the car. -#. In your tmux session, spawn a new window and examine the list of active ROS topics using ​rostopic list​. Make sure that you can see the ``/vesc/sensors/core​`` topic , which contains drive motor parameters. -#. Here’s where ROSbags come into play. Run ``rosbag record /vesc/sensors/core​`` to start recording the data. The data will start recording to a file in the current directory with naming format ``YYYY-MM-DD-HH-MM-SS.bag​`` . Recording will continue until you press Control-C to kill the rosbag process. +#. Make sure both your computer and car are connected to the same network. On your laptop, open a terminal and SSH into the car. Once you’re in, run ``tmux`` so that you can spawn new terminal sessions over the same SSH connection. +#. In your tmux session, spawn a new window and run ``roscore`` to start ROS. +#. In the other free terminal, navigate to your working directory, run ``catkin make``, and source the directory using ``source devel/setup.bash``. +#. Run ``roslaunch f1tenth_racecar teleop.launch`` to launch the car. Place the car on the ground or on a stand and press the center button on your joystick so you can control the car. +#. In your tmux session, spawn a new window and examine the list of active ROS topics using ``rostopic list``. Make sure that you can see the ``/vesc/sensors/core`` topic , which contains drive motor parameters. +#. Here’s where ROSbags come into play. Run ``rosbag record /vesc/sensors/core`` to start recording the data. The data will start recording to a file in the current directory with naming format ``YYYY-MM-DD-HH-MM-SS.bag``. Recording will continue until you press Control-C to kill the rosbag process. * If you get an error about low disk space, you can specify the directory to record to (e.g. on a USB flash drive or hard drive) after the topic name). For example, ``rosbag record /vesc/sensors/core -o /path/to/external/drive`` to record into an external hard drive. - * Note that ​rosbag​ also supports recording multiple topics at the same time. For example, I could record both laser scan and motor data using rosbag record ``/vesc/sensors/core /scan`` + * Note that ``rosbag`` also supports recording multiple topics at the same time. For example, I could record both laser scan and motor data using rosbag record ``/vesc/sensors/core /scan`` #. Let the recording run for about 30 seconds. Drive the car around during this time using the controller and then hit ``Ctrl-C`` to stop recording. -#. Play the rosbag file using ``rosbag play ​``. While the bag is playing, examine the topics list, and you will see a list of all topics that were recorded into the bag. Note that in addition to the topics you specified, ROS will also record the ``rosout​``, ``rosout_agg``, and ``clock`` topics, which can be useful for debugging. -#. View that recorded motor data by echoing the ``/vesc/sensors/core​`` topic. Pay attention to how the motor RPM changed as you drove the car around. When the bag is out of data, it will stop publishing. +#. Play the rosbag file using ``rosbag play ``. While the bag is playing, examine the topics list, and you will see a list of all topics that were recorded into the bag. Note that in addition to the topics you specified, ROS will also record the ``rosout``, ``rosout_agg``, and ``clock`` topics, which can be useful for debugging. +#. View that recorded motor data by echoing the ``/vesc/sensors/core`` topic. Pay attention to how the motor RPM changed as you drove the car around. When the bag is out of data, it will stop publishing. From 142247d7e0d5459682b1968e9fb5f97e35ddcf08 Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 21:42:07 -0600 Subject: [PATCH 6/8] Updating algorithms/waypoints.rst based on changes to f1tenth_system. --- going_forward/algorithms/waypoints.rst | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/going_forward/algorithms/waypoints.rst b/going_forward/algorithms/waypoints.rst index 6d1c090..e420a90 100644 --- a/going_forward/algorithms/waypoints.rst +++ b/going_forward/algorithms/waypoints.rst @@ -13,19 +13,19 @@ Do the following to save waypoints. .. code-block:: bash - # ​ Allow the car to be controlled with joystick - $​ roslaunch racecar teleop.launch + # Allow the car to be controlled with joystick + $ roslaunch f1tenth_racecar teleop.launch - #​ Record a rosbag with just the scan and vesc/odom topics. Will be saved + # Record a rosbag with just the scan and vesc/odom topics. Will be saved into your Home directory. (In a new terminal window) - $​ rosbag record scan vesc/odom + $ rosbag record scan vesc/odom # You will need to modify particle_filter.launch with path to rosbag you just recorded $ roslaunch localization particle_filter.launch # Records waypoints and saves as waypoints.csv in current working directory - $​ rosrun waypoint_logger waypoint_logger.py + $ rosrun waypoint_logger waypoint_logger.py At this point, in your current working directory you will see a csv file called ``waypoints.csv``. Let’s go into further detail on what is going behind the scenes. ``Particle_filter.launch`` plays the rosbag that you recorded (of course, you have to update the particle_filter.launch with the path to your bag file you recorded). The particle filter subscribes to the ``vesc/odom`` and scan topics, and it outputs a stream of messages over the topic ``pf/viz/inferred_pose``. ``Waypoint_logger.py`` subscribes to ``pf/viz/inferred_pose`` and saves the x, y coordinates in each callback to a CSV file. @@ -45,7 +45,7 @@ To run in the simulator (recommended to do this first): .. code-block:: bash - $​ roslaunch pure_pursuit pure_pursuit_sim.launch + $ roslaunch pure_pursuit pure_pursuit_sim.launch Note that the Gazebo simulator works well with pure pursuit algorithm only at slower speeds, around 1 m/s on turns and less than 4 m/s on straightaways. The reason is that on turns with higher speeds than 1 m/s, Gazebo models the car as sliding out more with a much larger turn radius. We’ve tried a dozen ways to try to fix this overestimation of turning drift, but with no success. Hence we use Gazebo mainly to test that algorithms work at slower speeds, then take the car into real world to slowly ramp up the speed. @@ -55,7 +55,7 @@ To run in the real world: .. code-block:: bash - $​ roslaunch pure_pursuit pure_pursuit.launch + $ roslaunch pure_pursuit pure_pursuit.launch All of the core logic for ``pure_pursuit`` is contained in the ``pure_pursuit.py`` file which can be found under ``algorithms/pure_pursuit/scripts``. From a high level, the pseudocode for pure pursuit is like `this `_. @@ -86,7 +86,7 @@ To run the pure pursuit with speed control: .. code-block:: bash - $​ roslaunch pure_pursuit pure_pursuit_with_speed_control.launch + $ roslaunch pure_pursuit pure_pursuit_with_speed_control.launch The car examines the points ahead of it within the search window defined by the constants ``WP_TURN_WINDOW_MIN`` and ``WP_TURN_WINDOW_MAX`` and takes the average x-coordinate of those points. (You can think of ``WP_TURN_WINDOW_MIN`` as being the radius of the inner circle of the region to check and ``WP_TURN_WINDOW_MAX`` as being the radius of the outer circle. See the diagram below.) The amount that the car slows down depends on how steep the turn is: if the turn is steeper (that is, the average x-coordinate is far from the car’s centerline), the car will slow down more; if the turn is shallow, it will slow down less. For smooth speed adjustment, the speed is interpolated between the maximum straightaway speed (``VELOCITY_STRAIGHT``) and the minimum turn speed (``VELOCITY_TURN``). @@ -118,19 +118,19 @@ At this point we have been able to run pure pursuit relatively fast (up to 6 m/s Path Planning with ROS move_base ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -We use ROS ​``move_base`` to incorporate a global planner and a local planner. Almost everything in this section is taken from the official ROS tutorial on setting up move_base. It’s a very important document. We’ve literally read it at least 10 times. +We use ROS ``move_base`` to incorporate a global planner and a local planner. Almost everything in this section is taken from the official ROS tutorial on setting up move_base. It’s a very important document. We’ve literally read it at least 10 times. Install move_base by running: .. code-block:: bash - $​ sudo apt-get install ros-kinetic-move-base + $ sudo apt-get install ros-kinetic-move-base To see ``move_base`` running in the simulator, type this in your terminal: .. code-block:: bash - $​ roslaunch path_planning move_base_sim.launch + $ roslaunch path_planning move_base_sim.launch When you launch this file, you will see both Gazebo and Rviz open up. You may also see a list of yellow warning messages that an “Invalid argument passed to canTransform argument source_frame in tf2 frame_ids cannot be empty”. We haven’t yet figured out how to fix this, but the car seems to run fine in the simulator even with the warning message. @@ -145,7 +145,7 @@ To see move_base running in the real world, run the following: .. code-block:: bash - $​ roslaunch path_planning pure_pursuit_local_plan.launch + $ roslaunch path_planning pure_pursuit_local_plan.launch You should see Rviz open with a map of Levine Hall 2nd floor. Note that this launch file is meant for running the car live, as in in the real world. If you are running this on your car, in order to get the car to move, we have added a dead man’s switch onto the joystick. The car doesn’t move unless we hold down the “RB” button on the top right of the joystick. The strategy for the car to follow the local plan here is different from the strategy used in the simulator above. Earlier in the simulator we subscribed to the ``/cmd_vel`` topic which literally gave us the velocity and steering angle to follow. Here our strategy is to take the global plan which is a list of Pose data type, and use our pure pursuit code from an earlier section. The biggest challenge with pure pursuit for us is that with too great of a lookahead distance (in this case greater than 1 meter), the car will run into corners on turns because it sees waypoints too far in front. This is a problem because if we turn the lookahead distance to something smaller, then the car oscillates a lot going down straightaways. Hence this code isn’t ideal for any type of racing, but is merely to demonstrate the differences in the two strategies for following the generated paths. The first strategy is blindly following the ``/cmd_vel`` output by move_base. The second strategy is to take the list of waypoints (poses) and use pure pursuit to follow them. @@ -183,7 +183,7 @@ Install TEB: .. code-block:: bash - $​ sudo apt-get install ros-kinetic-teb-local-planner + $ sudo apt-get install ros-kinetic-teb-local-planner TEB is a very thorough, well documented library with LOTS of parameters. Like over 40 parameters. We configured parameters in ``algorithms/path_planning/params/teb_local_planner_params.yaml``. There are params for ``min_turning_radius``, wheelbase of the car, ``max_vel_x``, and much more. In our ``follow_teb_local_plan.launch`` file, under the ``move_base`` node we add a rosparam that loads the ``teb_local_planner_params.yaml`` and have removed the default local planner params file. The underlying python file, ``follow_teb_local_plan.py``, is very similar to the ``follow_move_base_cmd_vel.py`` used for the default local planner. The main difference is that because Teb literally outputs the velocity and steering angle as is, we don’t need to do conversion. From 76b5bfa088d035ea07ab50a0ec1e28be66e52775 Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 21:49:13 -0600 Subject: [PATCH 7/8] Adding missing catkin_init_workspace command to ROS workspace instructions. Fixing indentation. --- getting_started/driving/drive_workspace.rst | 77 +++++++++++---------- 1 file changed, 39 insertions(+), 38 deletions(-) diff --git a/getting_started/driving/drive_workspace.rst b/getting_started/driving/drive_workspace.rst index f58a6e7..ac0b8cb 100644 --- a/getting_started/driving/drive_workspace.rst +++ b/getting_started/driving/drive_workspace.rst @@ -3,9 +3,9 @@ Workspace Setup ===================== **Equipment Required:** - * Fully built F1TENTH vehicle - * Pit/Host computer OR - * External monitor/display, HDMI cable, keyboard, mouse + * Fully built F1TENTH vehicle + * Pit/Host computer OR + * External monitor/display, HDMI cable, keyboard, mouse **Approximate Time Investment:** 1.5 hour @@ -21,46 +21,47 @@ Connect to the **TX2** either via SSH on the **Pit** laptop or a wired connectio On the **TX2**, setup your ROS workspace (for the driver nodes onboard the vehicle) by opening a terminal window and following these steps. -#. Create a ROS workspace folder, here called ``f1tenth_ws``, and cd into the ``src`` folder of the workspace: +#. Create a ROS workspace folder, here called ``f1tenth_ws``, and cd into the ``src`` folder of the workspace to initialize it: - .. code-block:: bash + .. code-block:: bash - $ mkdir -p f1tenth_ws/src - $ cd f1tenth_ws/src + $ mkdir -p f1tenth_ws/src + $ cd f1tenth_ws/src + $ catkin_init_workspace #. Clone the ``f1tenth_system`` repository into the workspace: - .. code-block:: bash + .. code-block:: bash - $ git clone https://github.com/f1tenth/f1tenth_system + $ git clone https://github.com/f1tenth/f1tenth_system #. Use ``rosdep`` to install all of the dependencies: .. code-block:: bash - $ sudo apt-get update - $ sudo rosdep init - $ rosdep update - $ rosdep install --from-paths . -i -y + $ sudo apt-get update + $ sudo rosdep init + $ rosdep update + $ rosdep install --from-paths . -i -y #. Make all the Python scripts executable. - .. code-block:: bash + .. code-block:: bash - $ find . -name “*.py” -exec chmod +x {} \; + $ find . -name “*.py” -exec chmod +x {} \; #. Move to your workspace folder and compile the code (``catkin_make`` does more than code compilation - see online reference). - .. code-block:: bash + .. code-block:: bash - $ cd .. - $ catkin_make + $ cd .. + $ catkin_make #. Finally, source your working directory into your shell using - .. code-block:: bash + .. code-block:: bash - $ source devel/setup.bash + $ source devel/setup.bash Congratulations! Your onboard driver workspace is all set up. @@ -82,46 +83,46 @@ Copy the following rule exactly as it appears below and save it: .. code-block:: bash - KERNEL=="ttyACM[0-9]*", ACTION=="add", ATTRS{idVendor}=="15d1", MODE="0666", GROUP="dialout", SYMLINK+="sensors/hokuyo" + KERNEL=="ttyACM[0-9]*", ACTION=="add", ATTRS{idVendor}=="15d1", MODE="0666", GROUP="dialout", SYMLINK+="sensors/hokuyo" Next, open ``/etc/udev/rules.d/99-vesc.rules`` and copy in the following rule for the VESC: .. code-block:: bash - - KERNEL=="ttyACM[0-9]*", ACTION=="add", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", MODE="0666", GROUP="dialout", SYMLINK+="sensors/vesc" + + KERNEL=="ttyACM[0-9]*", ACTION=="add", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", MODE="0666", GROUP="dialout", SYMLINK+="sensors/vesc" Then open ``/etc/udev/rules.d/99-joypad-f710.rules`` and add this rule for the joypad: .. code-block:: bash - KERNEL=="js[0-9]*", ACTION=="add", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c219", SYMLINK+="input/joypad-f710" + KERNEL=="js[0-9]*", ACTION=="add", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c219", SYMLINK+="input/joypad-f710" Finally, trigger (activate) the rules by running .. code-block:: bash - $ sudo udevadm control --reload-rules - $ sudo udevadm trigger + $ sudo udevadm control --reload-rules + $ sudo udevadm trigger Reboot your system, and you should find three new devices by running .. code-block:: bash - $ ls /dev/sensors - $ hokuyo vesc + $ ls /dev/sensors + $ hokuyo vesc and: .. code-block:: bash - $ ls /dev/input - $ joypad-f710 + $ ls /dev/input + $ joypad-f710 If you want to add additional devices and don’t know their vendor or product IDs, you can use the command .. code-block:: bash - $ sudo udevadm info --name= --attribute-walk + $ sudo udevadm info --name= --attribute-walk making sure to replace ```` with the name of your device (e.g. ttyACM0 if that’s what the OS assigned it). The Unix utility ``dmesg`` can help you find that. @@ -136,11 +137,11 @@ If you are using the Hokuyo 10LX or a lidar that is connected via the ethernet p Once you’ve set up the lidar, you can test it using ``urg_node``, ``rviz``, and ``rostopic``: - * Start ``roscore`` in a terminal window. - * In another terminal window run either: + * Start ``roscore`` in a terminal window. + * In another terminal window run either: * For the Hokuyo 10LX: ``rosrun urg_node urg_node _ip_address:=""`` replacing ```` with the IP address of your sensor; or * For the Hokuyo 30LX: ``rosrun urg_node urg_node _serial_port:="/dev/sensors/lidar"`` - * This tells ROS to start reading from the lidar and publishing on the ``/scan`` topic by default. + * This tells ROS to start reading from the lidar and publishing on the ``/scan`` topic by default. * If you get an error saying that there is an “error connecting to Hokuyo,” double check that the Hokuyo is physically plugged into a USB port or the Orbitty's ethernet port. * If you are using a 30LX, You can use the terminal command ``lsusb`` to check whether Linux successfully detected your lidar. * If the node started and is publishing correctly, you should be able to use ``rostopic echo /scan`` to see live lidar data. @@ -151,8 +152,8 @@ Once you’ve set up the lidar, you can test it using ``urg_node``, ``rviz``, an * If ``laser`` is not in the drop-down menu, you can type ``laser`` in the frame text field. * ``rviz`` will now show a collection of points of the lidar data in the gray grid in the center of the screen. * You might have to change the size and color of the points in the LaserScan topic settings to see the points more clearly. - * Try moving a flat object such as a book in front of the lidar and to its sides. You should see a corresponding flat line of points on the ``rviz`` grid. - * Try picking the car up and moving it around, and note how the lidar scan data changes. + * Try moving a flat object such as a book in front of the lidar and to its sides. You should see a corresponding flat line of points on the ``rviz`` grid. + * Try picking the car up and moving it around, and note how the lidar scan data changes. * You can also see the lidar data in text form by using ``rostopic echo /scan``. * The type of message published to that topic is ``sensor_msgs/LaserScan``, which you can also find by running ``rostopic info /scan``. @@ -172,5 +173,5 @@ If you are using a Hokuyo UTM-30LX: With all of the parts connected now, we can move on to driving with a joystick! .. image:: img/drive01.gif - :align: center - :width: 200pt + :align: center + :width: 200pt From afa3d32d98f45b5f39a5794bebcd331330f7f8f7 Mon Sep 17 00:00:00 2001 From: Joshua Whitley Date: Wed, 30 Dec 2020 22:03:53 -0600 Subject: [PATCH 8/8] Fixing some additional doc generation warnings. --- getting_started/driving/drive_manual.rst | 14 +++++------ getting_started/driving/drive_workspace.rst | 28 ++++++++++----------- getting_started/firmware/firmware_vesc.rst | 6 ++--- 3 files changed, 24 insertions(+), 24 deletions(-) diff --git a/getting_started/driving/drive_manual.rst b/getting_started/driving/drive_manual.rst index e9bb5e3..53b6f13 100644 --- a/getting_started/driving/drive_manual.rst +++ b/getting_started/driving/drive_manual.rst @@ -48,15 +48,15 @@ Troubleshooting Here are some common errors: * **VESC out of sync errors**: Check that the VESC is connected. -If the error persists, make sure you're using the right VESC driver node. -Currently, the ``vesc`` package in the ROS repositories only supports VESC 6+. -If you have an older implementation of VESC (for example the FOCBox), clone the repo `here `_ into your workspace and build it again to use this version. + If the error persists, make sure you're using the right VESC driver node. + Currently, the ``vesc`` package in the ROS repositories only supports VESC 6+. + If you have an older implementation of VESC (for example the FOCBox), clone the repo `here `_ into your workspace and build it again to use this version. * **Serial port busy errors**: Your VESC might have just booted up, give it a few seconds and try again. * **SerialException errors** when using the Hokuyo UTM-30LX and not using ``udev`` rules: These errors might be due to a port conflict: e.g., suppose that the lidar was assigned the (virtual serial bi-directional) port ``ttyACM0`` by the operating system and suppose that the ``vesc_node`` is told the VESC is connected to port ``ttyACM0`` (as per ``vesc.yaml``). -When the ``vesc_node`` receives joystick commands from ``joy_node`` via ROS, it pushes them to ``ACM0`` - so these messages actually go to the lidar, and the VESC gets garbage back. -To resolve this, change the ``vesc.yaml`` port entry to ``ttyACM1``. -Note that every time you power-down and -up, the OS will assign ports from scratch, which might again break your config files. -This is why using ``udev`` rules as explained in `this `_ section is recommended. + When the ``vesc_node`` receives joystick commands from ``joy_node`` via ROS, it pushes them to ``ACM0`` - so these messages actually go to the lidar, and the VESC gets garbage back. + To resolve this, change the ``vesc.yaml`` port entry to ``ttyACM1``. + Note that every time you power-down and -up, the OS will assign ports from scratch, which might again break your config files. + This is why using ``udev`` rules as explained in `this `_ section is recommended. * **urg_node-related errors**: Check the ports (e.g. an ip address in ``sensors.yaml`` can only be used by 10LX, not 30LX, and vice-versa for the serial port). Congratulations on building the car, configuring the system, installing the firmware, and driving the car! diff --git a/getting_started/driving/drive_workspace.rst b/getting_started/driving/drive_workspace.rst index ac0b8cb..76c7c50 100644 --- a/getting_started/driving/drive_workspace.rst +++ b/getting_started/driving/drive_workspace.rst @@ -139,23 +139,23 @@ Once you’ve set up the lidar, you can test it using ``urg_node``, ``rviz``, an * Start ``roscore`` in a terminal window. * In another terminal window run either: - * For the Hokuyo 10LX: ``rosrun urg_node urg_node _ip_address:=""`` replacing ```` with the IP address of your sensor; or - * For the Hokuyo 30LX: ``rosrun urg_node urg_node _serial_port:="/dev/sensors/lidar"`` + * For the Hokuyo 10LX: ``rosrun urg_node urg_node _ip_address:=""`` replacing ```` with the IP address of your sensor; or + * For the Hokuyo 30LX: ``rosrun urg_node urg_node _serial_port:="/dev/sensors/lidar"`` * This tells ROS to start reading from the lidar and publishing on the ``/scan`` topic by default. - * If you get an error saying that there is an “error connecting to Hokuyo,” double check that the Hokuyo is physically plugged into a USB port or the Orbitty's ethernet port. - * If you are using a 30LX, You can use the terminal command ``lsusb`` to check whether Linux successfully detected your lidar. - * If the node started and is publishing correctly, you should be able to use ``rostopic echo /scan`` to see live lidar data. - * In another terminal window run ``rosrun rviz rviz`` or simply ``rviz`` to visually see the data. - * When ``rviz`` opens, click the “Add” button at the lower left corner. - * In the dialog window that pops up, click the *By topic* tab, highlight the *LaserScan* topic, and click *OK*. - * In order to view the lidar data, you may need to switch the Global Frame from ``map`` to ``laser``. This is done in the left pane under Global Options > Fixed Frame. - * If ``laser`` is not in the drop-down menu, you can type ``laser`` in the frame text field. - * ``rviz`` will now show a collection of points of the lidar data in the gray grid in the center of the screen. - * You might have to change the size and color of the points in the LaserScan topic settings to see the points more clearly. + * If you get an error saying that there is an “error connecting to Hokuyo,” double check that the Hokuyo is physically plugged into a USB port or the Orbitty's ethernet port. + * If you are using a 30LX, You can use the terminal command ``lsusb`` to check whether Linux successfully detected your lidar. + * If the node started and is publishing correctly, you should be able to use ``rostopic echo /scan`` to see live lidar data. + * In another terminal window run ``rosrun rviz rviz`` or simply ``rviz`` to visually see the data. + * When ``rviz`` opens, click the “Add” button at the lower left corner. + * In the dialog window that pops up, click the *By topic* tab, highlight the *LaserScan* topic, and click *OK*. + * In order to view the lidar data, you may need to switch the Global Frame from ``map`` to ``laser``. This is done in the left pane under Global Options > Fixed Frame. + * If ``laser`` is not in the drop-down menu, you can type ``laser`` in the frame text field. + * ``rviz`` will now show a collection of points of the lidar data in the gray grid in the center of the screen. + * You might have to change the size and color of the points in the LaserScan topic settings to see the points more clearly. * Try moving a flat object such as a book in front of the lidar and to its sides. You should see a corresponding flat line of points on the ``rviz`` grid. * Try picking the car up and moving it around, and note how the lidar scan data changes. - * You can also see the lidar data in text form by using ``rostopic echo /scan``. - * The type of message published to that topic is ``sensor_msgs/LaserScan``, which you can also find by running ``rostopic info /scan``. + * You can also see the lidar data in text form by using ``rostopic echo /scan``. + * The type of message published to that topic is ``sensor_msgs/LaserScan``, which you can also find by running ``rostopic info /scan``. 4. Configuring the F1TENTH Software for Your Lidar -------------------------------------------------- diff --git a/getting_started/firmware/firmware_vesc.rst b/getting_started/firmware/firmware_vesc.rst index b4efd91..854fe28 100644 --- a/getting_started/firmware/firmware_vesc.rst +++ b/getting_started/firmware/firmware_vesc.rst @@ -18,14 +18,14 @@ .. note:: - If using the VESC mkIV, see `here `_. + If using the VESC mkIV, see https://github.com/RacecarJ/vesc-firmware. 1. Installing the VESC Tool ----------------------------- -We need to configure the VESC so that it works with the ROS driver package. Before you start, you'll need to install the `VESC Tool v2.03 `_. The latest version, v2.05 does not contain the firmware that we use. The Linux VESC tool v2.03 can be found `here `_. +We need to configure the VESC so that it works with the ROS driver package. Before you start, you'll need to install the `VESC Tool v2.03 `_. The latest version, v2.05 does not contain the firmware that we use. To download the version that we use, get the `Linux VESC tool v2.03 `_. .. - `VESC Tool `_ on a laptop or a PC. A pre-built VESC Tool for MacOS can be found `here `_ . + `VESC Tool `_ on a laptop or a PC. A `pre-built VESC Tool for MacOS `_ is also available. 2. Powering the VESC -------------------------