Setup to launch ROS nodes on a remote computer on a network

ROS nodes can be setup to run on a remote computer from a local computer on the same network. However, there are some setup to be done. After reading the tutorials and trying out on my own, the following steps summarized what worked for me.

Create known hosts
On the local Linux computer e.g. a Raspberry Pi (local1) do the following:

1. Open a Terminal.
    
2. Type in the command.
   
   $  ssh -oHostKeyAlgorithms='ssh-rsa' remote_user1@remote1
   
   The prompt appears: Are you sure you want to continue connecting (yes/no)?
   
3. Type in yes. Press RETURN.
   
4. When prompted, type in the password for the remote1 computer's remote_user1.
   
   The Terminal is now connected to the computer remote1 and remote_user1 is logged in.
   
   The remote1 computer name is encrypted with the RSA encryption and stored in the Raspberry Pi's /home/local_user1/.ssh/known_hosts file.
   
   
5. Type in exit.
   
   The connection to remote1 is closed.
   
6. If necessary, repeat the previous steps 2 to 4 for the IP address of the computer remote1.
   
   $ ssh -oHostKeyAlgorithms='ssh-rsa' user1@192.168.8.101
   
   Note: where 192.168.8.101 is the IP address for the computer remote1.

Create SSH public and private keys for authentication

1. On the local1 computer, open a Terminal.
   
2. Type in the command:
   
   $ ssh-keygen -t rsa
   
   Enter file in which to save the key (/home/local_user1/.ssh/id_rsa):
   
3. Press RETURN.
   
   Enter passphrase (empty for no passphrase):
   
4. Press RETURN.
   
   Enter same passphrase again:
   
5. Press RETURN.
   
   The private key is generated in /home/local_user1/.ssh/id_rsa.
   The public key is generated in /home/local_user1/.ssh/id_rsa.pub.

Install the public key(s) to the remote computer

1. On the computer local1, open a Terminal.
   
2. Type in the command:
   
   $ ssh-copy-id remote_user1@remote1
   
3. When prompted, type in the password for remote_user1.
   
   The public keys are installed on computer remote1.

Create a remote ROS environment shell script file
The following steps should be executed on the remote computer remote1.

1. Using a text editor, create a shell script file e.g. /opt/ros/melodic/env_remote1.sh with the following content.
   
   

   #!/bin/bash
   
   export ROS_MASTER_URI=http://remote1:11311
   
   source /opt/ros/melodic/setup.bash
   source /home/remote_user1/catkin_ws/devel/setup.bash
   
   exec "$@"
   

   
   
2. Open a Terminal. Make the shell script executable.
   
   $ sudo chmod a+x env_remote1.sh
   

Create and run local launch file
The following should be done on the local computer local1.

1. Using a text editor, create a launch file e.g. run_remote.launch.
   

   <launch>
           <machine
                   name="remote1"
                   address="remote1"
                   env-loader="/opt/ros/melodic/env_remote1.sh"
                   default="true"
                   user="remote_user1"
           />
           <node machine="remote1" pkg="beginner_tutorials" name="hello_doubles" type="hello_doubles" />
   </launch>
   

   
   Note: this launch file will run the hello_doubles node from the beginner_tutorials package on the remote1 computer.
   
   
2. Open a Terminal. Type in the following command assuming the launch file is in the current directory:
   
   $ roslaunch remote.launch
   The following messages may appear. Ws06 in this example screenshot is the remote computer.
   
   

How to run a shell script from a ROS launch file

I wanted to execute a bash shell script from the ROS launch file but the ROS Wiki were not very clear. After some trial and error, I figured out how to do it. The following steps illustrate the procedure I used:

Create a shell script

1. In the ROS workspace package, e.g. /path/to/workspace/package/script/ folder, create a shell script e.g. run_script.sh.
2. Type in the script commands, e.g. see the code listing below.
   
   Note 1: ensure the shebang statement is at the top i.e. #!/bin/bash and a exit status code (0 for success or other values) is returned from the script.
   
   Note 2: Use the chmod command to make the script executable, e.g. $ chmod a+x run_script.sh

