Menu

Support FAQ

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:

markdown img paste 20181121152240183

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 (markdown img paste 20181121154948678) 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:

markdown img paste 2018112116011573

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:

markdown img paste 20181121160838664

And when we check the log generated with the sections disabled:

Time Stamp  Motor Power 1   Motor Command 1 Battery Amps 1
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0
11/21/2018 4:03:51 PM   0   0   0

We get almost 30 samples per second. We can get even more if we increase the Baud settings of the controller, however the minimum time between samples will be 10ms (100Hz sample rate).

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. markdown img paste 20181121162234359
  4. And finally, paste your log (Ctrl+V)

markdown img paste 20181121161913240

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:

markdown img paste 20181121163527606

And Voila!

markdown img paste 20181121163722736

… 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”:

markdown img paste 20181121163934942

Click the Edit Button for the Horizontal Axis Labels:

markdown img paste 20181121164059760

And delete eveything in the Axis label range before clicking okay:

markdown img paste 20181121164217131

And we are left with a beautiful excel scatter plot:

markdown img paste 20181121164428205

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:

 py

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.

Safety is a critical concern in Mobile Robots. Serious injury to person and/or expensive material damage can occur if the robot and its load run out of control. Laser range finders, remote controls and other systems can be used to tell the robot to stop. The challenge is to make the robot always respond to the stop command. This is where Safe Torque Off – or STO – comes in.

STO is a safety mechanism for motor drives that reliably brings the motor to a no-torque state. STO is typically used for the prevention of an unexpected startup (EN 1037) of machinery or for an emergency stop, fulfilling stop category 0 (EN 60204-1).

 

sto

 

STO has the immediate effect that the drive cannot supply any torque-generating energy. STO can be used wherever the drive will be brought to a standstill in a sufficiently short time by the load torque or friction or where coasting down of the drive is not relevant to safety. In a Mobile Robot application, STO will stop motion in case of emergency, and prevent restart until it is safe to do so.

From this simple description, one can assume that STO is as simple as disconnecting power to the drive and motors. And indeed, STO can be achieved using a contactor that will cut the power to the motor controller, for example. However, using a contactor adds cost and components that can eventually go wrong.

STO must operate according to Safety Category 3 Performance Definition. To achieve Safety Category 3, according to EN ISO 13849-1, the controller must meet a list of several requirements. Of this list, the most challenging is that the STO must function even in the case of a single fault in any part of the system.

So, in the case of our earlier example, a single contactor cannot be use. At a minimum, two contactors are needed in series, so that energy can be cut from the motor in case one of the two contactors gets stuck.

 

Embedding STO in a Controller

All drive manufacturers are free to invent any method they wish if it meets the safety requirements. The most common implementation – and the one used by Roboteq, is to add a circuit that will cut off the power to MOSFET drivers. Without power, the drivers are not able to turn on any of the MOSFET’g gate.

Two switches in series are necessary to ensure that the power does get cut even if one of the switches is permanently ON because of failure.
Each of the switches is driven by a separate input, commonly labeled STO1 and STO2. In this manner, too, if one external or internal circuit is damaged and the respective STO command is stuck at the “ON” level, the other can still safely disconnect the power to the drivers.

 

Asset 1

 

The MCU monitors the STO input lines and the voltage to the MOSFET drivers. It is important to notice, however, that the STO circuit works independently of the controller’s MCU. It is therefore totally immune to any hardware malfunction.

The Safety Standard also requires that the drive be able to detect a failure in the STO circuit, and this can be quite challenging. Consider the example below.

STO1 and STO2 are active and both switches are On. But switch 1 is damaged and will remain ON even if the STO1 command is off. The drive appears to be operating normally. However, it is no longer as safe because it would not turn off if STO1 only is deactivated. It will still stop because STO1 and STO2 will be off. But if there is another fault in the system and should the STO2 command wire be stuck to a high voltage, the controller will not stop.

To alleviate these sort of problems, the controller incorporates additional circuitry for detecting and reporting that the STO circuit is fully functional.
The controller design is such that MCU can force either of both STO inputs to the OFF state. The MCU will use this capability to briefly turn off the MOSFET driver supply and verify that the driver supply voltage does in fact drops. This check is performed every time the controller is powered ON, as well as at periodic intervals.

