3 Getting Started

This section introduces the basic operation and development of the SCOUT 2.0 platform using the CAN bus interface.

3.1 Use and operation

The basic operating procedure of startup is shown as follows:

Check

Check the condition of SCOUT 2.0. Check whether there are significant anomalies; if so, please contact the after-sale service personal for support;

Check the state of emergency-stop switches. Make sure both emergency stop buttons are released;

Startup

Rotate the key switch (Q1 on the electrical panel), and normally, the voltmeter will display correct battery voltage and front and rear lights will be both switched on;

Check the battery voltage. If there is no continuous "beep-beep-beep..." sound from beeper, it means the battery voltage is correct; if the battery power level is low, please charge the battery;

Press Q3 (drive power switch button).

Shutdown

Rotate the key switch to cut off the power supply;

Emergency stop

Press down emergency push button both on the left and the right of SCOUT 2.0 vehicle body;

Basic operating procedure of remote control

After the chassis of SCOUT 2.0 mobile robot is started correctly, turn on the RC transmitter and select the remote-control mode. Then, SCOUT 2.0 platform movement can be controlled by the RC transmitter.

3.2 Charging

SCOUT 2.0 IS EQUIPPED WITH A 10A CHARGER BY DEFAULT TO MEET CUSTOMERS' RECHARGING DEMAND.

3.2.1 Charging operation

Make sure the electricity of SCOUT 2.0 chassis is powered off. Before charging, please make sure the power switch in the rear control condole is turned off;

Insert the charger plug into Q6 charging interface on the rear control panel;

Connect the charger to power supply and turn on the switch in the charger. Then, the robot enters the charging state.

Note: For now, the battery needs about 3 to 5 hours to be fully recharged from 22V, and the voltage of a fully recharged battery is about 29.2V; the recharging duration is calculated as 30AH ÷ 10A = 3h.

3.2.2 Battery replacement

SCOUT2.0 adopts a detachable battery solution for the convenience of users. In some special cases, the battery can be replaced directly. The operation steps and diagrams are as follows (before operation, ensure that SCOUT2.0 is power-off):

Open the upper panel of SCOUT2.0, and unplug the two XT60 power connectors on the main control board (the two connectors are equivalent) and the battery CAN connector;

Hang SCOUT2.0 in midair, unscrew eight screws from the bottom with a national hex wrench, and then drag the battery out;

Replace the battery and fixed the bottom screws.

Plug the XT60 interface and the power CAN interface into the main control board, confirm that all the connecting lines are correct, and then power on to test.

3.3 Communication using CAN

SCOUT 2.0 provides CAN and RS232 interfaces for user customization. Users can select one of these interfaces to conduct command control over the vehicle body.

3.3.1 CAN cable connection

SCOUT2.0 deliver with two aviation male plugs as shown in Figure 3.2. For wire definitions, please refer to Table 2.2.

3.3.2 Implementation of CAN command control

Correctly start the chassis of SCOUT 2.0 mobile robot, and turn on DJI RC transmitter. Then, switch to the command control mode, i.e. toggling S1 mode of DJI RC transmitter to the top. At this point, SCOUT 2.0 chassis will accept the command from CAN interface, and the host can also parse the current state of chassis with the real-time data fed back from CAN bus. For the detailed content of protocol, please refer to CAN communication protocol.

3.3.3 CAN message protocol

Note[1]: Robot chassis firmware version V1.2.8 is supported by subsequent versions, and the previous version requires firmware upgrade to support Note[2]: The buzzer will sound when the battery under-voltage, but the chassis control will not be affected, and the power output will be cut off after the under-voltage fault

The command of movement control feedback frame includes the feedback of current linear speed and angular speed of moving vehicle body. For the detailed content of protocol, please refer to Table 3.3.

The control frame includes control openness of linear speed and control openness of angular speed. For its detailed content of protocol, please refer to Table 3.4.