#!/bin/bash

# just print this out
echo "Hello ROS world"

# exit gracefully by returning a status 
exit 0

Create a launch file

1. In the ROS workspace package launch folder, create a launch file e.g. /path/to/workspace/package/launch/hello_script.launch.
2. Using a text editor, type in the following:
   
   Note: fill in the package name, e.g. beginner_tutorials, and the type, which should be the shell script name; name is any label you want to associate with the script node.

<launch>
        <node pkg="beginner_tutorials"
                type="run_script.sh" name="run_script"
                output="screen"
        />
</launch>

Run the launch file

1. In a terminal, type in the ros launch command:
   
   $ roslaunch beginner_tutorials hello_script.launch
   
   Note: change beginner_tutorials to your package name and hello_script.launch to the launch file created previously.
   
   The script is executed as shown in the print out of "Hello ROS world" below.
   

Using Saga GIS' Terrain Analysis Swath Profile (interactive) function

Saga GIS has a couple of interactive terrain profiling functions, a single profile and a swath profile. This post shows how to use the interactive swath terrain profile command.

Load a grid file such as a USGS SRTM file

1. Run Saga GIS. Select Geoprocessing | File | Grid | Import | Import USGS SRTM Grid.
   
   The Import USGS SRTM Grid dialog box appears.
   
2. Click the Browse button in the Files field. Choose an SRTM file e.g. N21E093.hgt.
   
   
3. Click Open.
   
   
4. Click Okay.
   
   The SRTM file is loaded and shown in the Data tab.
   

Start the swath profile command

1.  Under the Data tab, mouse right click on the loaded grid file e.g. N21E093.
2. In the pop up context menu, choose Add to Map.
   
   The grid file is displayed in a map window.
   
3. Select Geoprocessing | Terrain Analysis | Profiles | Swath Profle [Interactive].
   
   The Swath Profile dialog box appears.
   
4. In the Grid system field, choose the loaded grid file's system e.g. 0.000833; 1201x 1201y; 93x 21y option.
5. In the DEM field, choose the loaded grid file, e.g. N21E093.
6. Optional. Change the Swath Width if necessary.
   
   The message Interactive tool execution has been started is displayed in the Messages pane.

Digitize the swath profile

1. In the Toolbar, click the Action icon (that looks like a black NW arrow).
2. In the map window, click a few points to draw the swath profile.
   
   
   
3. To complete the drawing, press the mouse right button.
4. To exit the interactive command, select Geoprocessing | Swath Profle [Interactive].
   
   The Tool Execution prompt appears.
   
5. Click Yes.
   
   The message: "Interactive tool execution has been stopped" is shown in the Messages pane.
   
   Note: This may take a while as the command will sample the terrain to calculate the points.

Display the swath profile graphically

1.  In the Data pane, mouse right click on the newly created profile points e.g. Profile [N21E093].
   
   
2. In the pop up menu, choose Attributes | Diagram.
   
   The Properties dialog box appear.
   
3. In the X Axis Values field, choose D (for Distance).
4. In the X Axis Label field, choose D.
5. In the Attributes field, toggle on Z, Z [min], Z[max].
6. Set other options if necessary.
7. Click Okay.
   
   The profile line(s) are displayed.
   

git authentication failed after changing password or installing a new version of git for Windows

After installing a new version of git for Windows or changing the git repository password, the following git error messages may appear when trying to access the git repository: "...access denied...fatal authentication failed for ..."
 
This problem can be resolved by resetting the git password in the Windows Credential Manager.

1. Click the Windows Start button.
   
2. Start typing in "Credential Manager". When the Credential Manager icon is displayed, click the icon.
   
   The Credential Manager dialog box appears.
   
   
3. Click the Windows Credentials icon.
   
4. Scroll down the credential list and look for a git generic credential, e.g. git:https://gitlab.com. Click on the credential.
   
   The git credential properties appear.
   
   
5. Click Remove.
   
   
   
   The git credential is removed.
   
