Odroid C1

work in progress

Technical data

Technical data of the Odroid C1 can be found here

Overview

Odroid C1 front

Pin Out 40 pin connector

odroid_c1_pinout.jpg

Flashing the eMMC card with Ubuntu

Download the image for the Odroid C1:

We recommend the 14.04 LTS minimal version as it is very small and stripped down to bare essentials.

To flash the image, please follow the instruction on this page:

Connecting to Odroid C1 with UART cable

If no network connection has been established yet, the Odroid C1 can be accessed via a UART connection. The connection consists of a serial UART cable, a serial-to-USB adapter and a micro USB plug cable as shown here. To establish connection, the program screen can be used in the following way from the shell:

screen /dev/ttyUSB0 115200 8N1

The above command assumes that the UART connection is assigned the device name ttyUSB0 in your computer. Please adapt the name correspondingly if the name was assigned to be else.

To check whether device ttyUSB0 exists, type the following in your shell:

ls /dev/ttyUSB0

Connecting to Odroid C1 with Ethernet cable

Depending of the Ubuntu version that has been installed, Ubuntu starts and runs automatically the service network-manager. To check whether the service runs:

sudo service network-manager status

The following explanations regarding the Ethernet connection or the WIFI connection only work if the service network-manager is not running. To remove the network-manager:

Please be aware that the removal of the network manager can only be reverted if the connection to the Internet is available again.

sudo apt-get purge network-manager

If you want to use an Ethernet connection to connect to the Odroid C1, append the following to the the configuration file /etc/network/interfaces:

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

The auto key word enables that the connection is attempted to be established during boot. eth0 corresponds to the connection interface. iface is the command. inet is the protocoll, i.e. IPv4 and dhcp is the method, i.e. dynamic configuration.

Establishing wifi connection with antenna

This section explains how to set up the wlan connection. The first part explains how to manually connect to a wifi network secured with WPA2 and in the second part it is shown how to set up Odroid C1 such that it connects at boot and can roam in different wifi networks. The wifi module 3 is used. Technical details can be found here. The wifi module is connected via a USB slot.

Manually connect to WPA2 secured wifi network

In a first step the properties of the wlan connection must be checked. To find out the internal name of the wlan card type:

$ iwconfig

If the board Odroid C1 detects the card but is not connected to a wifi network yet, the output would be something like:

wlan0     unassociated  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency=2.437 GHz  Access Point: Not-Associated   
          Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=0/100  Signal level=0 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
          ...

In this case the wlan card has the assgined name wlan0. To check whether the wireless device is up:

$ ip link show wlan0

If it was down, the output would be:

5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 7c:dd:90:73:6c:4d brd ff:ff:ff:ff:ff:ff

To bring the wlan card up:

$ sudo ip link set wlan0 up

Now checking again the status of wlan0, the output is:

5: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 7c:dd:90:73:6c:4d brd ff:ff:ff:ff:ff:ff

Since there is the keyword UP visible, the wlan card should be up. Assuming you want to connect to the WPA2 wifi network with the SSID my_wifi and with the pre-shared key (PSK) easy_password, do the following:

$ sudo -s
[sudo] password for <user>:
$ wpa_passphrase my_wifi >> /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf 
type the password and hit enter
$ exit

With the above commands a file named wpa_supplicant_my_wifi.conf is created where the SSID of the network and the corresponding pre-shared key in hexadecimal format are saved. The content of the file looks like :

$ cat /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf
network={
        ssid="my_wifi"
        #psk="easy_password"
        psk=79be906c320eef65c104e14fc264d5ca2812660aeffc519490407e01776f67e1
}

To connect to the network my_wifi, run the wpa_supplicant with the configuration file:

$ sudo wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf
Successfully initialized wpa_supplicant
ioctl[SIOCSIWAP]: Operation not permitted
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument

To check whether the wlan card has successfully connected to the network:

$ iwconfig
wlan0     IEEE 802.11bgn  ESSID:"my_wifi"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.437 GHz  Access Point: D8:50:E6:AA:2B:58   
          Bit Rate:72.2 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=100/100  Signal level=-45 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
          ...

Finally the device needs an assigned IP address in the network. To fetch an address:

sudo dhclient wlan0

To check whether the device has received a valid IP address in the network:

$ ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 7c:dd:90:73:6c:4d  
          inet addr:192.168.5.173  Bcast:192.168.5.255  Mask:255.255.255.0
          inet6 addr: fe80::7edd:90ff:fe73:6c4d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:980 errors:0 dropped:92 overruns:0 frame:0
          TX packets:210 errors:0 dropped:2 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:252339 (252.3 KB)  TX bytes:118406 (118.4 KB)

The IP address after inet addr is the IP address of the device in the wifi network if a connection was successfully established.

Connect wifi at boot and roaming in multiple networks

Assuming you have manually connected to a WPA2-secured wifi network as described in the preceding section, it is possible to enable the Odroid C1 to automatically connect to this network at boot. In a first step open the configuration file that has been created as explained in the preceding section with your favourite editor and add the entry id_str=“bootwifi” below the psk entry. E.g. with nano:

$ sudo nano /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf

After this the file would look like:

$ cat /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf
network={
        ssid="my_wifi"
        #psk="easy_password"
        psk=79be906c320eef65c104e14fc264d5ca2812660aeffc519490407e01776f67e1
        id_str="bootwifi"

}

The “id_str=” network identifier string parameter is given to wpa_action when a network has been selected.

In a second step go to your network interface directory and create the file wlan0 if it does not exist already:

$ cd /etc/network/interfaces.d/
$ sudo touch wlan0

Adapt the name of the file here wlan0 subject to the assigned name of the present wlan card by the Odroid C1. To find out which name was assigned to the wlan card, see the foregoing section.

Open the file wlan0 with root permission.

$ sudo nano wlan0

In the end your file should look like:

$ cat /etc/network/interfaces.d/wlan0 

# Used such that wlan0 is brought up during boot
auto wlan0

# Used such that wlan0 is brought up if plugged in later or unplugged/plugged
allow-hotplug wlan0

# Used to activate multiple configuration for wlan0
iface wlan0 inet manual

# Define use of wext driver
wpa-driver wext

# Activating roaming 
wpa-roam /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf

# First known WLAN network. Connection with DHCP
iface bootwifi inet dhcp

# Fallback interface when there are no identifiers in the wpa_supplicant.conf network stanza's
iface default inet dhcp

Now the system can be rebooted. If all settings are correct, Odroid C1 should automatically connect to the wifi network. Also if the antenna is plugged in at a later stage the board should be able to connect to the wifi network.

In the preceding step it was assumed that the directory /etc/network/interfaces.d where the file wlan0 is located is sourced in the file /etc/network/interfaces . Therefor the file /etc/network/interfaces looks like:

$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

Roaming in multiple networks

Assuming you have set up a wifi network connection as described in the preceding section, it is possible to add a second or multiple wifi networks and assign those network different priorities such that Odroid C1 will automatically connect to that one present with the highest priority. Supposing the wlan card should also automatically connect to a second wifi network called “prior_wifi” that should have a higher priority than the already installed network called “my_wifi”, the following steps must be executed: In a first step open the file wpa_supplicant_my_wifi.conf that was created as explained in the foregoing section.

$ sudo nano /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf

Adapt it such that it looks like:

# reading passphrase from stdin
network={
        ssid="my_wifi"
        #psk="easy_password"
        psk=79be906c320eef65c104e14fc264d5ca2812660aeffc519490407e01776f67e1
        id_str="bootwifi"
        priority=1
}
# reading passphrase from stdin
network={
        ssid="prior_wifi"
        #psk="test_password"
        psk=a9f676ecd45a1fc9da1e06cbef273b2189c3238aad1ed8aaeeeb6a173675d63d
        id_str="priorwifi"
        priority=15
}

