I'm sorry, but as a robot support technician, I'm not able to provide code or programming. However, you can use the ARC software to control your robot. ARC has a variety of robot skills that you can use to control your robot's movements, including the Auto Position robot skill for walking, gaits, and dancing.

For controlling motor speed and direction, you might find the HBridge PWM robot skill useful. This skill can control the speed and direction of motors.

As for reading the encoder, you might want to look into the ADC (Analog to Digital Converter) robot skill. This skill can read voltages into the EZ-B Robot Controller, which might be useful for reading encoder data.

Remember, there is no robot API or SDK. All programming must be done through ARC. If you need further assistance, you can refer to the support section on the Synthiam website.

Do you have a data sheet for the protocol?

Yes I do. It is fully detailed in the Roboclaw user manual: https://downloads.basicmicro.com/docs/roboclaw_user_manual.pdf

I think having a skill(s) that can support this would be a big addition to the ARC functionality. To be able to add gear motor contols thru a popular motor controller plus having easy servo controls would be fantastic.

I think this would be nice. Since the Roboclaw has a PID calibration feature, I would find reading/writing more serial info a plus when it comes to making sure left/right drive motors are more in sync with each other when it comes to going in a straight line. Just my thoughts :)

DJ I tried to compile your ESP32 DOIT DevKit v1 Version 3 and got a compile error:

C:\Users\jsale\Downloads\EZ-ESP32\EZ-ESP32\EZ-ESP32.ino: In function 'void doEZProtocol()': C:\Users\jsale\Downloads\EZ-ESP32\EZ-ESP32\EZ-ESP32.ino:591:72: error: call of overloaded 'analogWrite(byte, long int)' is ambiguous analogWrite(translateaDigitalPort(port), map(pos, 0, 100, 0, 255)); ^ In file included from C:\Users\jsale\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.11\cores\esp32/Arduino.h:36, from C:\Users\jsale\AppData\Local\Temp\arduino\sketches\CDE5C4BB246CA7756BE71CCDDE855B8B\sketch\EZ-ESP32.ino.cpp:1: C:\Users\jsale\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.11\cores\esp32/esp32-hal.h:98:6: note: candidate: 'void analogWrite(uint8_t, int)' void analogWrite(uint8_t pin, int value); ^~~~~~~~~~~ In file included from C:\Users\jsale\Downloads\EZ-ESP32\EZ-ESP32\EZ-ESP32.ino:9: C:\Users\jsale\Downloads\EZ-ESP32\EZ-ESP32\analogWrite.h:9:8: note: candidate: 'void analogWrite(uint8_t, uint16_t)' void analogWrite( uint8_t APin, uint16_t AValue ); ^~~~~~~~~~~

exit status 1

Compilation error: call of overloaded 'analogWrite(byte, long int)' is ambiguous

Is there a newer version I should be using?

I figured it out.  The parameters for analogWrite were passed via other functions, and those functions had different return values defined.  I simply added a cast to each function return.

Was: analogWrite( translateaDigitalPort(port),  map(pos, 0, 100, 0, 255)); Now : analogWrite((uint8_t) translateaDigitalPort(port), (uint16_t) map(pos, 0, 100, 0, 255));

Ah yes, i was about to reply with that advice. There are several versions of Arduino IDE with various compiler inconsistencies. This is one of those - because it works on some but not others. Awesome you got it figured out :)

Well DJ, I’m a little disappointed. Since Python is an interpretive language, I thought the Python script in ARC would simply pass the code to the interpreter. But apparently not, since I can’t seem to be able to use Motion Control’s Python library to do the packet serial communications with the Roboclaw Solo 30A. When I call functions from MC’s Python library in ARC I get invalid syntax errors.

Unless I’m missing something (which could very well be), I am going to have to modify your ESP32 firmware to use MC’s Python library and see about creating code in ARC that will execute functions in the ESP32 firmware. Not exactly what I wanted to do.

Or maybe I’ll just have to write ARC script code to do the packet serial CRC calculations and protocol to the serial write/read commands.

The python interpreter does get the python code as entered. Including any libraries added to it.

Make sure their library works - or you know how to use it. Because it could have some gotchas. The library could also have dependencies of other libraries etc etc

