TurtleBot3

The turtlebot3 is a small mobile robot with a 2-D Lidar Sensor. These instructions describe Northwestern's variant of the software, which has been modified for easy deployment on our networks and to allow low-level access to the motors through ROS 2.

However, most of the content of the reference manual still applies.

1. The Turtlebot can be powered from a battery, or directly from the wall charger, which gets plugged into the OpenCR board
   • IMPORTANT Always make sure the battery is unplugged prior to powering from the wall charger
   • IMPORTANT Never have the battery and wall charger powering the robot simultaneously
2. When the battery voltage drops below a threshold, the turtlebot will issue a low-battery warning sound
   • IMPORTANT When the battery voltage is low, stop using the turtlebot and charge the battery. Otherwise you can permanently damage the battery.
3. Do not use the PincherX 100 power brick with the turtlebot3!
   • It has the same plug but is rated for significantly less power.
4. I like to test most of the software with the turtlebot3 powered from the wall and up on a block so that the wheels don't touch the ground.
   • This method increases development speed because charging the batteries or chasing the turtlebot3 around the room both take time.
   • However, the odometry of the stock turtlebot3 depends solely on the IMU, therefore if it is up on blocks and you turn, the odometry will be incorrect.
     • In my opinion this is an odd choice but I have not done experiments comparing its accuracy with wheel odometry
     • If using the nuturtlebot firmware (e.g., those in ME495 Sensing Navigation and Machine Learning for Robotics) then odometry relies on encoders.
5. sudo access
   • You have sudo access just in case, but nothing you are doing should require it.
   • Please do not use sudo unless explicitly instructed.

1. Connect to the NUMSR wifi network
2. Set your ROS_DOMAIN_ID as assigned so you don't see everybody else's nodes.
3. ssh -oSendEnv=ROS_DOMAIN_ID msr@turtlebot
4. You can use ssh-copy-id msr@turtlebot to load your ssh key so you don't need a password.
5. You should hear the MSR jingle when turning on the turtlebot: if not run opencr_install_firmware

1. To run the MSR-specific code, providing low-level access to the turtlebot, run the following command while ssh'd into the turtlebot: ros2 run numsr_turtlebot numsr_turtlebot
2. The code for this package is at https://github.com/NU-MSR/numsr_turtlebot
3. It relies on messages in https://github.com/NU-MSR/numsr_msgs

1. Technically you could develop all your code on the Raspberry Pi 3, but doing this would be extremely slow and frustrating.
   • It is easy to run out of RAM during compilation, for example.
2. Instead we will adopt a workflow whereby all development (including compilation) is performed on your computer and then transferred to the turtlebot3.
3. Using a compiler on one system to generate code for another system is called cross compilation.
   • In our case we are running on amd64 (sometimes called x64) to =aarch64 (64 bit arm, sometimes referred to as =arm64).
     • These processors have completely different machine language instructions and are incompatible: therefore they require different compilers.
   • Not only must our own code be compiled for aarch64, but also any libraries that our code uses must also be compiled for the target platform.
     • Libraries greatly complicate cross-compilation, as our host systems usually only have libraries for our own architecture and it can be difficult to obtain and link against non-native libraries.
     • Despite some support from Ubuntu, there are inevitable conflicts and problems.

• To run the nodes they must be present on the remote computer
• Use rsync to copy the install space to the turtlebot: rsync -av --delete aarch64_install/ msr@leonardo:/home/msr/install
  • This command makes turtlebot:/home/msr/install contain the same exact files as yourcomputer:/path/to/ros/ws/arm_install
  • BE CAREFUL! The trailing / and (lack thereof) are both crucial.
• Cross-compilation only applies to compiled programs (like C++). Python nodes can be run directly on the raspberry pi, for example (as long as you copy the code).

Because we are only copying the install space to the raspberry pi and because the raspberry pi is so slow, it makes sense, for debugging, to run the debugger on our host computer. To do this, the following commands work (after installing gdb-multiarch on your host machine)

1. Mount the raspberry pi's disk image to /mnt/raspberrypi/
   • sudo losetup -Pf turtle_img
   • This will output the name of a loop device loopX
   • sudo mount /dev/loopXp2 /mnt/raspberrypi
   • The /mnt/raspberrypi directory must exist for this to work. You can use any directory that you want
2. On raspberry pi gdbserver host:2345 <executable>, where <executable> is the name of the file you wish to run
3. On your pc: gdb-multiarch file set debug-file-directory /mnt/raspberrypi/usr/lib/debug set sysroot=/mnt/raspberrypi target extended-remote turtlebotX:2345 To kill the remote server: monitor exit

• Main turtlebot documentation
• rosberrypi
  • Contains the scripts used to create the full turtlebot image and also the cross-compilation docker container
• Code for the numsr node is at https://github.com/NU-MSR/numsr_turtlebot
• Custom numsr ROS messages: https://github.com/NU-MSR/numsr_msgs (TODO, put numsr_turtlebot and numsr_msgs in same git repository).
• Custom numsr firmware: OpenCr