BODAS Connect Samples Code

Table of Contents

• Introduction
• Getting Started
  • Prerequisites
  • Development Infrastructure
  • Connecting your computer with the RCU
    • Serial connection
    • Windows Hyperterminal
    • Linux Minicom
    • Ethernet connections
• Developing Snaps for RCUs
  • Development and Testing
  • Building and Packaging
  • Installation and Testing
• License
• Contact
• Acknowledgements

Introduction

This guide describes how to create your own application for the Rexroth Connectivity Unit (RCU). It is going to start out by explaining how to set up your development infrastructure. This guide will not show you how to implement your functionality, but will focus on how to build, package and deploy your applications for/on the Rexroth Connectivity Unit. The examples are written in C++, Golang, Javascript (NodeJS) and Python. Example written in other languages will be added soon.

Getting Started

Some topics are not covered by this programming guides and are prerequisites for being able to start using it. Moreover you have to setup your development infrastructure.

Prerequisites

• Snapcraft overview
• Tutorial on creating a SNAP
• MQTT
• Eclipse Mosquitto
• Eclipse Mosquitto TLS
• Secure Shell
• Can-utils
• C++ Programming know-how if you want to use the C++ sample code
• Golang Programming know-how if you want to use the Golang sample code
• Javascript (NodeJS) Programming know-how if you want to use the Javascript (NodeJS) sample code
• Python3 Programming know-how if you want to use the Python3 sample code

Development Infrastructure

In order to efficiently develop for the RCU you need (additionally to your developer computer) a build computer and a RCU for final testing. They have to be connected in the same TCP/IP network. The following picture shows an example infrastructure where the Developer Computer (IPv4 Address 1), the Build Computer (IPv4 Address 2) and the RCU (IPv4 Address 3) are connected to the same network.

• Developer Computer: The developer computer is any computer that you would use for developing your application.
• Build Computer: Applications will run on the RCU armhf processor architecture. It is therefore necessary to build and package the application on a computer with the same architecture. The build computer that you use shall therefore have an armhf processor architecture. Additionally SNAP application are always based on an Ubuntu core snap. On RCUs we mainly use core and core18. We also recommend to have a version of Ubuntu 18 installed on the build computer. The build computer we use is a Raspberry Pi 3, on which 32-bit Ubuntu Server 18.04 is installed.
• RCU: We recommend to use an RCU4-3W for your development activities.

Connecting your computer with the RCU

Serial connection

Either Linux OS or Windows OS can be used to connect to the RCU from a Personal Computer (PC) through serial port. The required configuration parameters are the following:

• Bit Rate: 115200 bps
• Data Bits: 8
• Parity: none
• Bit Stop: 1
• Flow Control: None

Windows Hyperterminal

Use Windows HyperTerminal to connect the RCU to the PC configuring the serial port parameters to the values indicated in previous section. Switch on the RCU. Once the Kernel is loaded in RAM memory and the system is up, the device waits for the user to enter a valid user name to log in. Once logged in, the user is in the RCU file system which has the directory structure. To transfer a file from the PC to the RCU, change to /home directory or to the directory where the file is to be stored (cd /home or cd /directory_name), type rz command and choose Transfer-> Send File… option of the HyperTerminal. To transfer a file from the device to the PC, change to the directory where the file is, then type sz command indicating the name of the file (sz file_name) and choose the Transfer -> Receive File… option of the HyperTerminal. File transfer protocol is zmodem in both cases.

Linux Minicom

Run the minicom program and configure the serial port parameters to the values indicated in previous section. Minicom help is shown by typing Ctrl-A Z. Serial port device files (/dev/ttyS0, /dev/ttyS1…) must have reading and writing permissions for all users. Log in as root and type chmod a+rw /dev/ttySx to change permissions. Switch on the RCU and wait until login prompt appears. Log in and enter into the device Operating system. To transfer a file from the local PC to the device, change to /home directory (or to the directory where the file is to be stored), type rz command in RCU OS, type Control-A S so that the minicom knows the file that is to be transferred. The file transfer protocol is zmodem. To transfer a file from the device to the local PC, change to the directory where the file to be transferred is stored, type sz command indicating the name of the file (sz file_name) and type Control-A R so that the minicom starts to receive the file. The file transfer protocol is also zmodem.

