Today we enter a new era of robotic communication! We’ve got the control panel and the robot talking directly with the robot using WebSockets.
To do this, Ryan set up a WebSocket server on the robot using Python. The server waits for messages from the console.
On my end, the client/control panel connects to the server. JavaScript detects kepresses from W, A, S, D and numbers 0 to 9 and then sends the information to the WebSocket server with a single line of code:
1 | controlSocket.send(key + speed); |
It’s unbelievably elegant and simple.
I read Ryan’s code while writing this blog (which is probably something I should have done earlier). I can’t pretend to fully understand it, however when it comes to the WebSocket server I noticed something we can improve on Monday.
Currently, the WebSocket server is started with these arguments:
1 | run, "10.0.2.3", 5555 |
10.0.2.3 is the IP of the NUC and 5555 is the WebSocket port. The issue is that we have 2 NUCs with different IPs (and those IPs often change if we’re working on network hardware). This means the code has to be updated every time a new IP is being used. If the IP changes in Japan, it’s just another thing we have to debug in a stressful situation.
Instead, we could have Python check the IP of the NUC when the script starts and pass the IP variable as an argument instead of a fixed string – and there’s one less thing to worry about on competition day.
A feature like this already exists in the control panel.
1 | var controlSocket = new WebSocket("ws://<?php echo $_SERVER['SERVER_ADDR'] ?>:5555"); |
I’m using PHP to get the IP of the web server, which is conveniently the IP of the robot, which just so happens to be the IP of the WebSocket server. How convenient and unexpected!
We’re uploading all this code on our new GitHub repository over the coming weeks. Stay tuned for a blog from Ryan about that!
Also, if anyone wants a complete code walkthrough so you can understand the JavaScript client and the Python server, I’d be happy to write one up and post a blog.