Autonomous Unmanned Aerial Vehicle Project/mLogger

mLogger

The need for mLogger arose due to a lack of fast efficient debugging tools for microcontrollers. Most debugging tools can potentially slow down the operations of a microcontroller. A major factor that distinguishes mLogger from most other debugging tools is how it reads incoming data from the microcontroller and displays it. Instead of using strings, mLogger can take binary information from the microcontroller, which is then decoded and displayed in a convenient human readable format. Using binary makes transmitting information significantly faster, thereby reducing the impact on crucial operations of the microcontroller.

mLogger is also capable of displaying information visually, using widgets. Widgets can take binary data transmitted from the microcontroller and display it in a manner dictated by the user by coding the widget. More information about widgets in mLogger and related examples widgets can be found here.

mLogger can be used with any project, as long the source code follows a few rules.

Contents:

mLogger UI

Figure 4.1: mLogger UI. showing command window, logging window, and widget for AUAV Project

The text entry bar for the MCU Port Log Window offers some searching/filtering functionality as listed below. This functionality can be seen in demo videos among other functionalities/capabilites discussed on this webpage.

  1. hide * : hides the message
  2. show * : shows the message if hidden by user earlier
  3. \<space><string> : searches for the string from current line to last line
  4. /<space><string> : searches for the string from current line to first line

 

The text entry bar at the very bottom is used for sending any data to the microcontroller and connecting to the COM port with a user defined baud rate.
The green square seen at the left-bottom corner of the Command Window and MCU Port Log Window turns red if the user scrolls up/down. Clicking on the red square takes the user back to the current line and restores the color of the square.

The algorithm used to display mLogger UI follows a hierarchical order as depicted below in the figure. All windows operate independently from each other. When mLogger starts, it opens four windows (Command Window, MCU Port Log Window, Widget Window, and a window at the bottom that behaves similar to a taskbar in Windows OS for switching between the aforementioned three windows). Thereafter, the window manager takes over the display and response control. All user input collected by the window elements travels back to the window manager, from here mLogger takes the user input and processes it.

Figure 4.2: mLogger UI Hierarchy.

How mLogger works

Figure 4.3: Basic overview of how mLogger works.

Macro expansion of logToPc:

Byte 1 - Start Byte($|0x80) - Most Significant Byte
Byte 2 - File Name Enum
Byte 3 - MSB of line number of file
Byte 4 - LSB of line number of file
Byte 5 - MSB of first variable
Byte 6 - LSB of first variable
Next two subsequent bytes are MSB and LSB of the subsequent variable
Last Byte - End Byte(';'|0x80) - Least Significant Byte

Macro expansion of mesToPc:

Byte 1 - Start Byte($|0x80) - Most Significant Byte
Byte 2 - Message ID Enum
Byte 3 - MSB of first variable
Byte 4 - LSB of first variable
Next two subsequent bytes are MSB and LSB of the subsequent variable
Last Byte - End Byte(';'|0x80) - Least Significant Byte

Widgets

Widgets are the only project-independent component of the mLogger. As discussed earlier, widgets can be programmed by the user so that the information transmitted by the microcontroller can be displayed in the Widget Window in any manner in real time, such as graphs/pictures or just plain text. This video (ADD LINK HERE LATER) demonstrates the use of a widget to display crucial data such as 3D orientation and states of vital sensors of an unmanned autonomous aircraft.

Ruleset

1. Message ID Enum

The source code must contain an enum named MESSAGE_ID_ENUM which contains file names for all files that are being logged and message ID names for all messages being passed to the widgets. Below is an example of the correct format that should be used:

 

 enum MESSAGE_ID_ENUM{
FILE_NAME_<file name 0>,
FILE_NAME_<file name 1>,
FILE_NAME_<file name 2>,
FILE_NAME_<file name 3>,
MESSAGE_ID_<Message ID name 0>,
MESSAGE_ID_<Message ID name 1>,
MESSAGE_ID_<Message ID name 2>,
};

 

This enum helps the mLogger interpret integers as file names and message ID's. This is how the mLogger identifies the file name or message ID.

2. File Name Macro

Each file in the source code must contain a macro for the file name on top of the file. This macro is not needed for mesToPc commands, therefore this rule is not required if you only plan to use mesToPc. The example below shows the correct format to be used. Note that the FILENAME macro is defined the same as the corresponding enumerator in MESSAGE_ID_ENUM.

 

#define FILENAME FILE_NAME_<file name>

 

3. logToPc Syntax

 

logToPc("<format>", <variables>); //must be written on a single line

 

Example:

 

int elevation = 10;
logToPc("Current elevation is %i meters.", elevation);

 

Output:

<MCU Port Log Window Line Number> <Time since port connected(ms)> <File Name> <Line Number> Current elevation is 10 meters.

Here is a list of valid format specifiers that can be used with logToPc:

 

The maximum size for any variable that can be displayed using logToPc cannot exceed 16 bits. In order to log 32 bit variables, we need to split it into two 16 bit parts. The code below shows an instance of how a 32 bit variable can be split so that it can be used with logToPc, we log the first 16 bits of the 32 bit variable "Value" followed by its last 16 bits:

 

logToPc("32 bit value: %x %x",Value >> 16, Value & 0xffff);

 

4. mesToPc Syntax

 

mesToPc("MESSAGEID<messageName>", <variables>); //must be written on a single line
Similar to logToPC, size of variables cannot exceed 16 bits. The same splitting method can be used for 32 bit variables.

 

Demo video