Note that the MCU is not physically capable to force the STO inputs to the ON state. If it was, this could cause the STO circuit to cease protecting, in case the MCU is accidentally setting the outputs to 1 due to software of hardware malfunction.

Being a safety critical function that absolutely has to work in all situations, STO must be certified by a regulatory organization such as TUV. There, the examiner will simulate the failure of all critical components to verify that the drive can still safely be stopped.

STO is gradually being introduces in all Roboteq controllers, starting with the KBL1660. STO is scheduled to be available in all our products in 2019.

 

In most cases, Windows will generally automatically install the necessary DFU Drivers with the install of Roborun+.  However, in some cases the drivers are not installed automatically and must be installed manually in order to be able to update RoboteQ Firmware via USB.  Please perform the following steps to do this:

1) Navigate to the Console tab of Roborun+ and choose the option Update Driver Via USB.  The device will enter DFU Mode and lose connection with the Roborun+ Utility and the DFU Loader will open.  In the DFU Loader window you will notice that no DFU Devices will be detected:

Screenshot 1

 

 2)  Leave the DFU Loader open while navigating to your computers Device Manager.  On one of the ports you will see "STM Device in DFU Mode" with an exclamation point over the icon.  This is indicative of a missing driver:

dfu mode

 

3) Right click on this line and select Update Driver Software.  You will then select the option to Browse my computer for driver software:

Screenshot 2

4)  We have included the driver files in the Roborun+ program files.  Simply shoose Browse and navigate to the Roborun Plus program files folder (C:\ > Program Files (x86) > Roboteq > Roborun Plus):

Screenshot 3

 

After following these steps STM Device in DFU Mode should show in the DFU Loader and you will be able to complete the firmware update.

RoboCAN is a powerful networking protocol designed to allow RoboteQ products to easily communicate with one another.  However, it can be a bit confusing initially to new RoboteQ users or those unfamiliar with CAN.   Thus, the purpose of this brief article is to review the basics of RoboCAN and give a practical tutorial of networking to RoboteQ products together using RoboCAN.

 

RoboCAN Basics

RoboCAN is a proprietary networking protocol intended to interconnect and communicate between RoboteQ products specifically.  Note that the specifics of RoboCAN are described in more detail in our article, “RoboCAN:  A Simple Meshed Network,” as well as in Section 15 of our User Manual.  But for now, let’s just review some of the basics:

The RoboCAN network is generally set up in a Master – Slave configuration, where you have one RoboteQ device configured as the Master Node and then up to 125 Slave Nodes.  The bus will require that you connect CANL and CANH between all of the RoboteQ devices, and then use 120Ω termination resistors on each end of your bus.

CANnetwork

You can then send serial commands through your Master Node connected to a PC or Microcomputer via RS232 or USB, or you can have a MicroBasic script loaded to your Master Node that gives full automated control over the entire network.

 

Serial Runtime Commands/Queries

Serial commands are sent from your PC using the Roborun+ Console or a terminal program.  Serial commands can also be sent from a Micro or other hardware device via RS232 or USB to the Master Node.

Runtime Command

Syntax:  @id!cc ch vv

Where:

id is the remote Node Id in decimal

cc is the Command code, eg !G

ch is the channel number. Put 1 for commands that do not normally require a channel number

vv is the value

Example: 

@04!G 1 500

This will give a run command of 500 to motor channel one on the slave motor controller assigned as Node ID: 4.

 

Runtime Query

Syntax:  @id?cc ch vv

Where:

id is the remote Node Id in decimal

cc is the Command code, eg ?AI

ch is the channel number. Put 1 for commands that do not normally require a channel number

vv is the value Put 0 for queries that do not normally require a value

Example: 

@03?AI 2 0

This will read the analog input voltage of analog input 2 on the motor controller assigned to Node ID: 3.

 

MicroBasic Runtime Commands

 Commands and queries can also be sent from a MicroBasic Script running on the Master Node.

 

Runtime Command

Syntax:  SetCANCommand(id, cc, ch, vv)

Where:

id is the remote Node Id in decimal

cc is the Command code, eg _G

ch is the channel number. Put 1 for commands that do not normally require a channel number

