Q- How to use logs for troubleshooting
Advanced Topics in Data Logging and Time Series Analysis
Monitoring the performance of a RoboteQ motor controller is essential to mastering the usage of our motor controllers. In this article, we will be demonstrating the advanced techniques that RoboteQ engineers use when setting up a motor controller, deploying a controller in a field application, or troubleshooting the performance of a motor control setup by datalogging and analyzing values.
Prerequisites
This article also assumes that you are familiar with general RoboteQ terminology, including our operating modes (Open Loop, Closed Loop, etc.) and some of the internal interfaces for commanding values from our motor controller (Motor Commands, Feedback Signal, etc.). If you are not familiar with any of these terms in the context of RoboteQ products, please consult our User Manual.
Open Loop Motors - a Quick Rundown
One of the first tasks that occur when connecting a controller to a motor is to ensure that the controller configuration is correct, and that all hardware connections to the motor are working. The first step is always to run the motor in Open Loop mode. From Page 86 our User Manual:
In [Open Loop] mode, the controller delivers an amount of power proportional to the command information. The actual motor speed is not measured.
The best way to think of Open Loop control is as a direct voltage control. The Motor Command issued to an Open Loop Motor channel, the supply voltage is proportionally applied to the motor output. The formula for this application is given as:
DPWM = .1% * Mc
Where DPWM is the output PWM signal duty cycle, or the Motor Power, and MC is the Motor Command. For practical purposes, you can think of the output duty cycle as the voltage output of the controller.
Note: Keep in mind that for Brushless and AC induction controllers, the output voltage is not a DC current. For Brushless controllers, it is commuted based on the controller’s Switching Mode. In an AC Induction controller, it is output as a 3 phase AC signal. However, in both of these controllers, the output is still in the form of a PWM signal, so the analogy still holds.
Therefore, when we drive a motor in Open Loop mode we want to make sure the following occurs:
- When we send the channel a Motor Command, the motor power quickly responds.
- That the Motor Power of the controller changes at a fixed ramping speed until it reaches the Motor Command value, and then it stays there.
- That, as the rotor of the motor applies torque, we see current drawn, or Motor Amps
Creating a Log
Using the Run Tab in Roborun+ we can log data values from the controller to ensure that the previous three conditions are occurring. This is the output of a Brushed Motor running in Open Loop Mode on an SDC2160:
Running this MicroBasic Snippet:
top:
setcommand(_G, 1, 1000)
wait(3000)
setcommand(_G, 1, 0)
wait(3000)
setcommand(_G, 1, -1000)
wait(3000)
setcommand(_G, 1, 0)
wait(3000)
goto top
Here it looks like our controller is achieving the first two parameters that we are looking for: it is accepting new Motor Commands and it is adjusting Motor Power correctly in Open Loop mode. However, by looking at the Run Tab graph, it would appear that the motor isn’t drawing current. Perhaps we should take a closer look at the Data…
Saving and Examining a Log
By hitting the save button ( 
) we can save a log of the actual samples that the run tab is using as a Tab column delimited, newline row delimited text file. For instance, here is an excerpt of a log saved of the above Dataset:
Time Stamp Motor Power 1 Motor Command 1 Battery Amps 1 11/21/2018 3:21:28 PM 0 0 0 11/21/2018 3:21:28 PM 0 0 0 [...] [...] 11/21/2018 3:21:29 PM 0 0 0 11/21/2018 3:21:29 PM 0 0 0 11/21/2018 3:21:29 PM 0 0 0 11/21/2018 3:21:30 PM 176 1000 0 11/21/2018 3:21:30 PM 376 1000 0.1 11/21/2018 3:21:30 PM 576 1000 0.2 11/21/2018 3:21:30 PM 776 1000 0.2 11/21/2018 3:21:30 PM 976 1000 0.2 11/21/2018 3:21:30 PM 1000 1000 0.1 11/21/2018 3:21:30 PM 1000 1000 0.1 11/21/2018 3:21:30 PM 1000 1000 0.1 11/21/2018 3:21:30 PM 1000 1000 0.1 11/21/2018 3:21:30 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1 11/21/2018 3:21:31 PM 1000 1000 0.1
Here we can see the raw values that the run tab has logged from the controller. Now it is clear - the motor was drawing current! Just not very much, since it was an unloaded motor.
When you save a log of the controller values, each sample is given it’s own time stamp, in the format of MM/DD/YYYY (H)H:MM:SS. Notice how their are currently 10 samples per second in the log. What if we want a higher resolution sample? What is preventing this? If we look at the Controller Log form the console tab, we get our answer:
The controller isn’t just debugging the values we want to log, it is also sending tons of other values, such as Analog Input values (AI) or the Pulse Input values (PI). These values debugs are actually what is going on under the hood to power the rest of the run tab status lights. We can disable it Using the checkmark boxes in each section:
Graphing a Log Using Excel
We have designed our data logs to be very accessible to tabular data programs. Using an external program it becomes very easy to exam our data using a program like Excel. For instance, let’s paste the contents of the first Open Loop log we generated into Excel:
1.First copy the contents of your motor log.
2.Then Highlight cell A1 in a blank Excel table:
3.
4.And finally, paste your log (Ctrl+V)
Excel is automatically able to parse the delimited data and separate each column into rows and columns. Make sure you have A1 highlighted when you paste, or it may not automatically parse the data correctly.
Once the data is in excel, we can take advantage of Excels rich graphing features, wich are far beyond the capabilities of the graph previewer that is included in the run tab of Roborun+. All we have to do is insert an XY scatter plot with our data selected:
And Voila!
… Or not. Excel had a little bit of trouble with the data selection. We have to help it out by deleting the range for our Horizontal Axis Labels. Just right click and choose “Select Data”:
Click the Edit Button for the Horizontal Axis Labels:
And delete eveything in the Axis label range before clicking okay:
And we are left with a beautiful excel scatter plot:
Ah, that’s much better.
Analyzing our Data with Python and NumPy
We can use other tools than Excel to manipulate our data. If we want to perform advanced analysis, importing the data to Python is not a bad idea. In Python we can use a variety of tools to manipulate and perform analysis on our motor logs.
Let’s import our motor logs into a NumPy array in Python. Here is a snippet that does that
import numpy
MotorData = np.genfromtxt('Brushed_OpenLoop.txt', skip_header = 1) #Skip data label headers
MotorData = MotorData[:, 3:] #skip time frame columns
Like Excel, NumPy will also automatically parse our data. In the above example, I also took the liberty of skipping the series label header (skip_header = 1) as well as stripping away the timestamps (MotorData[:, 3:]).
Once we have the data as a NumPy array, analysis becomes a breeze. For instance, sticking on the topic of plotting the data, we can use plot.ly to generate an interactive graph:
The sky is the limit when it comes to manipulating the data behind our motor logs and gaining insight about the performance of the RoboteQ motor controller. If you can’t perform some cool motor analysis using our data logging, drop This email address is being protected from spambots. You need JavaScript enabled to view it. an email and let us know.
