jsale
Resolved by DJ Sures!
@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?
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:
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.
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.
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.
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.
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.
I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
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.
Defining the broadcastAddress(255, 255, 255, 255) - should that have the ip I want to set as fixed ip for the ESP32 device?
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.
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.
Data Link Layer (Layer 2): This layer provides node-to-node data transfer-a link between two directly connected nodes. It also handles error correction from the physical layer.
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.
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.
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.
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.
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.
I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.