vv is the value

Example:

SetCANCommand(04, _G, 1, 500)

This will apply 50% power to channel 1 of node 4.

For more details and examples of runtime commands/queries, as well as configuration commands and queries, please review Section 15 of our User Manual.

 

Practical Example Tutorial

Now that we are familiar with the syntax needed to communicate between devices on a RoboCAN network, let’s apply this knowledge in a simple practical example.  In this example we will simply connect a RoboteQ MDC2460 motor controller to a RIOX1216-AH IO Extender via CAN.  We will then configure the RIOX1216-AH as a Slave Node, and configure the MDC2460 as the Master Node.  Finally we will load a MicroBasic Script to the Master Node (MDC2460) that will turn on all of the Slave Node’s digital outputs in sequence, then turn them off in sequence in a loop.

 

Wiring

Wiring is simple in this case, since we are only connecting two devices to the bus.  We simply need to connect CANL of the MDC2460 to CANL of the RIOX, and then connect CANH of the MDC2460 to CANH of the RIOX.  Note that the CANL and CANH pins may not be the same on different models of RoboteQ devices.  Please refer to the product datasheet for the correct CAN pins of your device.

After connecting the CANL and CANH lines together we need to add the 120Ω termination resistor between them.  In this example we are using only two nodes, and our bus length is quite short, only ~2ft.  So, in this case only one termination resistor is necessary.  If you are using more nodes and have a longer bus it will be necessary to add a second termination resistor, one on each end of the BUS.

CAN1

In the end, our network wiring looks like this:

CANnetwork RIO

 

Configuration

Slave Configuration

Now we will configure our two devices.  First we will configure our RIOX1216-AH as a Slave Node.  This is done simply from the RIOX Configuration Utility.  We will set the CAN Mode:  RoboCAN, Node ID: 2, and Bit Rate: 250.  All other CAN settings besides these three will be irrelevant in RoboCAN.   After making these configuration changes, be sure to click “Save to Sensor” in order to save the new configuration settings to the RIOX.

 

RIOXCONFIG

Master Configuration

Next we will configure the MDC2460 as the Master Node.  This is done simply from the Roborun+ Configuration Utility.  We will set CAN Mode: RoboCAN, Node ID: 1 (master node),  and Bit Rate: 250.  Note that for sake of this tutorial we are using the bit rate 250.  In general you can use any of the available bit rates, you will just need to be sure that the same bit rate is configured to all nodes.  After changing these settings be sure to click “Save to Controller” in order to save the new settings.

MDC configuration

 

Confirm That Slave Is Present

After configuring both devices you will want to make sure that the Slave Node is present and ready to be instructed by the Master Node.  Make sure both devices are powered on and that they are connected via CAN.  At this point you only need to have your Master Node (MDC2460) connected to your PC via RS232 or USB. 

To confirm that the Slave Node (RIOX1216-AH) is present, open the Console tab of Roborun+.  From one of the Out Data lines send the query ?ICL 02.  ?ICL is the serial query syntax to check for the presense of any remote node, 02 of course is the node id we are checking.  After sending this query you will get one of two responses in the In Data window.  If you receive ICL = 1, then this means that the slave node is present and ready for commands.  If you receive ICL = 0, then your slave node is not present.

Node Present

Node Found  

Node Note Present

Node Not Found

If you do receive a response of ICL = 0 you will want to double check your wiring and configuration to make sure all is correct.   Additionally you can follow the Basic Setup and Troubleshooting instructions detailed on pages 152-153 of the User Manual.

 

Load MicroBasic Script to Master Node

After we have connected our two devices, configured them for RoboCAN, and confirmed that the Slave Node is present, we are ready to load a script to our Master Node to give commands to the Slave.  Again, we will be using a simple script that will send commands from the Master (MDC2460) to activate and deactivate the digital outputs in sequence on our Slave (RIOX1216-AH). 

Simply copy and paste the script below into the Scripting Tab of Roborun+:

 

' This script is provided "as-is", without warranty of any kind,
' expressed or implied, including but not limited to the warranties of
' merchatability, fitness for a particular purpose and
' noninfringemement. In no event shall Roboteq be liable for any claim,
' damages or other liability, arising from the use of the software"

