@DJSures it has been awhile since we discussed my attempt to use Roboclaw library with ESP32 and ARC. But I have made some progress (not real clean, but it does what I need). But now I'm trying to send data from the Roboclaw back to ARC, and can't seem to get the serial comms to work from the ESP32 to ARC. On the ARC side, I have the following EZ-Script code:

$Getbuf = " " #parms: EZB boardindex, UART, RoboClaw CMD UARTWrite(0, 0, $ReadEncoder) #Roboclaw read encoder value

sleep(3000) $x = UartAvailable(0, 0) print("bytes available: " + $x)

This sends a command (ReadEncoder) to the ESP32, sleeps, and then attempts to read data from the ESP32. The ESP32 which correctly recognizes the command it recieved, and then executes the following code on the ESP32:

   char roboCmd       = ' ';
   uint32_t position  = 0;
   roboCmd = ReadByte();
   switch (roboCmd)
   {
   case ReadEncoder:
      position = roboclaw.ReadEncM2(0x80);
      Serial.print("Reading encoder value:");
      Serial.println(position);
      Write32(position);
      break;    

On the Arduino IDE, I can see that the correct value of the encoder is returned, so I know that worked (17:29:19.481 -> Reading encoder value:1125). But on the ARC side, the UartAvailable turns 0 number of bytes in the buffer.
Is there some other function besides Write32() I should be using on the ESP32 side to send data back to the ARC?

Are you initializing the uart in your script? There does not seem to be an Initialization command in the script you provided. However, one is needed to configure the uart for correct parameters and baudrate.

Yes I initialized the UART.  I do not have all the code shown, it is way too much to post.  As I mentioned, sending data from ARC to ESP32 via the UART is working.  I am having trouble sending from ESP32 to ARC.

Try this: https://synthiam.com/Community/Questions/Connecting-EZ-B-or-IoTiny-to-Arduino-19184

There’s a comment on #5 that should be useful

I have not yet figured out what my problem is. Does the ESP32 WiFi use UART0, or does it have it's own buffers/functions to do communications with ARC? If it has its own, what do I need to do on ARC to read the data coming from the ESP32 WiFi?

Wifi? Hmm I'm missing something in what you're proposing. Can you describe how you have this setup? Like, how the wire are, or wifi, or what ever. Because UART is not wifi, so I'm missing something. Or even a diagram I guess is useful :)

@DJSures So ARC communicates with ESP32 (EZB) via WiFi. In ARC, I send a command via UARTWrite() using Uart0. This is sent via wifi to the ESP32, which reads the command (one byte code sent via the UARTWrite), the command is ReadEncoder. On the ESP32 firmware I've added reading that one byte command (ReadEncoder) and it then executes the RoboClaw C++ library command roboclaw.ReadEncM2 (which returns the encoder reading for Motor 2) and then I execute COMMUNICATION_PORT.Write (encoder reading) to send the value back to ARC. On the ARC side, I then execute:

$x = UartAvailable($HeadPort, 0) print("Bytes in buffer: " + $x)

and that returns either 0, or some large (invalid) number, like 4000. Mostly it returns 0.

So the "from ARC to ESP32" wifi works, but it does not seem like the "from ESP32 to ARC" works. I assume it works on the initial log-in, as I think the ARC software is expecting the ESP32 (EBZ) to send back the "Capability Controler" (222 for ESP32) and the firmware ID, and since it connects with no problems, I assume ESP32 is doing that.

So I don't understand why I can't send data back to ARC.

Ah i see, so the ESP32 has EZB firmware on it?

Yes, your firmware Version 3 (2/5/2021).

Can you share your modified esp32 firmware code?

Also I can’t quite understand the ezscript code you posted. I’m going to switch you to JavaScript or Python because ezscript is broken and being deprecated.

Here's a zip file of the ESP32 code:

EZ_ESP32_Head.zip

and here's the EZ-script:

UARTWrite($HeadPort, 0, $ReadEncoder)       #Roboclaw read encoder value

sleep(500) $x = UartAvailable($HeadPort, 0)

print("Bytes in buffer: " + $x)

And, by the way, I hate the editor on this forum.

I switched to JavaScript, and it worked.  So the problem was on the ARC side with EZB-script.  Guess I'm changing ALL of my code to JavaScript.  One step forward, 100 backwards :)

well done!

Congrats @JSale!. I know that's a good feeling.

I've been spending the past month or so learning Javascript and rewriting all my scripts for my Lost in Space B9 robot. It was painful at first but with some help from DJ and Athena along with a lot of research and reading, trial and error I'm managing to do it. I can't believe how many scripts I had to do but I'm getting close to finishing. I'm really happy I did it and love the performance boost. It also gave me a reason to clean out old scripts and refine most of the others. I'm sure they aren't up to professional script writing standards but they look and run a lot better then my EZ Scripts did.

How's your B9 build coming along? I haven't heard from you in a while.

Happy building!

Well I spoke too soon. Yes, I finally got data back on the ARC side, but now the ESP32 side for some reason is looping trying to read data that I don't thing is there. Don't know why it is even attempting to read data. So, more work to do.

@Dave Schulpius, have not move forward much on the B9, as I have been stuck trying to get the coding for the ESP32s working. I am using two ESP32s in the B9 to control the waist and head rotations. The setup I had before worked more like a servo, which did not allow me to spin the head/waist around without limitations. With the ESP32 and a magnetic sensor to home on, I am getting close to achieving full, continuous rotation. I am also using RoboClaw motor controllers so I can get exact position readings, which is what I am having the issue with right now. And like you, I'm going to be switching all my code from EZB-script to javascript. I might have to hit you up for help!

You're trying to put code in the

    } else if (cmd2 == CmdV4UARTExpansion0Write) {

But to do that, you'll have to understand how that is working...

For example, the roboCmd in this snipet of code is actually the "length of bytes" according to the protocol document.

  } else if (cmd2 == CmdV4UARTExpansion0Write) {

    ...
    roboCmd = ReadByte();
    ...
  } 