On the one hand a new network called “prior_wifi” with the id_str “priorwifi” has been added. On the other hand priority values have been assigned to the two networks. A higher priority number equals higher priority. In a second step open the file wlan0 that was created in the preceding section.

$ sudo nano /etc/network/interfaces.d/wlan0

Add the line iface priorwifi inet dhcp such that the file looks like:

$ cat /etc/network/interfaces.d/wlan0 

# Used such that wlan0 is brought up during boot
auto wlan0

# Used such that wlan0 is brought up if plugged in later or unplugged/plugged
allow-hotplug wlan0

# Used to activate multiple configuration for wlan0
iface wlan0 inet manual

# Define use of wext driver
wpa-driver wext

# Activating roaming 
wpa-roam /etc/wpa_supplicant/wpa_supplicant_my_wifi.conf

# First known WLAN network. Connection with DHCP
iface prioriwifi inet dhcp

# Second known WLAN network. Connection with DHCP
iface bootwifi inet dhcp

# Fallback interface when there are no identifiers in the wpa_supplicant.conf network stanza's
iface default inet dhcp

To update the new modifications and connect to the network with the higher priority, do the following:

sudo wpa_action wlan0 stop
sudo wpa_action wlan0 reload
sudo ifup wlan0

If all settings are correct, Odroid C1 should automatically connect to the network with the highest priority.

ROS (Robot Operating System)

Information can be found under:

Installation of bluefox camera driver

Go to the matrix vision homepage: http://www.matrix-vision.com/software-drivers-en.html. Choose ARM Boards→mvBlueFOX and download the files install_mvBlueFOX_ARM and mvBlueFOX ARMhf_gnueabi 2.12.1.tgz and save them in the same folder on the board. Remark: In this step it is assumed that the ARM board is hard float. To check for this type the following:

dpkg -l

If ARM board is hard float one should see packages that are denoted with armhf in the third column that indicates the architecture. Next go to the folder where the before-mentioned downloaded files where saved and enable the execute flag:

chmod a+x install_mvBlueFOX_ARM.sh

Then run the installation script:

./install_mvBlueFOX_ARM.sh 

The driver application is installed in /opt/mvIMPACT_Acquire by default. More information concerning the installation of the driver can be found in: http://www.matrix-vision.com/manuals/mvBlueFOX/mvBF_page_quickstart.html#mvBF_subsubsection_quickstart_linux_software.

Establishing ROS node for bluefox camera

In this section it is assumed that a catkin workspace has been created on the board. More information on how to create such a workspace can be found under http://wiki.ros.org/ROS/Tutorials/InstallingandConfiguringROSEnvironment.

Download the following repositories and save them in the source folder of your catkin workspace on the board (e.g. catkin_ws/src):

rm -rf ~/temp_catkin_packages
wget -P ~/temp_catkin_packages https://github.com/KumarRobotics/camera_base/archive/master.zip
unzip -d ~/temp_catkin_packages ~/temp_catkin_packages/master.zip
rsync -a ~/temp_catkin_packages/camera_base-master/ ~/catkin_ws/src/camera_base/
rm ~/temp_catkin_packages/master.zip
wget -P ~/temp_catkin_packages https://github.com/KumarRobotics/bluefox2/archive/master.zip
unzip -d ~/temp_catkin_packages ~/temp_catkin_packages/master.zip
rsync -a ~/temp_catkin_packages/bluefox2-master/ ~/catkin_ws/src/bluefox2/
rm -r ~/temp_catkin_packages

Now go to the catkin workspace and run catkin_make :

source ~/catkin_ws/devel/setup.bash
cd ~/catkin_ws
catkin_make -j1

The -j1 flag is set to avoid parallel compilation what can lead to issues with the RAM

Befor starting the node to run the bluefox camera open the file single_node.launch, e.g. with the nano editor:

nano ~/catkin_ws/src/bluefox2/launch/single_node.launch