' Sends RoboCAN commands in sequence to RIOX board configured as Slave Node.
' Activates Douts 1 - 8, holds then deactivates Douts 8 - 1 in a loop.


Print("Starting...") 'Prints verification in console that script has started

Top:

setCANcommand(02,_Dset, 0, 1) 'Enable RIOX Digital Output 1

wait(250) 'wait 250 milliseconds

setCANcommand(02,_DSET, 0, 2) 'Enable RIOX Digital Output 2

wait(250) 'wait 250 milliseconds

setCANcommand(02,_Dset, 0, 3) 'Enable RIOX Digital Output 3

wait(250) 'wait 250 milliseconds

setCANcommand(02,_Dset, 0, 4) 'Enable RIOX Digital Output 4

wait(250) 'wait 250 milliseconds

setCANcommand(02,_Dset, 0, 5) 'Enable RIOX Digital Output 5

wait(250) 'wait 250 milliseconds

setCANcommand(02,_Dset, 0, 6) 'Enable RIOX Digital Output 6

wait(250) 'wait 250 milliseconds

setCANcommand(02,_Dset, 0, 7) 'Enable RIOX Digital Output 7

wait(250) 'wait 250 milliseconds

setCANcommand(02,_Dset, 0, 8) 'Enable RIOX Digital Output 8

wait(500) 'wait 500 milliseconds


setCANcommand(02,_DRES, 0, 8) 'Disable RIOX Digital Output 8

wait(250) 'wait 250 milliseconds

setCANcommand(02,_DRES, 0, 7) 'Disable RIOX Digital Output 7

wait(250) 'wait 250 milliseconds

setCANcommand(02,_DRES, 0, 6) 'Disable RIOX Digital Output 6

wait(250) 'wait 250 milliseconds

setCANcommand(02,_DRES, 0, 5) 'Disable RIOX Digital Output 5

wait(250) 'wait 250 milliseconds


setCANcommand(02,_DRES, 0, 4) 'Disable RIOX Digital Output 4

wait(250) 'wait 250 milliseconds


setCANcommand(02,_DRES, 0, 3) 'Disable RIOX Digital Output 3

wait(250) 'wait 250 milliseconds


setCANcommand(02,_DRES, 0, 2) 'Disable RIOX Digital Output 2

wait(250) 'wait 250 milliseconds


setCANcommand(02,_DRES, 0, 1) 'Disable RIOX Digital Output 1

wait(500) 'wait 500 milliseconds

goto top 'Loop forever

 

After pasting the script click “To Device” to load the script to the motor controller.  After doing this you will simply need to click Run at the top of the Roborun+ window to start the script.  After starting the script, you will see the green LEDs relative to the RIOX1216-AH digital outputs illuminate in sequence, and then turn off in sequence.

 UZGG8420

It is simple as that!  You are now sending commands from your Master node to your Slave node over the CAN bus! 

 

Final Notes

This has been a very basic tutorial of communicating between two RoboteQ devices using RoboCAN.  However, you should now see how simple and strait forward RoboCAN is.  You can now begin experimenting with more nodes and more complicated tasks.  Adding more nodes is simple in that you will only need to assign them a different Node ID, and then refer to that respective node ID in your script or serial commands and queries.

xbot con rastrello21 sml
Robotic beach cleaner by Dronyx

 

Mixed Mode Steering, also known as tank style steering or skid steering, is easily achieved by selecting from a simple drop down menu in our dual channel controllers.  You can, however, still achieve this style of steering mode when using two single channel motor controllers connected to two individual motors.  Here's How:

 

Wiring The Controllers

First you will need two network your two single channel motor controllers together via RoboCAN.  If you are not yet familliar with RoboCAN please have a look at our article, RoboCAN:  A Simple Meshed Network, as well as our RoboCAN Practical Example FAQ Article.  Set your Master Controller to Node ID = 1, and your Slave Controller to Node ID = 2.

 Artboard 2

Configuring the Master Controller

After you have established your CAN connections between the two controller and configured them both for RoboCAN, you will now need to set up your command device on the Master Controller.  The MicroBasic script provided at the end of this script will allow you to give commands to your controller via an analog input source (such as an analog joystick), or via a pulse input source (such as an RC Remote).

 