Here's the protocol details: synthiam.com/Support/EZB-Firmware/communication-protocol

And here's how you can optionally extend it - but your way "will work" if you're not doing anything else with the uart and saves u from having to create a robot skill I guess: synthiam.com/Support/EZB-Firmware/extend-ezb-protocol

That's what I was missing.  I think I need to go with extending the EZB protocol on my ESP32 firmware.  I'll start looking at that. Thanks.

@Jsale, 

Quote:

And like you, I'm going to be switching all my code from EZB-script to javascript. I might have to hit you up for help!

Good luck and have fun!!

Okay, if you're going to do that - let me know if you want any hints or tips. Here's pretty much what you'll do... (I don't want to take the fun away hehe)

1. Create a robot skill. And based on what features you want to support, at least you'd need to subscribe to the ServoMove event. Otherwise, your Form Load and Close will look like this...

    private void Form1_Load(object sender, EventArgs e) {

      // Bind to the events for moving a servo and changing the connection state
      EZBManager.EZBs[0].Servo.OnServoMove += Servo_OnServoMove;
      EZBManager.EZBs[0].Servo.OnServoRelease += Servo_OnServoRelease;
      EZBManager.EZBs[0].Servo.OnServoSpeed += Servo_OnServoSpeed;
      EZBManager.EZBs[0].Servo.OnServoGetPosition += Servo_OnServoGetPosition;
      EZBManager.EZBs[0].Servo.OnServoAcceleration += Servo_OnServoAcceleration;
      EZBManager.EZBs[0].Servo.OnServoVelocity += Servo_OnServoVelocity;
    }

    private void FormMain_FormClosing(object sender, FormClosingEventArgs e) {

      EZBManager.EZBs[0].Servo.OnServoMove -= Servo_OnServoMove;
      EZBManager.EZBs[0].Servo.OnServoRelease -= Servo_OnServoRelease;
      EZBManager.EZBs[0].Servo.OnServoSpeed -= Servo_OnServoSpeed;
      EZBManager.EZBs[0].Servo.OnServoGetPosition -= Servo_OnServoGetPosition;
      EZBManager.EZBs[0].Servo.OnServoAcceleration -= Servo_OnServoAcceleration;
      EZBManager.EZBs[0].Servo.OnServoVelocity -= Servo_OnServoVelocity;
    }