Ethernet connections

To communicate with the RCU a SSH connection can be established too using the Ethernet interface, if the unit features this option. The system get the SSH daemon up by default. Default ip to reach the RCU via SSH: 192.168.10.1 on Port 22. Only login as jarvis is permitted. To get elevated rights the user has to become superuser from the jarvis console.

Developing Snaps for RCUs

Development and Testing

The following picture shows the high level architecture of our sample code during development on the developer computer. can1 is connected to can2 and we have an internal shell script which is generating CAN messages and sending those messages to can2. Two 120 Ohm resistors per CAN-channel are needed to properly terminate the CAN-bus.

MQTT Broker on RCU

The mosquitto broker is the central communication hub on the RCU. It handles asynchronous communication between software components on the RCU. Each component has to be authenticated by the Broker in order to be able to publish or receive message to/from the broker. Please get in touch with us at Connect.BODAS@boschrexroth.de to get the right configuration (mosquitto.conf), certificates and keys for communicating with the broker.

CAN Snap on RCU

This software module provides communication to the CAN bus based on Linux socket CAN. It provides the content of the CAN bus to other software modules via MQTT.

Parameterization

To change a parameter run

snap set can <parameter_key>=<parameter_value>

This Snap will filter the can messages on a given CAN IDs. To change the filter, create (or modify) a filter.txt and set the path to the file via

snap set can can.<interface>.fiter=<path/to/file/filter.txt>

Usage example

The snap can be managed using snapd like follows.

snap start can
snap stop can
snap remove can
snap info can

To review the log output, use following command. The optional -f flag allows to review the live logs.

journalctl -u snap.snap.can.cand [-f]

Alternatively you can use the following command, too.

snap logs can [-f]

The CAN messages received by RCU will be published to the broker on the defined topic. Per default the topic is hardware/can/channel/<interface>/rx The format of the messages is (<timestamp>) <interface> <CAN id>#<data> while the timestamp is in seconds.microseconds.

Example:

(1586260384.286194) can1 21A#FE3612FE690507AD

The CAN message sending from RCU will be sent to CAN bus on the defined topic. Per default the topic is hardware/can/channel/<interface>/tx The format of message is same as above, while the timestamp field will be ignored, because the CAN message will be send once the mqtt topic is received by this module. So zero '0' could be used as placeholder. Example:

(0) can1 21A#FE3612FE690507AD

Configuration Parameters

The following sample json snippet contains all parameters of the software module snap. Add this section to the /etc/rexroth/rcu.json configuration file on the RCU.

{
    "module": "can",
    "private": {
        "status.interval": 60,
        "logging.level": "info",
        "can1.baudrate": 250000,
        "can1.filter": "/etc/rexroth/can1.filter",
        "can2.baudrate": 250000,
        "can2.filter": "/etc/rexroth/can2.filter",
        "can3.baudrate": 250000,
        "can3.filter": "/etc/rexroth/can3.filter"
    },
    "public": {}
}

The shell script for generating can signals is using following can IDs: 001, 002, 003 and 004. Consequently add those IDs in the /etc/rexroth/can1.filter configuration file on the RCU.

001
002
003

Sample Code on the Developer Computer

The sample code is structured as follow:

• Definition of variables for running the code as an application on the RCU. These definitions are commented out when the code is not run on the RCU.

• Definition of variables for running the code as an application on your computer or on the build. These definitions are commented out when the code is run on the RCU.

• Definition of variables containing the path to the certificates and keys needed for the TLS communication with the MQTT Broker

• Definition of variables containing:

  • the topic for publishing a message that shall be sent through can2
  • the message be sent through can2
  • the topic for receiving messages that are coming through can1
  • the topic for receiving can status messages

• Inititialization of the communication with the mqtt broker