If using an analog joystick, connect the two analog signal wires to analog inputs 1 and 2 respectively on your Master Controller.  Configure the Capture Type on these two inputs to "Absolute".  Setting the Input Use is not necessary.  Finally, you will want to calibrate both inputs.

 

If using an RC device, connect the two signals from your RC Receiver to pulse inputs 1 and 2 respectively on your mater controller.  Configure the Captrue Type on these inputs to "Pulse Width".  Again setting the Input Use is not necessary.  Finally, calibrate the two inputs.

 

MicroBasic Script

After configuring your input type copy and paste the MicroBasic Script below to the Scripting Tab of Roborun+.  As mentioned previously this script has two sections dependent on the command type you are using.  If using an RC device, uncomment the RC CONTROL section and comment out the ANALOG CONTROL section.  If you are using an analog device, you can leave the script as is.  You will then load the script to your Master controller. After you run the script in Roborun+ and confirm it works as expected, you can enable the script to autostart when the controller powers on.

 

' This script is provided "as-is", without warranty of any kind,
' expressed or implied, including but not limited to the warranties of
' merchatability, fitness for a particular purpose and
' noninfringemement. In no event shall Roboteq be liable for any claim,
' damages or other liability, arising from the use of the software.

Option Explicit
' Mixed mode using two separate controllers
' Script is written for use in any single channel controller.
' Script must be loaded and executed in controller that will serve as Master on a RoboCAN network.
' Second controller will act a Slave. Master node id=1, Slave node id=2
' Script is provided for demonstration purposes, as-is without warranty.
dim Pulse1Present as integer ' Raw pulse 1 value
dim Pulse2Present as integer ' Raw pulse 2 value
dim Throttle as integer ' Throttle Command
dim Steering as integer ' Seering Command
dim LeftMotor as integer ' Left Motor Command
dim RightMotor as integer ' Right Motor Command
dim CANAlive as integer ' Alive Robocan nodes
Top:
' Read list of alive RoboCAN nodes
CANAlive = getvalue(_ICL, 2)
'-------------------------------------RC CONTROL----------------------------------------
'Uncomment below to enable RC Command Mode
'Pulse1Present = getvalue(_PI, 1) ' Check if Radio is on by reading raw pulse value
'Pulse2Present = getvalue(_PI, 2)
'if (Pulse1Present > 0 and Pulse2Present > 0 and CANAlive > 0) ' Check that both channels have a signal and slave node is alive
'Capture RC joystick value after scaling and conversion
' Throttle = getvalue(_PIC, 1) ' Throttle on pulse input 1
' Steering = getvalue(_PIC, 2) ' Steering on pulse input 2
'else
' Throttle = 0 ' Radio if off, all commands at 0
' Steering = 0
'end if
'--------------------------------------------------------------------------------------------
'---------------------------ANALOG JOYSTICK CONTROL--------------------------------
' Uncomment below to enable Analog Command Mode
' WARNING there are no safety. If joystick is missing, motors will runaway
if (CANAlive > 1) ' Check that slave node is alive
Throttle = getvalue(_AIC, 1) ' Throttle on analog input 1
Steering = getvalue(_AIC, 2) ' Steering on analog input 2
else
Throttle = 0
Steering = 0
end if
' Compute Simple mixed mode algorithm
LeftMotor = Throttle + Steering
RightMotor = Throttle - Steering
' Cap commands to +/-1000
If LeftMotor > 1000 then LeftMotor = 1000
If LeftMotor < -1000 then LeftMotor = -1000
If RightMotor > 1000 then RightMotor = 1000
If RightMotor < -1000 then RightMotor = -1000
' Apply Left Command to local motors
SetCommand(_G, 1, LeftMotor) 'Send command to local motor ch1
'SetCommand(_G, 2, LeftMotor) 'Send command to local motor ch2
' Send Right Command to Slave, node 2 on RoboCAN network
SetCANCommand(2, _G, 1, RightMotor) 'Send command to slave motor ch1
'SetCANCommand(2, _G, 2, RightMotor) 'Send command to slave motor ch2
wait(10) ' Repeat loop every 10ms / 100Hz
goto top

 

Go to top