2. In the event functions, you can send the appropriate data to the ESP32 with the command info for the specified servo

3. In the ESP32 firmware, extend protocol command 0x00 as the link here says (synthiam.com/Support/EZB-Firmware/extend-ezb-protocol). There's an example of it in the Arduino firmware; a few others are listed on that page. So if ARC sends 0x00, 0x01, the 0x00 means "custom command" and 0x01 means "move servo" perhaps. and then the following bytes are the parameters for the move servo. It is up to you to decide how to implement the protocol and what commands it uses. There's no worry about conflict because your firmware and robot skill work together.

Here's a little cheater for you to get you up and running. This is the code for LewanSoul that does the exact thing u wanna do, except it's using the UART and not custom commands. This is already on GitHub anyway but this will save you from searching for it: LewanSoul_Servos.zip

I finally found out what the real issue is with my code. But I did not find it until after I built a skill for a JavaScript extension and creating function calls to send requests to the ESP32.

In my variable initialization for the custom ESP32 firmware I had, for some very dump reason, initialized a variable with a call to Read16(). Not sure why I had that, and the code using that variable was not even being called. Reading that byte messed everything else up.

Can't believe I was doing something so stupid. You would never know I've been programing for 40 years !

Well, at least I finally built a skill and got it working. That is something I had been trying to do for a couple of years, but just never got it fully done.

Congratulations James! Don't beat yourself up over this. You found it, that's the important thing.

@DJ Sures, now that I got the RoboClaw library and related Javascript interface to work, now I need to know what to add to the ESP32 firmware to make it work with EZB ControlCommand("EZB Connect By Name", "Connect", port, "devicename").

Can you add more detail about what you mean by that?

My robot has 2 EZB v4 devices in it at this time. One of them I have setup as the network of the robot (AP Mode, with SSID B9MainDevice). The other EZB (in the brain) is setup with System Name as B9BrainDevice, EZ-B IP Address as xxx.xxx.x.2, and it logs into the B9MainDevice.

On the ARC side, I have the skill EZB Connect by Name, and a Script that connects to the B9BrainDevice by its name - B9BrainDevice.

I need to know/understand what needs to be done in the ESP32 firmware to set the System Name, IP address, and have the name boardcast so the the EZB Connect by Name can use B9BrainDevice instead of an IP address. I set the #define WIFI_AP_SSID to "B9HeadDevice", but EZB Connect by Name does not see it, so I assume since the B9HeadDevice (ESP32) is in Client mode and logging into the B9MainDevice (EZB), that there must be something else to do to boardcast the name when in Client mode.

I'll tell you what I'm thinking, and you can tell me how far off I am from understanding. :)

1. Your custom firmware is an EZB firmware that extends the protocol with new commands for controlling a servo controller on an ESP32 with wifi

2. Therefore, you connect to your custom EZB firmware using the Connection robot skill

3. The connection robot skill accepts either a Serial Port (USB) or IP Address (wifi) of the remote EZB. There can be multiple EZ-B's connected, starting at index 0 (first)

4. Your custom firmware is wifi. But you also have an EZB v4 wifi. This means you would connect the EZB v4 and ESP32 to Client Mode. That means the two devices connect to the same access point (or router) to which your PC is connected. The access point/router will be assigned a unique address to each of the three devices (PC, ESP32, EZB v4)

5. The connection robot skill accepts several ControlCommands for connecting and disconnecting from ezbs. You want to connect to the EZBv4 and ESP32 using programmatic control commands.

6. Let me speculate that the EZB v4 had the IP address 192.168.0.100, and the ESP32 had the IP address 192.168.0.101. Let's also assume you wanted the EZB v4 to be on Index #0 and the ESP32 to be on Index #1. The control commands would be.

ControlCommand("Connection", "Connect0", "192.168.0.100");
ControlCommand("Connection", "Connect0", "192.168.0.101");

You might be asking about the ESP32 broadcasting itself, which can be detected using the EZB Scan Tool. I do not believe the ESP32 does that if that's the case. The firmware could be modified to do it - perhaps in a loop while it waits for a command to send a broadcast every few seconds. If that's something you're thinking of adding, let me know, and I can add some details on how the broadcast works. I recently added a bunch of support for the broadcast to ARCx, so it's fresh in my mind :).