Interesting... it seems this motor controller uses the same protocol as the Sabertooth if it is in "Standard Serial" mode. Have you considered putting it in that mode and using the sabertooth movement panel?

Problem is with standard serial, Roboclaw only receives data, it does not transmit. To get encoder readings I need two-way serial, which Roboclaw does with the Packet Serial.

Also, I don’t seem to have the Roboclaw Python library installed correctly (which is what you had suggested). I tried to write/run Python code with Roboclaw classes directly (via Windows cmd window instead of ARC) and am having issues.

I think using a robot skill made natively for this controller is the best idea. That way you’re removing extra layers of abstraction. I can check if there’s a c# library because that would be easiest.

what are you wanting from the encoder values? To use the better navigator with nms? Or do you have other plans?

im asking because I’d like to know what features the robot skill needs

BasicMicro does supply a C# library for their motor controllers, and I was thinking about using that. I am a C programmer by profession (30+ years) so it was my first choice. I tried creating a linked in library of functions for doing Alexa voice interface, and ran into troubles getting the C functions I wrote to work in ARC. But that was an early attempt a couple of years ago, and I have yet to re-visit that.
This time around on my attempts to interface with ARC, I decided to look into Python, since both ARC and the Roboclaw motor controller support Python. But of course, linked in C# functions would be much more efficient and execute faster.

So what I am using this for is the waist motor in a full sized Lost in Space Robot (B9). I want to have unlimited rotations in both directions, with speed control, and need to know exactly which way the torso is facing at any given time. I have a slip ring in the center so I don’t have to worry about twisting the wires around.

I’m trying to get my robot to be as fully autonomous as I possibly can, with voice controls. So if I tell the robot to face forward it will know exactly which is the shortest path to do that. And if for some reason it is to act like it confused, it could spin around in circles for 5-10 rotations and still figure out how to get back to facing forward. Maybe even recognize which way a voice is coming from and turn to face that person. The more actuate positioning it has the more thinks I can program it to do.

@Jsale, I'm a Sabertooth/Kangaroo guy and don't know a lot about Roboclaw. I did at one time consider using the roboclaw but thought the ST/Roo was better for my needs in my B9 robot. I am wondering, does the Roboclaw controller (along with the ability to give you direction and speed) have the ability to give you precise position command?  I see the Roboclaw does support encoders but I don't see anything about switches. I would think for position control you would need some kind of switch to home to so the controller knows where the motor is.

@Dave Schulpius, Yes it does. You can read the current position, move to a specific position, reset the encoder, set the encoder to a specific value, and much more. And the Roboclaw has settings to allow for range limits (via switches which is what I use in the arms), and homing switch (although I have yet to get that to work; might be switch problem, not sure yet).

And you can even move to a specific position at a current speed with a specified acceleration and deceleration, in just one command.

I was using the Sabertooth/Kangaroo setup like yours, but I had trouble getting it to work consistently. Plus I wanted unlimited number of turns for the waist and radar. So I switched to Roboclaw in the arms and decided to use one in the waist. If I can get this to work, I might swap out the Sabertooth/Kangaroo in the radar as well.

Nice! I'd love to see it all.

@DJSures, I think I'm over my head with this. I might be a professional C programmer, but when it comes to C++ or C# and IDEs, I have no clue. I tried following the steps on systhiam.com to create a skill using Visual Studio, and I "think" I got the RoboClaw C# library added to the project, but I have no idea how to call the RoboClaw functions (or methods in object-oriented speak) within EZ-script. Is there any chance you could give me a few pointers on doing this? I just need to execute a half-dozen or so of the functions in the RoboClaw library to do what I want with my waist motor. I know you can't possible teach me C#, but some of the basics it getting at least one function to work would be of great help.

Sure I can give it a quick look and make a template for you. Just to clarify, you would like a dc motor to be used like a servo by having an encoder on it?

Im using the Roboclaw on my REMI robot, They also provide an app to help setup things like communication type and motor calibration. The motors I use have built in encoders and use a small pvb to route the wires proper between motor and controller. One feature on the app, is being able to calibrate motors via PIV/PID and you can then save the results. Because the Sabertooth plug-in is setup for Simple serial mode, I had decided to use of the recommended calibration methods to make sure both motors run same rpm for a "straight line" when moving forward. Its not perfect, I do se it deveate a little bit.  I believe having bidirectional communication between the Roboclaw and a UART on the EZB ( and proper plug-in) would be helpful at reading the encoders in realtime and adjust the rpms to allow for a straight line when driving forard.

