Menu

Support FAQ

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.

 

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

 

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.

When a motor is spinning faster than it would normally at the applied voltage, such as when moving downhill or decelerating, the motor acts like a generator. In such cases, the current will flow in the opposite direction, back to the power source.

It is therefore essential that the controller be connected to rechargeable batteries. If a power supply is used instead, the current will attempt to flow back in the power supply during regeneration, potentially damaging it and/or the controller.

Regeneration can also cause potential problems if the battery is disconnected while the motors are still spinning. In such a case, the energy generated by the motor will keep the controller On, and depending on the command level applied at that time, the regenerated current will attempt to flow back to the battery. Since none is present, the voltage will rise to potentially unsafe levels.

The oscilloscope capture below shows the voltage at the input of an SDC2160 controller connected to a power supply.

regen60V

When suddenly stopping a motor that was running at full speed, the voltage quickly rises from 24V to nearly 60V. The voltage could rise even higher under certain conditions. When the motor is finallly stopped, the voltage that accumulated in the controller's capacitors starts decaying.

The controller includes an overvoltage protection circuit to prevent damage to the output transistors. The oscilloscope capture below shows the voltage at the input of an SDC2160 controller connected to a power supply with the overvoltage protection set to 25V.

regen25V

The overvoltage protection circuit will cut off (float) the motor, quickly stopping the regeneration and voltage surge. Once the motor is floating, the voltage accumulated in the controller's capacitor will decay. When the voltage goes level below the overvoltage threshold, the transistors reactivate. If the motor is still spinning because of inertia, regeneration will resume and the voltage quickly rise again above the overvoltage limit. This cycle will continue until the motor has stopped. Because the power transistors disconnect, there is no braking taking place. The motors are freewheeling down.

If the motor inertia is very high, the voltage jump at the time the transistors turn back on can be very dangerously high. The overvoltage protection can therefore not entirely be depended upon to protect the controller and the power supply. This protection will work best when the overvoltage limit is set as close as possible above the supply voltage. For example 25V on a 24V supply system.

A safer technique and one that will cause the motor to brake instead of freewheeling is to place a resistive load in parallel with the power supply, with a circuit to enable that load during regeneration. This solution is more complex but will provide a safe path for the braking energy into a load designed to dissipate it. The diagram below shows an example of such a circuit.

regen protection circtuit

The controller must be configured so that its digital output is activated when an overvoltage condition is detected. The MOSFET and brake resistor value must be sized according to the expected regeneration current that must be absorbed.

The oscilloscope capture below shows the effect of this circtuit.

regen protected

With a resitor value of 1ohm, the power supply and regeneration voltage suddenly see a load of 25Amps, causing a rapid drop in voltage. The resistor is then quicly disconnected and the voltage rises as the controller's capacitors recharge. When the voltage rises again above the overvoltage threshold, the resistive load reconnects again, repeating the cycle until all the motor's kinetic energy is dissipated.

Go to top