It’s been a while since the last blog post from the Dancebot team. We’ve received a lot of interest from the new RAS members in joining this subcommittee, and have moved ahead in setting up projects for the members to work on.
I’ll list a quick summary table of the projects that we’ll be doing this semester below:
Additionally, during our first meeting the software and firmware team finalized the communication protocol API (Application Programming Interface) for the server.
The mechanical team also discussed a lot of good ideas on Dancebot V2.0 body design and Mothership 1.0 body design.
In order to tell the Dancebot to do something, such as walk forward, we need an interface that will send and parse our commands. It could be as simple as a button on the robot. In our case, we’re developing a web application interface where the user and robot communicate with each other through a single middleman (the server).
Now what does the web application interface look like? It looks like a normal web url, like the url to this site: https://ras.ece.utexas.edu/. We’re using a protocol that defines how our commands look like called HTTP, or the HyperText Transfer Protocol.
In particular, we’re using GET requests to send and receive our data.
Why are we sending data with a GET request?
Indeed, if you’re thinking that there’s a disparity here, you’re right. We should be using a POST request to manage the sending of data. We’re using GET requests right now because they are just a little bit easier to implement a first version prototype.
For the Dancebot, a GET request will look like the following:
Let’s break this down.
myserver.com/ is the root address of the URL page we’re accessing. If we just entered
myserver.com/, we would typically be served the HTML page like the one you’re reading right now.
/endpoint is a unique endpoint that we specify. We are looking for requests at this endpoint from the Dancebots to guess what: join the server! We append important robot information to this endpoint to identify the robot that wants to join.
? tells us a GET request is starting.
name1=value1 assigns the string value
value1 to the argument
name1. Our server, upon receiving the GET request, will parse and interpret the variable for us to use in further processing.
& is essentially a delimiter that splits two arguments. As you can see argument
name2 comes right after and is assigned
This request is processed by the server and returns either a success or a failure (in the event that the request is malformed).
Here’s the cool stuff. You can find a more detailed version of this API here, in this issue.
Essentially, the robot has a couple different parameters we want to be able to tune or change as the user. This includes the following:
Robot State of Charge
Robot Eye Color
Robot Eye Expression
Robot Shutdown Command.
The robots are able send their current or initial status to the server with the following endpoints:
The functionality of /robotJoin and /robotLeave and when they are used seem pretty self explanatory. /robotUpdate is called every 150ms while the Dancebot is active and on the swarm network, and provides important information such as it’s current charge. What the robot gets back from the GET request is the new state, if any, it should transform to. For example, if the robot movement was currently WALK, and we get back the HOP movement, then the robot now needs to HOP.
In the other direction, the User can also request and send data, in GET requests encoded into the HTML page that you are served (that is, if you click a button, it’ll send a GET request to the correct endpoint to update something about the Dancebots or Mothership).
The user has four specific endpoints:
/userMove - When the user wants the robot to adopt a specific movement
/userExpress - When the user wants the robot to adopt a specific expression
/userShutdown - When the user wants the robot to shut down
/ - When the user wants to get an updated version of the page
You can see the specific issue linked above for what arguments are provided for each endpoint.
This is our communication API! The next step for the web application and dancebot firmware teams are to:
Wire up the user API to the web page and be able to trigger requests in the server
Update the requests API in the dancebot firmware send and receive data, and then be able to parse and interpret data.
There’s one thing I haven’t talked about in this post: security! A discerning reader would probably notice that since we gave away what the API looks like, you can fake requests to our server. That means you can do a bunch of nefarious things to our server and robots while it’s on, like:
make it appear that we have a hundred robots on the server
lock the robot state by spamming commands to it so it appears broken to the end user
DDOS our server by sending so many requests that our server kills itself
These potential events are catastrophic for an actual application with economic and social implications. This enforces the idea that when we (or yall) develop software, we need to keep in mind ways people can abuse it and develop best practices to prevent said abuse.
Something our team is looking at as a next step after this prototype is set up is to send encryption keys with requests. That way only authenticated users will be able to send valid commands. For example, each Dancebot can have its own private key that the server already knows. If a malicious user attempts to spoof itself as a Dancebot with the same ID and send bad data to the user, it’ll be unable to do so because it doesn’t have the private key.
If you’re interested on learning more about this project, you can join our slack at utras.slack.com and message me (@RoboticFish) or email me at firstname.lastname@example.org.
Author: Matthew Yu