@DJSures, not exactly on getting a dc motor to be used like a server. More like sending the serial packet data to the Roboclaw motor controller using their CRC check. What I’m trying to do is use ARC to send Roboclaw packet serial commands (with CRC) to an ESP32 board which has its UART connected to a RoboClaw Solo30A motor controller. And since BasicMicro has a C# library with methods that execute all of their packet serial commands, it seems that it would be a nice addition to ARC to include this capability.

Unfortunately BasicMicro does not give any examples of using their C# library, nor does the code have any comments describing what the functions do. They do give examples of using their Python library, and have more documentation on it. I have sent a request to BasicMicro to see if they have some documentation or examples for their C# library, and I’m waiting for their response.

What I need (after initializing/setup of the Roboclaw object) is to be able to a call RoboClaw method from an EZB-script. If I can figure that out (with your help), I should be able to call any of the 50+ methods in the C# library to do a variety of things with a dc gear motor that has an encoder (like read the encoder value, move to a specific encoder value, reset the encoder value, and so on). Of course it won’t be as simple as that, as the Roboclaw C# library needs to be initialized, which includes internal setup of the UART.

I’m sure this is the most complicated way to do this. The other 2 ways I would think would be easier (Python code in ARC that uses Roboclaw’s Python library or use Roboclaw’s Arduino library on the ESP32), but I would think the C# library would be much more efficient in processing.

Any help I can get on this would be greatly appreciated. Maybe if I can get this to work I will try to develop an ARC skill that can access a lot of the Roboclaw controller features. Although a skill might not be the best solution since there are over 50 commands for the Roboclaw. Maybe a set of skills would be better.

It sounds like you want the dc motor to behave like a servo. So you can specify what position the dc motor will move to. I don’t see any other way to control position of a dc motor than have it behave like a servo. Your description is how a servo operates. You specify a position, and for dc motor in the servo moves the output shaft to the desired position. Using an encoder is necessary for this to happen.

so the robot skill merely needs to read the position and map it to an ARC servo. That way any robot skill could move the dc motor to specified position.

So today when I opened my C# project in Visual Studio it could not find the ARC and EZB modules. So I’ve given up for now on trying to develop using C# and building a skill.

This weekend I will try building code on the ESP32 with the BasicMicro Arduino code. If I can get that to work, then I will see what it takes to get ARC to send commands to the ESP32 to execute the Roboclaw protocol functions.

Looks like i can whip something up pretty quick to give you as a template. Are you having the roboclaw motor controller connected directly to the computer via USB? That looks ideal for the SDK. It appears the SDK prefers that. Otherwise, if you want it over serial, that can be done, too. But one or the other...

I need serial communications from ESP32 and Roboclaw as I don't have USB access in that part of the robot.  Using WiFi between ARC and ESP32.

Okay - i'll take a look at the library and make something for you. Stay tuned

Looking forward to seeing it and learning from what you do.  Thank you very much !

Ugh, I'm torn on how to implement this with the least effort. They could have done a better job at providing libraries for serial and USB together. You see, the Arduino library is the only one that does serial communication to the roboclaw. The Python and c# libraries use USB, not serial/uart. It appears that they were expecting you to only communicate via serial if using an Arduino. But if you're limited only to Arduino, the robot cannot do much unless you use the Arduino as an intermediate controller between the RobotClaw and EZB/PC.

C# Library -> USB Python Library -> USB Arduino Library -> Serial/UART

The dilemma I'm up against is that if I spend a bunch of time implementing a robot skill for USB, then it'll require twice as much effort to implement the UART version on top of that. So, I need to figure out a few things without spending too much time on it.

Even loading the Python library into ARC won't work because you'll still be limited to a USB connection.

Okay, I have a proposed solution for separating communication ability between the libraries that causes a disconnect of limiting USB and Serial connectivity together. The only library that seems easiest to manipulate is the Arduino library. I will port the C++ Arduino library to c# and create a dynamic class using a communication stream.

