You’ve read all about Ryan’s “movement.py” script, so now it’s time to learn about “controlscript.php” – the script that collects client keystrokes and sends the movements to the WebSocket server. The script can be accessed at our GitHub repository here. So, let’s break it down!
Firstly, “controlscript.php” is a misnomer. It should really say “controlscript.js”, however I use a bit of PHP to get the IP of the robot (more on that later). The file extension needs to be .php so the server knows it needs to process it.
Attaching event handlers for the key presses.
This opens a new WebSocket connection with a WebSocket server on the IP provided. This is where the PHP code executes, in order to connect to the socket server on the NUC. I use snippets like this all over the site to get the IP of the robot. The “:5555” at the end denotes the port the server is running on. I don’t check for this automatically because there are going to be other socket servers running to serve raw sensor data, logs and such.
Now I set a couple of variables. The speed is currently set to 10 (100%) when the interface is loaded up, however as I write this I realise it may be smart to set it to something more resaonable – after all, 100% is very fast and could be dangerous if the robot is plugged into something or sitting on a table. The higher speeds should be used when the user is comfortable at lower ones. lastKey is used (as the name suggests) to store the last key the user has pressed.
Code within this function is executed every time a key is pressed. When a key is pressed, I want to store the key ID in a variable (creatively named key).
That is where lastKey comes in – If the currently pressed key is the same as the key that was just sent, there is no need to send it again. This solves an issue where the Dynamixel buffer would store repeated commands and continue to execute them long after the key had been released.
If the key press was successful, I can update lastKey.
The first segment of the switch statement updates the speed if the pressed key was a number. This is all done on the client side and there is no need to send any data to the robot.
The second section of the switch statement checks for the keys W, A, S or D.
The first thing the code does is provide feedback to the user by updating a list element called “controlFeedback” on the nav bar with the action and the speed at which the robot is travelling.
The action and speed is then sent to the WebSocket server using two numbers. The first represents the action (decided upon by Ryan and myself) and the second represents the speed. The numbers are separated by a space.
Code within this function is executed every time a key is released. Once again I store the key ID in the same creatively named variable, key.
If the key is any of the keys we are interested in, I first provide feedback to the user using controlFeedback, and then send the stop command (“0 0”) to the WebSocket server.
Just in case the user wants to do the same action again, we need to reset lastKey.
That’s pretty much all there is to it! However, the script offers expandability by adding more cases to the switch statement, allowing for more controls to be added in the future.
One thing we did try was adding arcing by holding down multiple keys at the same time (eg. W and A to arc to the left), however my impementation of that feature couldn’t track a last key pressed so we would have experienced the Dynamixel buffer issue.
Stay tuned for the fifth and final part, which will cover the remainder of movement.py (actually, it’s recently been renamed servo_party.py).