Oh, and one more thing. This document has a few examples of how to connect multiple EZB's to one PC. There are a few different ways to do it based on your setup: synthiam.com/Support/Tips-to-Make-a-Robot/Multiple-EZ-B-over-WiFi

We have discussed this before. When an EZB device is in client mode, the IP it gets is assigned by the router/network that the EZB is logging into. This can change, and since my robot will eventually be autonomous, and not have a user interface, ARC must either find out what the EZB device's current IP is (which I don't know how to do without manual/UI intervention), or connect to the EZB by name, which does not change. I already have ARC connecting to the 2 EZBv4 devices via system name (not device name since every EZBv4 device has the same name), and I want to do that with the ESP32.

I have been looking at the Arduino WiFi class methods. Looks like there is a way to force a specific IP for the device. If I can get that to work, that would be another way to go. Then the IP will always be the same, but not sure if that requires changing setup on my router.

Apologies if we had a conversation before. I volunteer some personal time on this forum and help several people, and my day is quite hectic, as you can imagine. I ask you to try to bear with me while I take time to help you get running. :)

1. hardcoding the IP on the device may be best if the IP changes. If that's going to change, the IP must be on the same IP network within the netmask. I assume your access point/router is part of the robot.

2. Adding a second USB Wi-Fi adapter to your laptop is the best option. That way, you can have the EZB v4s, and ESP32 connect to it with static IP addresses. They will never change and will remain static moving forward.

3. If you want to use the broadcast name, you'll have to implement a broadcast feature in the esp32. I'm willing to provide you with the broadcast info if you implement it as I described earlier.

The protocol is UDP on port 4242. You send a packet to the network broadcast, which is the network's broadcast IP. Most likely, your class C with 255 as the last DQN value. For example, 192.168.0.255 or 10.0.0.255, etc. I'm guessing 255.255.255.255 might also work.

The packet is assembled like...

              string broadcast = $"EZ-B {EZBType}||{Environment.MachineName}||{ipAddress}||23";

As an example, a broadcast packet could look like...

EZ-B JSALE ESP32||Some unique name||192.168.0.2||23

In the wait for connection of the esp32... maybe loop and every 2 seconds, send a broadcast packet.

Oh and quick look at the esp32 code you'd do something like this...

#include <WiFi.h>
#include <WiFiUDP.h>

// Create a WiFiUDP object for broadcasting
WiFiUDP udp;

// UDP broadcast address
IPAddress broadcastAddress(255, 255, 255, 255);

// UDP port
uint16_t udpPort = 4242;

// Delay between broadcasts (2 seconds in milliseconds)
unsigned long broadcastInterval = 2000;

// Time tracking for broadcast
unsigned long lastBroadcastTime = 0;

void setup() {
  // WiFi initialization code here
  // ...
  
  // Initialize the UDP object
  udp.begin(udpPort);
}

void loop() {

#ifndef AP_MODE
  if (WiFi.status() != WL_CONNECTED) {
    resetFunc(); 
  }
#endif

  // UDP broadcast every 2 seconds
  unsigned long currentMillis = millis(); // Get current time in milliseconds
  
  if (currentMillis - lastBroadcastTime >= broadcastInterval) {

    lastBroadcastTime = currentMillis;

    // Data to be broadcasted
    String message = "EZ-B JSALE ESP32||Some unique name||" + WiFi.localIP().toString() + "||23";
    
    // Send the UDP packet to the broadcast address
    udp.beginPacket(broadcastAddress, udpPort);
    udp.write(message.c_str());
    udp.endPacket();
  }

  if (_SERVER.hasClient()) {

    _CLIENT = _SERVER.available();

    Serial.print("Client connected from ");
    Serial.println(_CLIENT.remoteIP());

    while (_CLIENT.connected()) 
      doEZProtocol(); 

    Serial.println("Client disconnected");

    _CLIENT.stop();

    Serial.println("Waiting for client...");
  }
}

@Athena is there anything you want to add to this conversation that will assist @jsale?