• Main functionality:

  • All messages received by the broker are printed on the console
  • A message is sent to the broker every 5 seconds

• Get in touch with us for getting the certificates and acces control list files that you need for the sample codes. Connect.Bodas@boschrexroth.de

Use your preferred IDE for the chosen programming language. Develop your application on your computer using the remote access to the RCU, over <<IPv4 Address 3>>, to communicate with the MQTT Broker. Test your application. Sample results of testing the application from the developer computer are shown on the following picture. We see that the code is printing received messages from the can1 interface and publishing messages that are forwarded to can2.

Building and Packaging

When the functionality of your application is successfully tested on your computer, follow following steps for building and packaging the application into a snap:

• configure your application to be packaged as a snap (change the host address of the MQTT Broker to 127.0.0.1, ...)
• create your snapcraft.yaml (learn more on how to create a snapcraft yaml file here: https://snapcraft.io/docs/creating-a-snap)
• copy the source code from the developer computer to the build computer

scp -r <<source_folder>> <<user_name>>@<<IPv4 Address 2>>:/home/<<user_name>>/

• on the build computer:
  • install all necessary libraries needed for building the sample on the build computer
    • E.g. for the C++ sample code you will beed to install:
      • Build tools and libraries

      apt-get -y install build-essential git libudev-dev zlib1g-dev libssl-dev gcc g++ cmake

      • Eclipse Paho MQTT C++ Client Library which requires the Eclipse Paho C Client Library for the MQTT Protocol
  • test your code natively on the build computer to make sure that the functionality can be executed on a processor with armhf architecture
  • install the snapcraft tool

  sudo snap install snapcraft --classic

  • define your build computer as the host for building

  export SNAPCRAFT_BUILD_ENVIRONMENT=host

  • make sure that the install hook is executable under Linux.

  chmod +x /meta/hooks/install clean && snapcraft

  • build and package your application.

  snapcraft clean && snapcraft

After building and packaging, a snap with the ending "_armhf.snap" is created.

Installation and Testing

After sucessfully building and packaging your snap:

• Copy the generated snap to the RCU

scp <<snapname_version>>_armhf.snap <<user_name>>@<<IPv4 Address 3>>:/home/<<user_name>>/

• On the RCU:
  • Install the generated snap

  snap install <<snapname_version>>_armhf.snap --devmode --dangerous

  • Check that the installation was successful

  snap list

  • Test your snap by showing the output of its console:

  snap logs <<snapname>> -f

  • After testing you may want to remove the installed snaps

  snap remove <<snapname_version>>_armhf.snap --purge

The following picture shows the high level architecture of our sample code during the test on the Rexroth Connectivity Unit. can1 is still connected to can2 and we still have an internal shell script which is generating CAN messages and sending those messages to can2. Two 120 Ohm resistors per CAN-channel are needed to properly terminate the CAN-bus.

The test results on the Rexroth Connectivity Unit are shown on the following picture:

License

All sample codes are distributed under the MIT License. See LICENSE for more information.

Contact

BODAS Connect Team - Connect.BODAS@boschrexroth.de

Project Link: BODAS Connect

Acknowledgements

• Eclipse Paho C Client Library for the MQTT Protocol, Eclipse Public License v2.0 and Eclipse Distribution License v2.0
• Eclipse Paho MQTT C++ Client Library, Eclipse Public License v1.0 and Eclipse Distribution License v1.0
• Eclipse Paho MQTT Go client, Eclipse Public License - v 1.0 and Eclipse Distribution License - v 1.0
• Eclipse Paho™ MQTT Python Client, Eclipse Public License 1.0 and the Eclipse Distribution License 1.0
• mqtt NPM Package, The MIT License
• Best-README-Template, The MIT License

Image sources

• https://pixabay.com/vectors/device-electronic-open-hardware-pi-1295187/
• https://pixabay.com/vectors/wlan-telecommunications-router-2007682/
• https://pixabay.com/illustrations/macbook-vector-macbook-pro-4515471/