Viewing Arxterra Bluetooth and USB Communication

Packet command and telemetry channel data may be viewed directly in the ArxRobot App or using a terminal application program like CoolTerm. It should be noted that Atmel Studio 7 has a built-in telemetry window. The former is the subject of this chapter.

Trace Commands to the 3DoT Microcontroller Unit (MCU)

Step 1: To reveal trace statements of the major commands and telemetry messages that are being processed, open the Action Bar tray by selecting the hamburger icon “≡” on the right of the icon menu bar as shown in Figure 13.1.

Figure 13.1: How to open the Action Bar tray.

Step 2: When the Action Tray opens, you will see a slide switch labeled “Developer Mode.”  As shown in Figure 13.2, sliding this switch to the ON position, will enable diagnostic and configuration features of interest to programmers and hardware engineers.

Figure 13.1: Action Bar tray with developer mode turned ON.

Step 3: To reveal trace statements activate the switches for “Show Trace” and “Trace”.

Figure 13.2: Action Bar tray in developer mode, with “show trace” and “trace” turned ON.

For example, note the statements appearing as the motor controls are moved as shown in Figure 13.3.

Figure 13.2: Trace as motor control sliders are moved.

After a quick review of Section “Command Packet Example – Move Forward at Half Speed”, we see that after each line starting with “sent to MCU” are bytes i = 2 to 6 of a command packet.

data[i] i = 0 i = 1 i = 2 i = 3 i = 4 i = 5 i = 6 i = 7
Packet A5 05 01 01 6A 01 6A A1

data [0] = Command Packet ID

data [1] = Packet length w/o parity byte (N = 05)

data [2] = Command ID = Move

data [3] = Left Motor Forward

data [4] = Half speed (128/255)

data [5] = Right Motor Forward

data [6] = Half speed (128/255)

data [7] = LRC byte

Trace Telemetry from the 3DoT Microcontroller Unit (MCU)

WARNING

The “Trace” setting should not be kept ON indefinitely, because it can drastically slow the app’s performance.

Step 1: If you want to see hexadecimal string representations of all bytes arriving from the MCU, open the settings (“cog” icon) menu and select the “Components Test Configuration” view.

Figure 13.3: Open the test configuration window.

Figure 13.4: Trace raw data incoming from MCU slide switch to ON.

You should now see telemetry from the MCU as shown in Figure 13.5.

Figure 13.5: Trace of MCU telemetry.

After a quick review of Section “12 – 4: Telemetry Packet Example – Move Forward at Half Speed”, we see that after each line starting with “sent to MCU” are bytes i = 2 to 6 of a command packet.

After a quick review of Figure 12.6: Telemetry IDs and Section “12 – 3: Command Packet Example – Command Exception Code”, we see that after each line starting with “Telemetry data received:” is a telemetry.

data[i] i = 0 i = 1 i = 2 i = 3
Packet CA 01 11 DA

data [0] = Telemetry Packet ID

data [1] = Packet length w/o parity byte (N = 1)

data [2] = Telemetry ID = Pong

data [3] = LRC

A Pong packet is sent by the MCU in response to a Ping command from the processor (see  Arduino libraries  Robot3DoTBoard src TelecomClass.cpp). This handshake between the ArxRobot application and the MCU ensures that communications has not been lost.

Echo Command Packets

WARNING

The “ECHO_COMMANDS” settings should not be kept at TRUE indefinitely, because it drastically slows the MCU performance and may result in loss-of-signal and other unexpected problems.

Follow these steps to have the Microcontroller Unit (MCU) echo back every command it receives from the ArxRobot application.

Step 1: Open the Config.h file located in the Robot3DoTBoard source folder (Arduino libraries  Robot3DoTBoard src Config.h) and locate the “Debug Mode” block.

Step 2: To have the Microcontroller Unit (MCU) echo back every command it receives from the ArxRobot app, make the following change to the Debug Mode, #define preprocessor directive (also known as a macro definition)..

#define ECHO_COMMANDS FALSE  ⇢  #define ECHO_COMMANDS TRUE

Step 3: Save the file. 

Step 4: Compile the script and upload to the 3DoT board. 

USB Serial Communications