I fully understand you being a volunteer on the forum, and really appreciate your time and help. I (and many others) would have a hard time understanding all there is with ARC and EZBs without the fantastic help you provide.

Back to the issue - I did leave out one important thing: The 2 ESP32s and one of the EZBv4s will actually be logging into the other EZBv4 (which is configured in AP mode). Not sure that makes any difference.

Again, I really appreciate the help !

Given your setup where the ESP32s and one EZBv4 are connecting to another EZBv4 in AP mode, it does simplify the network topology since all devices are on the same local network managed by the EZBv4 in AP mode. This setup ensures that all devices are within the same subnet, which is crucial for direct communication without the need for routing through an external network.

For your specific scenario of sending data from the ESP32 back to ARC, and considering the previous discussions and suggestions, here are a few points to consider:

1. Static IP Configuration for ESP32: Assigning a static IP to your ESP32 when it connects to the EZBv4 in AP mode can simplify the connection process in ARC. This approach requires configuring the ESP32 to request a specific IP address when it connects to the WiFi network. This can be done through the ESP32's WiFi configuration settings in your code. However, ensure that the static IP does not conflict with other devices on the network.

2. Implementing UDP Broadcast on ESP32: As suggested, implementing a UDP broadcast feature on the ESP32 can be an effective way to announce its presence and IP address to ARC. This would involve periodically sending UDP packets with the ESP32's details to a broadcast address, which ARC can listen to and use to establish a connection. The provided code snippet outlines how to set up such a broadcast mechanism.

3. Receiving Data in ARC: On the ARC side, ensure that you have a script or robot skill set up to listen for incoming UDP packets or serial data from the ESP32. This could involve using the "TCP Server" or "UDP Server" robot skills in ARC, depending on your communication method. These skills can be configured to listen on specific ports and process incoming data.

4. Debugging Communication: If you're not receiving data as expected, consider using network monitoring tools to inspect the packets being sent and received. Tools like Wireshark can help you verify that the ESP32 is broadcasting its information correctly and that ARC is receiving the packets. Additionally, ensure that any firewall or security software on your computer is configured to allow the necessary network traffic.

5. Consistent Device Naming: For connecting to devices by name, ensure that each device has a unique and consistent name within your network. This can be managed through the device's configuration settings. In the case of the EZBv4 in AP mode, you can set its SSID to reflect the device name, making it easier to identify and connect to.

By following these steps and considering the network setup where devices connect through an EZBv4 in AP mode, you should be able to establish a reliable communication link between your ESP32 and ARC. This setup will facilitate data exchange and control commands, enabling more complex interactions and behaviors in your robot project.

It's good when Athena double-checks my work.

Are you leaning toward the broadcast method? Adding the broadcast feature to the ESP32 is probably the best way because it's working for you with the EZB v4. Does the code that I provided above make sense? The built-in EZB scan receiver should work, so there is no problem with going that route.

PS, thank you for the kind words!

@Jsale, First, I don't know a lot about networking but here is what I've found out about working with mutable EZBs connecting to ARC....

in the past I've tried to connect mutable EZB's to one EZB in the way you propose to do. Even though they would connect and work with no problem there was an issue. Each time the 3 EZB's would connect to the one they would have different index numbers each time in ARC. For example, EZB #2 would connect to connection 0, 1, 2 or three at different times. The people at EZ Robot said that this was expected behavior as the WIFI  board on the EZB didn't act like a router and keep track of IP addresses between power cycles. I couldn't get multicable EZB's to connect to one EZB and consistently keep the indexes assigned properly in ARC. Connecting just one EZB in this manor seems to have no issues keeping index numbers correctly assigned. Maybe it was just me but I tried to get this to work for a while before I reached out to EZ Robot.

If you find a solution please let me know. I ended up directly connecting my 3 EZB's individually in my robot to my onboard computer using the USB method. I would think having a dedicated access point or router mounted on the robot would work also. Another method I've tried and that worked was to assign static IP addressed to each EZB in the router it's self.

Good luck.

@DJ Sures, most of the code makes since. Two questions however.

1. Defining the broadcastAddress(255, 255, 255, 255) - should that have the ip I want to set as fixed ip for the ESP32 device?

