Upcoming Events:

Dancebot - Dancebot Starts the Semester Dancing

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:

Dancebot Projects for this semester.

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.


What does this mean?

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.

What does a GET request look like?

For the Dancebot, a GET request will look like the following: myserver.com/endpoint?name1=value1&name2=value2

Let’s break this down.

This request is processed by the server and returns either a success or a failure (in the event that the request is malformed).


Alright, but tell me more about the communication protocol API!

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:

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:

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:


Bonus: Security

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:

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 matthewjkyu@gmail.com.

Author: Matthew Yu