The stream could then be assigned to a serial/usb or ezb uart. That way, it'll be dynamic for either communication type. And because of that, we'll be able to create robot skills using the available commands in the library. I also have a new ControlCommand utility that generates commands based on public methods of a class. So we can have the entire new roboclaw library available as a ControlCommand to experiment with. That will provide enough flexibility to understand the commands necessary to build a robot skill that does what you want.

C++ and C# are close enough that it doesn't take too long. The challenge is that enums are referenced differently, so that's a lot of copying and pasting. Also, variable types are different as well. And small formatting things, precisely variable arguments for methods.

That sounds like a fantastic solution! I can’t wait to see it in action. I did not realize the C# and Python libraries were limited to USB. That’s really limited and would not work in my case since I don’t have USB available in the robot’s waist. I hope it doesn't take up too much of your time, but I sure there are a lot of people who would benefit from this work. Having another motor controller (especially as powerful as the RoboClaws) is a great addition to ARC.

In the meantime, I have a working Arduino library version running on the ESP32 board. The difference is that I use the ARC software to send serial text commands to the ESP32, which then reads the command (and any parameters needed) and then calls the RoboClaw Arduino functions which then send the serial command to the motor controller. There is no c# code on the ARC side to build skills with. So it is harder to be able to provide it to others (since it is a modified version of your ESP32/EZB firmware, also limits it to ESP32 cards).

Your version would be a more efficient way to go, plus being able to build robot skills for others to use is great.

@DJSures, How's the Roboclaw port coming along?  Is this going to require an ARC update?

Should have something soon. Because I’m approaching this skill a bit differently, it’s dependent on something we had been working on for the ControlCommand() engine. It’s going to expose their library methods so you can use what’s needed.

We have another ARC update with new stuff in a few days that’s dependent on it as well.

@DJSures, I'm curioius as to how the Roboclaw port coming along? I'm thinking of using a second one in my B9 robot, that's why I'm asking. I'm not trying to add presure to you or your team, just wondering. This second Roboclaw setup would replace the Sabertooth/Kangaroo setup I currently have, which is troublesome and limited in the number of turns I can do.

Ah, apologies for dropping the ball on this one. I overcommitted and won't be able to complete this until most likely after the new ARC24 ARC/2 ARC.2 is released. Geez, we have to agree on a name soon! No one knows what to call it. But the new ARC will make implementing things like this much more manageable. The time frame for the new ARC is sometime in the new year. Albeit, porting the 700+ robot skills over will take a bit of time as well :)

I have a template project that I started on a while ago. I'll attach it here once I get in front of that laptop. I'm on a different PC right now.

@DJSures, Your last comment (Dec) mentioned that you were going to attach a template project file to the comment, but I don't see the attachment. Also, any update to when the Roboclaw port will be available?

Ah, crazy, I had the temp skill I was working on on my desktop in the fall - it looks like I deleted it at some point. If I come across it and I didn't delete it, I'll post it. But in the meantime, I'm swamped with ARCx development and don't have time for volunteer development. Your best bet is to tackle a robot skill. I'll try to answer questions, but I don't have much free time.

Oh, or you can reach out to the manufacturer of that product and ask them to contribute a robot skill - that's how they usually get created.

Looking at it real quick again to refresh my memory. I came across this 9-year-old driver that someone was working on for Python. It seems like the cleanest version of any examples I've seen using that product. I don't know why they made it so complicated and the driver so hard to use. I guess that's why it's such a rare device.

Here's the link: github.com/sonyccd/roboclaw_ros/blob/master/roboclaw_node/src/roboclaw_driver/roboclaw_driver.py

I asked gpt4 to convert that python and got this bit to test with...

using System;
using System.IO.Ports;
using System.Threading;

public class RoboController
{
    private SerialPort _port;
    private ushort _crc;
    private const int TrysTimeout = 3;

    // Enum for commands
    public enum Cmd
    {
        M1FORWARD = 0,
        M1BACKWARD = 1,
        SETMINMB = 2,
        SETMAXMB = 3,
        // Add all other commands here...
        GETPWMMODE = 149,
        FLAGBOOTLOADER = 255
    }

    // Constructor to open serial port
    public RoboController(string portName, int baudRate)
    {
        _port = new SerialPort(portName, baudRate);
        _port.Open();
    }