2. The line udp.write(message.c_str() ); has compile error: invalid conversion from const char* to uint8_t, and I have not been able to figure out how to fix that.

I got it figured out: 1) no that stays 255,255,255,255 and 2) used message.println instead.

@Dave Schulpius, I use the EZB Connect By Name skill which connects to an EZB device by the system name (which you have to configure), and assigns that device to a specific ARC Connect port. For example: ControlCommand("EZB Connect By Name", "Connect", 1, "B9HeadDevice"). Here, the EZB device is configured with the system name B9HeadDevice, and that device is assigned to ARC connection 1.

Attached is a step-by-step Cheat Sheet I have setting up 2 EZBs, one in AP mode, the other Client mode that boardcasts the system name. cheat sheet.pdf

There's been confusion about the difference between a "WIFI Name" and an "EZB Name." in the past. Here's some detail about the difference between the two...

Remember, the "connect by name" robot skill's ControlCommand parameter is the broadcast name of the EZB on the UDP port I described above. It is not the WIFI name. You cannot connect to an EZB's TCP port by only a WIFI name because WIFI does not have an IP address. WIFI is a connection to a "thing" that transmits data. The "data" on that "thing" can be TCP or another protocol. So, a software program can't "connect to a device's service via WIFI" unless the program knows the IP address and port. The IP address and port is specified by the EZB broadcast that I explained above.

An example would be an AirPlay device. Let's pretend you connect a computer to a speaker of WIFI. You did not connect the software streaming music to the speaker over WiFi. You connected the software that streams the music to the speaker over TCP (or some other protocol). Connecting WiFi is no different than plugging an ethernet cable into your computer. You "cannot connect to an ethernet cable with a program." Just pretend that the "WiFi access point" is an ethernet cable with a name. :)

@Athena, add some additional context about this and the OSI network model.

Certainly, @DJ Sures. To add to the explanation regarding the difference between a "WiFi Name" and an "EZB Name," and how devices communicate over a network, it's essential to understand the basics of the OSI (Open Systems Interconnection) model. The OSI model is a conceptual framework used to understand network interactions in seven layers, from physical connections up to the application level where user interactions occur.

1. Physical Layer (Layer 1): This is the lowest layer of the OSI model, dealing with the physical connection between devices, such as Ethernet cables or WiFi signals. It's about transmitting raw bits over a communication channel.

2. Data Link Layer (Layer 2): This layer provides node-to-node data transfera link between two directly connected nodes. It also handles error correction from the physical layer.

3. Network Layer (Layer 3): This layer is responsible for packet forwarding, including routing through intermediate routers. Here is where IP addresses come into play, allowing devices to find each other on a network.

4. Transport Layer (Layer 4): This layer provides transparent transfer of data between end systems or hosts. It's responsible for end-to-end error recovery and flow control. It manages the delivery and sequencing of packets, including TCP and UDP protocols.

5. Session Layer (Layer 5): This layer establishes, manages, and terminates connections between applications. It sets up, coordinates, and terminates conversations, exchanges, and dialogues between the applications at each end.

6. Presentation Layer (Layer 6): This layer translates data between the application layer and the network. It's responsible for data encryption and decryption, data compression, and data translation to ensure the data from the application layer can be read by the network layer and vice versa.

7. Application Layer (Layer 7): The top layer of the OSI model directly interacts with software applications to implement a specific service or function, such as HTTP for web browsing, SMTP for email, or FTP for file transfer.

When we talk about connecting to an EZB device by name using the "Connect By Name" skill in ARC, we're operating at the higher layers of the OSI model, specifically the Application Layer. The "WiFi Name" is essentially the SSID (Service Set Identifier) used at the Physical and Data Link layers to establish a WiFi connection. In contrast, the "EZB Name" is used at the Application Layer to identify and connect to a specific service provided by the EZB over the network.

The process of connecting to an EZB involves multiple layers of the OSI model, starting from establishing a physical WiFi connection (Layer 1 & 2), obtaining an IP address through DHCP (Layer 3), and finally connecting to the EZB's service using its broadcast name over UDP (Layer 4 & 7). This multi-layered approach ensures that devices can discover and communicate with each other efficiently over a network.