Add the device number to the <arg name=“device”/> entry. E.g. if the device number was 25000060, the entry would look like: <arg name=“device” default=“25000060”/> . The device number can be found on the backside of the bluefox camera below the barcode as shown in the picture above (i.e. in the image the device number is 25000060). Save the file (in nano Cntl+o) and close it (in nano Cntl+x).

To publish images from the bluefox to the ROS network start roscore in a second terminal. Then run the rosnode:

roslaunch bluefox2 single_node.launch
 

Troubleshooting

  • Executing roslaunch bluefox2 single_node.launch gives the error message:
[single_node.launch] is neither a launch file in package [bluefox2] nor is [bluefox2] a launch file name The traceback for the exception was written to the log file

Possible solution is sourcing the setup.bash file of the catkin workspace:

source ~/catkin_ws/devel/setup.bash
 
  • Executing roslaunch bluefox2 single_node.launch gives the error message:
ERROR: could not contact master [http://localhost:11311]

Potential problem is that roscore uses another ROS_MASTER_URI than the node single_node looks for. To remedy this problem, go to the terminal where ros_core runs and terminate it then set the ROS_MASTER_URI to the localhost IP:

export ROS_MASTER_URI=http://127.0.0.1:11311/
roscore

Now go to the terminal where single_node should run and make the same:

export ROS_MASTER_URI=http://127.0.0.1:11311/
roslaunch bluefox2 single_node.launch

Subscribe to published images over network

If the board is connected to a network to which other computers that have ROS installed are connected as well it is possible to subscribe from one of these computers to the published images from the ros node running on the board. To do so the environmental variable of ROS_MASTER_URI and ROS_IP of the board and of the computer which should subscribe to the images need to be adapted. For clarity commands are denoted with OdroidC1 when they should be executed on the board and COMP when they should be executed on another network computer. In a terminal of the board set the ROS_MASTER_URI and the ROS_IP to the IP of the board in the network. Assuming the IP of the board in the network was 192.168.0.80, the command would look like:

OdroidC1$ export ROS_MASTER_URI=http://192.168.0.80:11311/
OdroidC1$ export ROS_IP=192.168.0.80

To find out the IP in the network, type in the command window:

hostame -I

In a terminal running on the desired network computer where the images should be subscribed to, do following: Assign the IP of the board to the environmental variable ROS_MASTER_URI and the IP of the computer itself to the environmental variable ROS_IP. Assuming the IP of the computer was 192.168.0.14, do the following:

COMP$ export ROS_MASTER_URI=http://192.168.0.80:11311/
COMP$ export ROS_IP=192.168.0.14

Start roscore and the rosnode single_node on the board:

OdroidC1$ roscore
OdroidC1$ roslaunch bluefox2 single_node.launch

To subscribe to the images and to view it on a screen on a network computer, start the rqt_gui on the computer:

COMP$ rosrun rqt_gui rqt_gui

In this GUI click on Plugins in the menu bar then choose Visualization→Image View and view the raw images by choosing image_raw.

In every new terminal the environmental variables need to be set again. To check the current value of ROS_MASTER_URI environmental variable:

 echo $ROS_MASTER_URI

Calibrating bluefox camera

The calibration of the bluefox camera is carried out on an external computer with access to a screen. To run the camera on a external computer, the bluefox camera driver and bluefox2 package must be installed on this computer as well.

Please use an appropriate driver for the computer. Different types can be found under http://www.matrix-vision.com/software-drivers-en.html

Connect the camera to the computer and start the node single_node.

roslaunch bluefox single_node.launch

Follow the steps described in this tutorial:

http://wiki.ros.org/camera_calibration/Tutorials/MonocularCalibration

If the calibration was successfully carried out, press “commit” as described in the end of the tutorial. If the camera number was 25000070, the calibration parameter would be saved in the file mv_25000070.yaml in the folder camera_info in the ROS home directory. Copy this file to the board and save it in the camera_info folder in the ROS home directory. Now the board is able to publish images and camera parameters.

Viewing rectified images

To view the rectified images, the raw images must be processes with the calibration parameters by the packages image_proc. To enable image_proc, open the file single_node.launch on the board, e.g. with nano:

nano ~/catkin_ws/src/bluefox2/launch/single_node.launch

Go to the argument (arg) proc entry and set its default value true. The entry would look like arg name=“proc” default=“true”/>. Go to the node proc entry labelled with <!-- Proc --> and change the namespace (ns) to the namespace of the camera such that the entry would look like ns=“$(arg camera)”. Save the file (in nano Cntl+o) and close it (in nano Cntl+x).

To view the rectified images on a network computer the same steps as described in the above section “Subscribe to published images over network” are applicable. In the rqt_gui the rectified images can be viewed by selecting image_rect.

Connecting Pixhawk with Odroid

The Pixhawk is connected with the Odroid via a UART connection. The Rx/Tx pins on the Odroid C1 are used for this purpose. Messages are sent via the ROS network that runs on the Odroid C1. For this reason it is necessary to install the mavros package. It can be downloaded here. It is also necessary to install the mavros_extra package that can be downloaded here. The launch file px4.launch is adapted such that it looks like:

<launch>
	<!-- vim: set ft=xml noet : -->
	<!-- example launch script for PX4 based FCU's -->

	<arg name="fcu_url" default="/dev/ttyS2:921600" />
	<arg name="gcs_url" default="" />
	<arg name="tgt_system" default="1" />
	<arg name="tgt_component" default="1" />
	<arg name="log_output" default="log" />
	<include file="$(find mavros)/launch/node.launch">
	<arg name="pluginlists_yaml" value="$(find mavros)/launch/px4_pluginlists.yaml" />
	<arg name="config_yaml" value="$(find mavros)/launch/px4_config.yaml" />
	<arg name="fcu_url" value="$(arg fcu_url)" />
	<arg name="gcs_url" value="$(arg gcs_url)" />
	<arg name="tgt_system" value="$(arg tgt_system)" />
	<arg name="tgt_component" value="$(arg tgt_component)" />
	<arg name="log_output" value="$(arg log_output)" />
	</include>
</launch>

This node is started by typing:

roslaunch mavros px4.launch

Sending triggering signal from Pixhawk autopilot

The Pixhawk autopilot is capable of sending a triggering signal to the bluefox camera(s). In the following section it is shown how the Pixhawk and the Odroid are set up such that the Pixhawks sends simultaneously two trigger pulses to two bluefox cameras such that these two bluefox cameras capture image frames at the same time. To accomplish this task from a software perspective, there are several steps that must be considered. They are separated into three parts:

  1. Starting camera trigger app on Pixhawk
  2. Establishing service call that sends message to Pixhawk to start triggering
  3. Adapt camera driver to send ready-for-trigger signal

In the following section these steps are explained in more detail. It is important to note that the mavros node as introduced in the preceding section must be started otherwise it is not possible to communicate with the Pixhawk.

Starting camera trigger app on Pixhawk

The camera trigger app is part of the Pixhawk firmware and the source code can be found here. In the file camera_trigger_params.c the desired parameters can be set. In this example two bluefox cameras should be triggered simultaneously. The two AUX pins 1 and 2 of the Pixhawk should be used to send the trigger signal. Thus the parameter TRIG_PINS is set to 12. To start the camera trigger app at boot, create the file extra.txt on the SD card and write the following:

camera_trigger start

Even though the camera trigger app is started at boot, it should start to send the trigger signal only after the service call from the Odroid has arrived. Please note, the camera trigger app on the Pixhawk does not only send electric trigger pulses it also sends a timestamp message that corresponds to the time instance when the trigger pulse was sent. This message is forwarded to the Odroid C1 and then published in the ROS network via the application mavros that was introduced before.

Establishing service call that sends message to Pixhawk to start triggering

The Odroid C1 is set up to send a ROS service call from type mavros::CommandTriggerControl as soon as both cameras are ready to capture an image, i.e. when they are in a state where they await the first trigger signal. An example is given in the source file starttriggersignal.c and can be downloaded here. If this service call is sent, the Pixhawk should start to continously send trigger pulses from AUX1 and AUX2 pins for the two bluefox cameras.

Adapt camera driver to send ready-for-trigger signal

The camera driver is adapted such that the following is guaranteed:

  • The cameras capture images only after a trigger signal has arrived and publishes the image in ROS only if the corresponding timestamp message has arrived
  • The cameras send a a service call when they are ready to capture the first frame

The first point is accomplished such that it complies with the manufactures specifications. Please note, the Pixhawk sends a timestamp that corresponds to the start instance of the trigger pulse. This timestamp is forwarded to the ROS network with the application mavros. The camera driver subscribes to this timestamp message and buffers it for the next frame that arrives shortly due to the transfer delay of the image (USB). The timestamp message is of type mavros_extras::CamIMUStamp and is sent in topic /mavros/cam_imu_sync/cam_imu_stamp. If either the timestamp message has not arrived or the image frame has not been captured, the timestamp message and the image frame are discarded. The camera driver has access to the exact exposure time that was used for the capturing of the image. Thus the capturing time is approximated by adding the half of the exposure time to the timestamp that is sent by the Pixhawk. The adaptions for the bluefox2 repository can be downloaded here and for the camera_base repository here. Please note, both repositories are needed in order that the triggering works properly. The second point is accomplished, by sending a service call of type std_srvs::Trigger to the node that sends the final service call to the Pixhawk to start the triggering. An example program that sends the service call to the Pixhawk as soon as both cameras have sent their ready-for-trigger signal is given in the source file starttriggersignal.cpp and can be downloaded here. Both bluefox cameras are started by calling the launch file stereo_px4.launch that resides in the adapted bluefox2 repository:

roslaunch bluefox2 stereo_px4.launch

Turning trigger pulses on and off via command line

It is possible to make the Pixhawk start to send respectively stop sending trigger pulses from the command line from the Odroid. To make the Pixhawk start to send trigger pulses:

rosservice call /mavros/cmd/trigger_control 1 0

To make the Pixhawk stop sending trigger pulses:

rosservice call /mavros/cmd/trigger_control 0 0

Please note, the mavros node as introduced earlier must run on the Odroid C1 otherwise the service call will not reach the Pixhawk. Furthermore, it is necessary that the camera trigger app is started on the Pixhawk as described earlier.

Hardware connection

As mentioned the Pixhawk is set up to start to send trigger pulses from the AUX1 respectively the AUX2 pins. They are indicated as green transparent area in the figure below.

Please note, the signal pin is connected with pin number 12 and the ground pin with the pin number 11 of opto-isolated digital input/output pins on the backside of the bluefox cameras. The pinout is shown below. The cable (pink) that is connected to the signal pin and the cable (gray) that is connected to the ground pin of the AUX pins of the Pixhawk and the plug are also shown below.

Connection of Odroid C1 with thermal camera Tamarisk 320

The Odroid C1 is interfaced with the thermal camera Tamarisk 320 via the Leopard board 368 via Ethernet connection. The thermal camera Tamarisk 320 and the Leopard board 368 are connected with a flex cable. Both devices are shown below. The image is taken form the manufacturer’s webpage. Details can be found here. The images are forward to the ROS network with the package gscam. Gscam is a ROS package and makes use of Gstreamer, a mulitmedia framework. Details of gscam can be found here. To forward the images to the ROS network the following steps are necessary:

  • Make sure Ethernet connection to Leopard board is established

To check this ping the Leopard board:

ping 192.168.0.168
  • Start roscore
  • Define environmental variable GSCAM_CONFIG:
export GSCAM_CONFIG="uridecodebin source::latency=1 uri=rtsp://192.168.0.168/1 ! ffmpegcolorspace"
  • Start gscam ROS node:
rosrun gscam gscam

The images can are then published on the topic /camera/image_raw.

Translations of this page:


Quick Links

QR Code: URL of current page