6. Close the Credential Manager.
   
   

Now, running any git command to access the repository will cause Windows to pop up a dialog box to enter the login and pasword, as shown below.

Entering the correct login and password will allow the git command to be executed successfully.

Fix error 400 bad request when trying to use create-react-app

While attempting to create a new ReactJS app with the create-react-app tool, I encountered the following error: "error 400 Bad Request: run-async@^2.2.0". See the screenshot below.

After some research, I found the node npm cache could be corrupted. So running the following command fixed the issue for me.

$ npm cache verify


The create-react-app tool now can complete successfully, as shown below:
$ npx create-react-app myapp

Fix USB serial adapters to static device names on Ubuntu

When a USB to serial device adapter are plugged into a computer's USB port, the Ubuntu Linux OS automatically assigns a default system device name to it. Typically, it is /dev/ttyUSB0, /dev/ttyUSB1, and so on. This is convenient but sometimes it may be necessary to fix a specific device name to a specific USB serial adapter. This can be done by defining a rule file as shown in the steps below.

Identify the USB serial adapter's product and vendor codes

1. Open up a Terminal. Physically plug in the USB serial adapter to the computer's USB port. Type in the following command:
   
   $ dmesg | grep ttyUSB
   The device messages with the string ttyUSB are displayed.
   
   
2. Note which default device name has been assigned. In this case it is /dev/ttyUSB0.
   
   
3. Type in the following command to print out the attributes of the device.
   
   $ udevadm info --name=/dev/ttyUSB0 --attribute-walk
   
   The attributes are printed out.
   
   
4. Scroll and look for the idProduct and idVendor attributes.
   
   
   
5. Note down the codes for the idProduct and idVendor attributes. In this case, the codes are ea60 and 10c4 respectively.

Define a rule to rename the USB serial adapter device

1. In a text editor, create a rule file e.g. 50-usb-serial.rules. Type in the following line:
   
   SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="my_device_name"
   
   Note: replace the idVendor and idProduct and the my_device_name with the appropriate values.
   
   An example file listing:
   
   
2. Place the rule file in /etc/udev/rules.d/. Note: you need to place it as the super user.
   

Activate the rule

1. This can be done by restarting the computer.
   
2. Alternatively, run the following command in a Terminal:
   
   $ sudo udevadm trigger
   
3. To see whether it has been renamed, type in the following command:
   
   $ ls -l /dev/my_device_name
   
   Note: replace my_device_name with the name you defined in the rule file.
   
   The USB serial device has been renamed accordingly as a symbolic link.
   

Android Studio: Automatically replace the Google Maps V2 API Key for debug and release mode

The Android Google Maps API requires a separate debug and release keys in the Android Studio project's AndroidManifest.xml file, as shown in the listing below.

<meta-data
android:name="com.google.android.maps.v2.API_KEY"
android:value="your_google_maps_v2_api_debug_or_release_key_here" />

It can get tedious having to replace the key every time you want to debug or to generate a release build APK.

It is possible to use Gradle to automate the replacement of the Google Maps V2 API key value by using constants defined in the Gradle build types. To automate the replacement, you can do the following:

1. In the Android app's build.gradle file, add in the following line under the debug component of buildTypes:
   
   resValue "string", "google_maps_v2_api_key", "your_google_maps_v2_debug_api_key_here"
   
   Note: replace the api key accordingly; and the constant name is google_maps_v2_api_key.
   
2. Similarly, add in the following line under the release component of buildTypes:
   
   resValue "string", "google_maps_v2_api_key", "your_google_maps_v2_release_api_key_here"
   
3. The Android app's build.gradle should look like this screenshot below:
   
   
   
4. Now, in the app's AndroidManifest.xml file, replace the Google Maps V2 API key metadata value to the string constant name google_maps_v2_api_key.
   
   

   <meta-data
   android:name="com.google.android.maps.v2.API_KEY"
   android:value="@string/google_maps_v2_api_key" />
   

   
   

Now you can debug or build the Android app as per normal without manually replacing the Google Maps V2 API key.