Upcoming Events:
- Check out our new Google Calendar for committee meeting times!
Dancebot - Dancebot Update
Surprise update! I’ve been working on the Dancebot over the last week (and severely procrastinating on my final labs), and I wanted to share what’s been done.
Firstly, I’ve revised the entire network and software architecture of the robot. The changes I will be suggesting will primarily allow us to have multiple robots on the same network and server.
Network Architecture
The above picture depicts the current and new design of the Dancebot, and by extension, all Demobots that use the ESP32.
In the current design, the Dancebot hosts its own network on the ESP32 using an Access Point (AP) named Demobot. Additionally, it’ll spin up its own server at the IP address 192.168.1.x. The code also has functionality to join an existing network in a mode called Station (STA) and spin up its server there. I’ve not seen this latter mode in action, though.
There are limitations in this design, though. A couple are listed below:
- Hosting its own network and server can utilize vital processing power.
- Serving its own web page limits the functionality and appearance to the HTML and JS code you can deploy from the C++ code. This can be undesirable in AP mode because you can’t just bind JS libraries to customize your web page (no communication with the internet!). Everything must be served from the ESP32.
- The design only supports one Dancebot on the network and one user. More specifically, the server is synchronous with the Dancebot state and cannot work in parallel/manage a separate data structure/and receive requests from other Dancebots. We would like the Demobots Swarm to be able to connect to the same network and server.
The new design revises the interface for the network. It separates the Dancebot from the server it spins up (and other Dancebots) by partitioning the data shared between the two. The Dancebot holds its own internal state, the webserver maintains a database of Dancebot(s) and their states, and the users can only update the database in the webserver.
To synchronize the Dancebot state with the webserver’s, each Dancebot connected to the network will send a HTTP POST request every set period to grab the latest desired state and update information like state of charge.
I selected 150ms based on the expected response time I would like the robot to change its movement right after I click a button in the UI. This also reflects the time it takes to make a tap (I max out around 150-170ms on this online stopwatch site. Any longer and latency between state changes may appear noticeable, and clicks will not appear to have registered.
In the context of our Dancebot swarm project, this allows us to use the Mothership with an RPI4 to host the server and manage requests between many Dancebots. It will also allow us to have a Dancebot act as the central node for other Dancebots in the event that the Mothership is not present.
This is pretty cool!
A couple more things. Servers, and their IP, are unique for each Demobot type. While Dancebots share the same IP, the Polargraph can also join the Demobots network, and establish a server on a different IP. This allows us to customize the server requests for the robot, and prevent conflicting API calls that would occur if the Polargraph tried to send an update request to the Dancebot server database.
Finally, the individual nodes of the network are designed to be flexible. If there is no network available that the Demobot can connect to, it will spin up its own network and server in AP mode. If it joins an existing network and there is no server (I do this by sending a request to the expected IP and looking for a response), the Demobot spins that up in STA mode. If there is both a network and server, the Demobot connects normally. I call this CON mode.
Software Architecture
This image describes the current file structure for the Dancebot. The sketch setup() function does two things. It sets up a web controller (going through the process I explained in my last point), and then initializes the robot. The web server runs asynchronously, so we won’t need to touch it after it spins up. What happens next in the loop() method is that the Demobot checks its current state and runs for a bit, then sends a request to the server to update itself. This occurs in DemobotAPI.
Since the two files are independent, we can replace the internals of DemobotAPI (say, the implementation of calls to Dancing Servos with, say, Polargraph) with minimal modifications to the overall structure.
It’s not completely decoupled, however. If I wanted to use this template for Polargraph, I would need to update the API and data structure used in WebController and RobotConfig, as well as the implementations in DemobotAPI regarding updateState() (a POST request to the server) and its internal data structure.
This is where I’ve gotten so far. I’ve gotten the API calls to work and correct HTML/JS to serve on the user end. I’m also able to set up the WebController in all three modes (AP/STA/CON). What’s next is to implement the updateState() request and see if I can drive the Dancebot. This will be the foundation of our Dancebot Swarm project.
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