Dancebot - Kicking It into High Gear

03 May 2020

We recently had our first meeting as the new Demobots Dancebot Team, and there was a lot of interest on working on the project! The team right now consists of internal members, but once the new semester starts, anyone looking for a cool Demobots project can join.

A little bit of history before I discuss our future mid and long term plans: Dancebot is a subgroup of the Demobots team that was created back in Fall of 2017 (as far as I know). Dancebot is one of the showpiece robots we show off at outreach events; it’s very easy to start up and simple to play with.

Dancebot was renewed in Fall 2019 by a team of Robotathon participants. They envisioned an extension to current project (a single robot and web application) - a swarm of dancebots dancing in sync with each other. However, they met with an untimely end, and I haven’t heard from them ever since.

In March, Region V decided to disband the group since it was unlikely that we would be able to attend the conference (for more reasons on this, you might want to see our Region V blog post). However, we were loathe to disassemble the current R5 robot and decided to repurpose it as a Dancebot Mothership.

TLDR; we have rebanded as the new Dancebot team with some other RAS members, and are continuing last Fall’s Dancebot swarm plan with a Mothership robot.

Okay, now to the future plans:

Looking towards this summer, after finals, we want to work on the design of the new Dancebot vision. The design update is split into three parts: the individual Dancebots, the Mothership, and the web application that we use to control both sets of robots.

For the individual Dancebots, we want to optimize the body to make it easier to assemble and 3d print. Right now, it takes around 8-16 hours to print a single robot, and the 3d print material can certainly be reduced while maintaining the required structural integrity. We also want to try to figure out new ways of movement with our current setup, and update the electronics. I want to design a small PCB to replace our current rats nest of a breadboard, and to increase the internal space to fit a larger battery. Additionally, I believe that we can add a simple battery monitoring circuit (see this video), which will play into the web application later in the post.

For the Mothership, our VP, Reiko, will be leading part of the team to design a new face for the robot. The MEs will also look at revamping the mechanisms used to deposit the Dancebot swarm from the Motherhsip. One of the ideas that was floated was an open floor underneath the robot, and a hook that goes through the underbelly of each Dancebot. It can lower itself to deposit the Dancebots by settling them on the ground and moving forwards, and raise itself to keep the Dancebots suspended.

For the web application, the existing webpage was pretty barebones, as it was served from the ESP32-PICO-KIT microcontroller on the Dancebot using Arduino.

I proposed this mockup at the meeting:

A couple of features I think might enhance the ux:

• Control robots independently as well as synchronously.

This would make the actions of the swarm highly customizable and varied. I think we can do that by using a toggle button. The robot should start at the REST state, and every time the button is tapped, the robot should cycle states into WALK -> HOP -> WIGGLE -> ANKLES -> REST. Likewise, to command all robots synchronously, there should be a larger button underneath the Mothership with the same functionality.

• The UI displays the state of each robot.

During communication, each Dancebot will send a request to update its state to the server, including battery status (hence the battery monitoring circuit), ID, eye color, and current movement. We can use this request to confirm that any commands sent from the Mothership have been received and interpreted correctly.

• The UI can send commands to customize the robot.

We can use several assets (designed by Reiko and co.) to represent each unique demobot. For example, an orange Dancebot head that corresponds to Dancebot with ID 1, which has a 3d printed orange head. We can tap the eyes or face of the Dancebot to change the eye color, which will correspond to the LED matrices on the robot. In the case of the Mothership, it can change both the color and the expression.

A couple of more interesting ideas regarding software and hardware:

• We can use assets that represent the state of charge for the robots - a yawning robot face if the battery voltage dips to a low operational level, and a snoring robot face if the battery voltage dips to a critically low operational level.

• An auto off circuit if the state of charge becomes too low. This will grey out the robot in the webpage after the heartbeat requests stop for at least a certain period of time. Perhaps something like this?

• Image processing to automatically adjust the state of the robots and the Mothership, I.E. making the swarm do a certain dance or the Mothership expression change based on a pose classifier. Part of this work has already been done for the SIMLab at UT, so it’s possible to integrate this with the Mothership’s onboard RPI camera.

I would like for most, if not all of the design work to be done by the end of the summer. In terms of software development, I think that the webpage is a pretty easy project and can be done with a relatively low amount of effort weekly (1-3 hours for 12 weeks. This can probably be done in about 20 man hours max.).

For long term plans, I would like to begin the construction, implementation, and testing of the robots this fall. I would love if we could have one or two Version 2 Dancebots ready by the end of the semester, with the ability to be controlled by a RPI standalone. Having a working prototype of the Mothership complete as well will be a pretty big stretch goal.

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

---