The mode setting frame is used to set the control interface of the terminal. For its detailed content of protocol, please refer to Table 3.5.

Description of control mode: In case the SCOUT 2.0 is powered on and the RC transmitter is not connected, the control mode is defaulted to standby mode. At this time, the chassis only receives control mode command, and does not respond other commands. To use CAN for control need to switch CAN command mode at first. If the RC transmitter is turned on, the RC transmitter has the highest authority, can shield the control of command and switch the control mode.

Status setting frame is use to clear the system errors. For its detailed content of protocol, please refer to Table 3.6.

[Note 3] Example data: The following data is only used for testing

1.The vehicle moves forward at 0.15m/s

2.The vehicle steering 0.2rad/s

The chassis status information will be feedback, and what’s more, the information about motor current, encoder and temperature are also included. The following feedback frame contains the information about motor current, encoder and motor temperature. The motor numbers of the 4 motors in the chassis are shown in the figure below:

The front and external lights also support command control. The following table shows the control commands:

Note [5]: The values are valid for custom mode.

3.4 Serial Communication Protocol

3.4.1 Instruction of serial protocol

It is a standard for serial communication jointly formulated by the Electronic Industries Association (EIA) of the United States in 1970 conjunction with Bell Systems, modem manufacturers and computer terminal manufacturers. Its name is "Technical Standard for Serial Binary Data Exchange Interface Between Data Terminal Equipment (DTE) and Data Communication Equipment (DCE)". The standard stipulates that a 25-pin DB-25 connector is used for each connector. The signal content of each pin is specified, and the levels of various signals are also specified. Later, IBM's PC simplified RS232 into a DB-9 connector, which became the practical standard. The RS-232 port of industrial control generally only uses three lines of RXD, TXD, and GND.

3.4.2 Serial Connection

Use the USB to RS232 serial cable in our communication tool to connect to the serial port at the rear of the car, use the serial tool to set the corresponding baud rate, and use the sample data provided above to test. If the remote control is turned on, it is necessary to switch the remote control to command control mode. If the remote control is not turned on, just send the control command directly. It should be noted that the command must be sent periodically. If the chassis exceeds 500MS and the serial port command is not received, it will enter the loss of connection protection. status.

3.4.3 Serial Protocol Content

Basic Communication Parameter

Instruction of protocol

The protocol includes the start bit, frame length, frame command type, command ID, data range, frame ID, and checksum. The frame length refers to the length excluding the start bit and the checksum. The checksum is the sum of all data from the start bit to the frame ID; the frame ID bit is from 0 to 255 counting loops, which will be added once every command sent.