    // CRC calculation method
    private void CrcClear()
    {
        _crc = 0;
    }

    private void CrcUpdate(byte data)
    {
        _crc ^= (ushort)(data << 8);
        for (int i = 0; i < 8; i++)
        {
            if ((_crc & 0x8000) == 0x8000)
                _crc = (ushort)((_crc << 1) ^ 0x1021);
            else
                _crc <<= 1;
        }
    }

    // Example of sending a command
    private void SendCommand(byte address, Cmd command)
    {
        CrcClear();
        CrcUpdate(address);
        _port.Write(new byte[] { address }, 0, 1);
        CrcUpdate((byte)command);
        _port.Write(new byte[] { (byte)command }, 0, 1);
    }

    // Example command functions
    public bool ForwardM1(byte address, byte value)
    {
        try
        {
            SendCommand(address, Cmd.M1FORWARD);
            WriteByte(value);
            // Additional logic to handle command response and verification
            return true;
        }
        catch (Exception)
        {
            return false;
        }
    }

    private void WriteByte(byte val)
    {
        CrcUpdate(val);
        _port.Write(new byte[] { val }, 0, 1);
    }

    // Add other methods similar to the Python script for command handling and data reading

    // Close the port
    public void Close()
    {
        if (_port != null && _port.IsOpen)
            _port.Close();
    }

    // Main method for testing
    public static void Main(string[] args)
    {
        // Example usage
        RoboController controller = new RoboController("COM3", 38400);
        controller.ForwardM1(0x80, 0x64); // Example call
        controller.Close();
    }
}

And a few more tips - this will be super helpful. The template for the Sabertooth Kangaroo Movement Panel will provide a skeleton to drop in the commands from the robot claw.

Using that above conversion as a library to stub into the sabertooth serial class should provide movement quickly.

Here's the sabertooth mvoement panel source: Sabertooth Kangaroo Movement Panel.zip

Okay, I just spent the last hour after dinner staring at that Python script, and I take it back. It's probably the worst code I've ever seen in my life. There are 10-20 duplicate functions for every function. For some reason, the author copied functions repeatedly and gave them new names with the same code inside.

Everything about the roboclaw is poorly supported. I don't know what to tell you, but we understand why no one uses it. If you want to help that company by cleaning their code and making something work, my above example should do that. But it's going to be a HUGE job for you.

Here this should work as it's mostly complete...

using System.IO.Ports;

public class RoboClaw : IDisposable {

  private SerialPort _serialPort;
  private const byte Address = 0x80; // Default address, adjust as needed