Previously in “Viewing Arxterra Bluetooth Wireless Communication” we looked at how to trace commands and telemetry from the ArxRobot Application. In Section “3DoT Application Development” we are going to look at how to write Arduino Scripts for your robot. While using the trace mode from the ArxRobot application will be sufficient in many cases, as the complexity of your robot increases you may want to test and debug your robot independent of the ArxRobot application. To understand how this is done we need to look at the two serial communication methods supported by 3DoT robots.

Bluetooth Communications

As demonstrated in the previous chapters, the 3DoT MCU communicates to the ArxRobot application through a Bluetooth module which interfaces on the 3DoT board to a USART peripheral subsystem on the ATmega32U4 microcontroller. Within the Arduino language this interface is the responsibility of the “Serial1” (Phone ⇄ Bluetooth ⇄ USART) object. All Bluetooth serial communication uses command and telemetry packets.

USB Communications

Although you may not have thought about it, when you write an Arduino script and upload it to the 3DoT board, you are communicating to the PC through a USB interface. Communications across the USB interface is the responsibility of the “Serial” (PC ⇄ USB) object and the data which goes across it may take many forms.

  • A “.hex” file format is used to upload programs to the MCU when you press the upload button.
  • Arduino instruction Serial.println(“Hello World”) sends a string of ascii characters to the “Serial Monitor” which displays this text message.
  • Serial terminal programs like CoolTerm may be used to send and display packets, a series of bytes displayed in hexadecimal.

MCU Monitoring using the Arduino IDE Serial Monitor

If you have done any Arduino programming you are probably already familiar with the “Serial.print” instruction. Print instructions are the simplest way to debug your Arduino programs.

The 3DoT board also has a large number of Print instructions which are used to display status and error information during development. Follow these steps to enable these built-in “Serial.print” instructions.

Step 1: Open the Config.h file located in the Robot3DoTBoard source folder (Arduino libraries  Robot3DoTBoard src Config.h) and locate the “Debug Mode” block.

Step 2: To have the Microcontroller Unit (MCU) send internal status and error messages, set the DEBUG flag to TRUE.

#define DEBUG FALSE  ⇢   #define DEBUG TRUE

Step 3: Save the file. 

Step 4: Compile the script and upload to the 3DoT board. 

Serial Terminal Programs – CoolTerm

Up to this point commands and telemetry packets have been sent and received by the ArxRobot application. As you develop and debug your robot, you will ultimately want to directly communicate to your program from a serial terminal program, like CoolTerm. This USB serial communication path is shared with the Arduino IDE (program upload and the serial monitor window). It is important to note, that all these communication paths are to a limited extent mutually exclusive. For example, an ASCII text string, like “Hello World” will appear as gibberish when displayed as hexadecimal digits in a serial monitor application.  Consequently, you may want to set the DEBUG flag to FALSE when sending and receiving telemetry packets.

In the next section, we will reuse the Robot_3DoT_Blink to show you how to use the CoolTerm serial monitor application to send and receive data packets.

Robot_3Dot_Blink (Using Arduino + CoolTerm) Tutorial

In Section 11 – “Robot_3Dot_Blink Lab” you changed the blink frequency by adding a custom widget to the ArxRobot application. In this tutorial you are going to change the blink frequency by sending command packets from the CoolTerm serial terminal application.

To better understand what is happening “behind the scenes” before stepping through this tutorial, I would recommend turning ON the trace mode of the ArxRobot application as described in Section 13 – “Viewing Arxterra Bluetooth Wireless Communication.”

Step 1: Open  and Upload  your Robot_3Dot_Blink written in  Section 11 – “Robot_3Dot_Blink Lab.”

Step 2: Download and open the “CoolTerm” application.

Step 3: Once the program is open, click on the “View Hex” icon and select “Connect” if CoolTerm is having trouble finding the board connected to the computer in use. Can also select Connection > Options > Re-Scan Serial Port.

Step 4: Next, press CTRL+T (alternatively, go to Connection > Send String). When this window is open, select “Hex” and not “ASCII.” Now, input the command packet in the sequence specified. For this example, 0x05  was chosen for parameter ‘0’ to make the LED blink five times.

Step 5: Lastly, to input the LRC byte, it may be calculated using the XOR checksum calculator or any of the aforementioned methods in Section 12 – 5: Calculating the LRC Byte of this document. Copy the command packet string into the calculator and it should return the LRC byte as shown below.

The LRC Byte should be the last byte in the command packet string in CoolTerm. Then, open the “Send String” window and click “Send” shown below. The onboard orange LED labeled “L” should blink five times if the command packet string is correct.