/**

*@brief serial message checksum example code

*@param[in] *data : serial message data struct pointer

*@param[in] len :serial message data length

*@return the checksum result

static uint8 Agilex_SerialMsgChecksum(uint8 *data, uint8 len)

{

uint8 checksum = 0x00;

for(uint8 i = 0 ; i < (len-1); i++)

{

checksum += data[i];

}

return checksum;

}

Protocol Content

Note[1]: Robot chassis firmware version V1.2.8 is supported by subsequent versions, and the previous version requires firmware upgrade to support.

Movement Control Feedback Command

Movement Control Command

Control Mode Setting Command

Status Setting Command

Motor Drive High Speed Information Feedback Frame

Motor Drive Low Speed Information Feedback Frame

Light Control Frame

Light Control Feedback Frame

Mileage Feedback Frame

Version Information Enquiry Frame

Version Information Feedback Frame

Remote Control Information Feedback Frame

BMS Feedback Frame

Example Data

By controlling the chassis to move forward at a linear speed of 0.15m/s, the following is the specific data content.

The following is the content of the data range:

The entire data content is: 5A A5 0A 55 01 00 96 00 00 00 00 00 F5 Other note: This protocol requires firmware version more than V1.5.12

3.5 Firmware upgrades

In order to facilitate users to upgrade the firmware version used by SCOUT 2.0 and bring customers a more complete experience, SCOUT 2.0 provides a firmware upgrade hardware interface and corresponding client software. A screenshot of this application is shown in Figure 3.3.

Upgrade preparation

SERIAL CABLE × 1

USB-TO-SERIAL PORT × 1

SCOUT 2.0 CHASSIS × 1

COMPUTER (WINDOWS OPERATING SYSTEM) × 1

Firmware upgrade software

https://github.com/agilexrobotics/agilex_firmwaregithub.com

Upgrade procedure

Before connection, ensure the robot chassis is powered off;

Connect the serial cable onto the serial port at rear end of SCOUT 2.0 chassis;

Connect the serial cable to the computer;

Open the client software;

Select the port number;

Power on SCOUT 2.0 chassis, and immediately click to start connection (SCOUT 2.0 chassis will wait for 3s before power-on; if the waiting time is more than 3s, it will enter the application); if the connection succeeds, "connected successfully" will be prompted in the text box;

Load Bin file;

Click the Upgrade button, and wait for the prompt of upgrade completion;

Disconnect the serial cable, power off the chassis, and turn the power off and on again.

3.6 SCOUT 2.0 SDK

In order to help users implement robot-related development more conveniently, a cross-platform supported SDK is developed for SCOUT 2.0 mobile robot.SDK software package provides a C++ based interface, which is used to communicate with the chassis of SCOUT 2.0 mobile robot and can obtain the latest status of the robot and control basic actions of the robot. For now, CAN adaptation to communication is available, but RS232-based adaptation is still under way.Based on this, related tests have been completed in NVIDIA JETSON TX2.

3.7 SCOUT2.0 ROS Package

ROS provide some standard operating system services, such as hardware abstraction, low-level device control, implementation of common function, interprocess message and data packet management. ROS is based on a graph architecture, so that process of different nodes can receive, and aggregate various information (such as sensing, control, status, planning, etc.) Currently ROS mainly support UBUNTU.

Development Preparation

Hardware preparation

CANlight can communication module ×1

Thinkpad E470 notebook ×1

AGILEX SCOUT 2.0 mobile robot chassis ×1

AGILEX SCOUT 2.0 remote control FS-i6s ×1

AGILEX SCOUT 2.0 top aviation power socket ×1

Use example environment description

Ubuntu 16.04 LTS (This is a test version, tasted on Ubuntu 18.04 LTS)

ROS Kinetic (Subsequent versions are also tested)

Git

Hardware connection and preparation

Lead out the CAN wire of the SCOUT 2.0 top aviation plug or the tail plug, and connect CAN_H and CAN_L in the CAN wire to the CAN_TO_USB adapter respectively;

Turn on the knob switch on the SCOUT 2.0 mobile robot chassis, and check whether the emergency stop switches on both sides are released；

Connect the CAN_TO_USB to the usb point of the notebook. The connection diagram is shown in Figure 3.4.

ROS installation and environment setting

For installation details, please refer to http://wiki.ros.org/kinetic/Installa%02tion/Ubuntu

Test CANABLE hardware and CAN communication

Setting CAN-TO-USB adaptor

Enable gs_usb kernel module

$ sudo modprobe gs_usb

Setting 500k Baud rate and enable can-to-usb adaptor

$ sudo ip link set can0 up type can bitrate 500000

If no error occurred in the previous steps, you should be able to use the command to view the can device immediately

$ ifconfifig -a

Install and use can-utils to test hardware

$ sudo apt install can-utils

If the can-to-usb has been connected to the SCOUT 2.0 robot this time, and the car has been turned on, use the following commands to monitor the data from the SCOUT 2.0 chassis

$ candump can0

Please refer to:

[1]https://github.com/agilexrobotics/agx_sdk

[2]https://wiki.rdu.im/_pages/Notes/Embedded-System/- Linux/can-bus-in-linux.html