  public RoboClaw(string portName, int baudRate = 38400) {

    _serialPort = new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One);
    _serialPort.Open();
  }

  public void Dispose() {

    if (_serialPort.IsOpen)
      _serialPort.Close();
  }

  private ushort UpdateCrc(ushort crc, byte data) {

    crc ^= (ushort)(data << 8);

    for (int i = 0; i < 8; i++) {

      if ((crc & 0x8000) != 0)
        crc = (ushort)((crc << 1) ^ 0x1021);
      else
        crc <<= 1;
    }

    return crc;
  }

  private ushort calculateCrc(byte[] data) {

    ushort crc = 0;

    foreach (byte datum in data) {
      crc = UpdateCrc(crc, datum);
    }

    return crc;
  }

  private void sendCommand(byte command, byte[] data = null) {

    int dataLength = data != null ? data.Length : 0;
    byte[] buffer = new byte[1 + dataLength + 2]; // Address + Data + CRC
    int index = 0;

    buffer[index++] = Address;

    buffer[index++] = command;

    if (data != null) {
      Array.Copy(data, 0, buffer, index, dataLength);
    }

    ushort crc = calculateCrc(buffer[..(1 + dataLength)]);
    buffer[^2] = (byte)(crc >> 8);
    buffer[^1] = (byte)(crc & 0xFF);

    _serialPort.Write(buffer, 0, buffer.Length);
  }

  private byte[] readResponse(int size) {

    byte[] buffer = new byte[size + 2]; // Data + CRC
    int bytesRead = _serialPort.Read(buffer, 0, buffer.Length);

    if (bytesRead != buffer.Length) {
      throw new InvalidOperationException("Failed to read all bytes from RoboClaw");
    }

    // Verify CRC
    ushort calculatedCrc = calculateCrc(buffer[..^2]);
    ushort receivedCrc = (ushort)((buffer[^2] << 8) | buffer[^1]);

    if (calculatedCrc != receivedCrc) {
      throw new InvalidOperationException("CRC mismatch");
    }

    Array.Resize(ref buffer, buffer.Length - 2); // Remove CRC from the response

    return buffer;
  }

  public void ForwardM1(byte speed) {

    sendCommand(0, new byte[] { speed });
  }

  public void Close() {

    if (_serialPort != null && _serialPort.IsOpen) {
      _serialPort.Close();
    }
  }

  public void ForwardM1(int speed) {

    sendCommand(0, new byte[] { (byte)speed });
  }

  public void ForwardM2(int speed) {

    sendCommand(4, new byte[] { (byte)speed });
  }

  public void SetMaxCurrent(byte motor, uint current) {

    byte command = (byte)(motor == 1 ? 133 : 134);
    byte[] data = BitConverter.GetBytes(current);

    sendCommand(command, data);
  }

  public uint GetMaxCurrent(byte motor) {

    byte command = (byte)(motor == 1 ? 135 : 136);

    sendCommand(command);

    var data = readResponse(4);

    return BitConverter.ToUInt32(data, 0);
  }

  public long GetEncoderCount(byte motor) {

    byte command = (byte)(motor == 1 ? 16 : 17);

    sendCommand(command);

    var data = readResponse(4);

    return BitConverter.ToInt32(data, 0);
  }

  public void SetBatteryVoltages(float minVoltage, float maxVoltage) {

    byte[] minVoltageData = BitConverter.GetBytes((ushort)(minVoltage * 10));
    byte[] maxVoltageData = BitConverter.GetBytes((ushort)(maxVoltage * 10));

    sendCommand(57, minVoltageData);

    sendCommand(58, maxVoltageData);
  }

  public (float, float) GetBatteryVoltages() {

    sendCommand(24); // Get main battery voltage command
    var mainVoltageData = readResponse(2);
    float mainVoltage = BitConverter.ToUInt16(mainVoltageData, 0) / 10f;

    sendCommand(25); // Get logic battery voltage command
    var logicVoltageData = readResponse(2);
    float logicVoltage = BitConverter.ToUInt16(logicVoltageData, 0) / 10f;

    return (mainVoltage, logicVoltage);
  }

  public void SetSpeedAccel(byte motor, uint accel, int speed) {

    byte command = (byte)(motor == 1 ? 38 : 39);
    byte[] data = new byte[8];

    Array.Copy(BitConverter.GetBytes(accel), 0, data, 0, 4);
    Array.Copy(BitConverter.GetBytes(speed), 0, data, 4, 4);

    sendCommand(command, data);
  }
}

@DJ Sures, I'll give it another try at doing a skill. Is this code mostly C++? I know the Roboclaw library was C#, which I have no experience with, but I have done some limited C++ coding.

Oh, it's all C#

I'm pretty sure that the last code snippet should work. If you can get a robot skill compiling with a simple button, I can talk you through how to test it.

All we really need to debug is add a button, and we'll see if we can make that button do different stuff, haha. one test at a time :)

@DJ Sures, it has been awhile since we last discussed the Roboclaw library. While I was waiting for Synthiam to add the Roboclaw library to ARC, I developed a solution with a modified version of the ESP32 firmware that works with the ESP32 DOIT DevKit. Once you informed me that Synthiam was not going to add support for Roboclaw in ARC, I decided to just use my solution (instead of building a plug-in for Roboclaw). So then I needed a second ESP32 unit and went with a ESPRESSIF ESP32 WROOM 32 board (got two for price of one ESP32 DOIT). The pin documentaion for that board shows RXDO is pin 34, GPI03, and for TXDO pin 35, GPIO1. So in the firmware I changed the translateDigitalPort() function so that the ARC port 13 (which I believe is the UART0 RX on an EZB board) to return a value of 3, and for ARC port 12 (EZB UART0 TX) to return a value of 1. But I am not getting anything from the serial port. Have you used ESP32 WROOM 32 boards, or know anyone who has? This seems to be a very straight forward port from ESP32 DOIT to ESP32 WROOM 32 (just change the pins for RX/TX), but it just does not work.