Tyler Hassenpflug, Tim Holt, Alec Portelli, and Blake Williams
Mental Mode & API
The basic architecture of the code for the project includes 5 different modules, 3 for controllers and 2 for Gigglebot interpretation. The code includes a module for a master swarm controller, a module for individual control in a swarm setting, a module for control in an individual control setting, a module for Gigglebot interpretation of swarm setting commands, and a module for Gigglebot interpretation of individual setting commands. The model we used for switching controlling parties in the individual control setting was communication based. Once both bots are in the appropriate location, the separate parties gain each other’s attention and initiate a switch of control via use of the microbit’s buttons. In the swarm setting, there is no need for communication to switch control because both the master and the individual have complete control over the bot, thus all that is necessary is a mutual understanding between the master controller and the individuals that they will both initiate actions that are mutually beneficial.
To view the task analysis, please download the file below.
The basic architecture of the code includes 5 modules: pass setting controller, swarm setting master controller, swarm setting individual controller, gigglebot swarm setting, gigglebot pass setting. In designing for the pass setting, we utilized the built-in gigglebot controller module for controlling the bots. While this module led to rather high sensitivity that rendered the bots difficult to control initially, once the controller microbit was housed in our ergonomic controller, the microbit became significantly easier to control. For passing control, our pod decided to designate buttons on the microbits for changing the controller group of the bot using a radio signal. We initially tried to make it so each controller initiated a particular change of control for both bots in the pod but ran into problems with both bots being able to pick up the signal from a single controller. We then switched to having each controller switch the bot being controlled to the other groups controller which required slightly more communication.
For the swarm setting, we only used radio signals to give commands to the bots so that all bots could receive signal from a single controller (the master). In this setting we essentially mapped each direction that the bot could move to a tilt of the controller microbit in that direction. To solve the problem of having multiple controllers control the same gigglebot, we designated a 10 value range for each controller to give commands through. The master controller gives commands from 20-29, and the individuals use the 30s and 40s. Our shared control between the master and individuals basically relies on communication and trust between the two parties. If the individual notices some error in their bots path, they can send the commands that will fix the bot, overriding what commands the master is giving, and then stop giving commands thus returning control back to the master.
Pass setting controller
Pass setting Gigglebot
Swarm setting gigglebot
Swarm setting individual controller
The code for swarm master controller unavailable as it is on the other team in the pod’s machine.
User Walk Through
Lucy is a 21 year old student at Tufts University studying Economics. Lucy knows very little about technology other than being able to sync her apple watch, iphone and macbook. During finals week, she accompanies her friend Tim to the Nolop lab on the first floor of Tufts new Science, Engineering and Technology building. The Nolop lab is a new makerspace open to everyone at Tufts campus. Lucy has been listening to Tim ramble on about his project for the past two weeks and how he has been programming MicroBit chips for something called a GiggleBot. She wanted to see what all the fuss was about so she decided to join him in Nolop while he finishes up his final project.
When Lucy first walks into the Nolop lab she notices several little green robots, controllers and and rooms with grids spread out on the floor. She picks up the controller next to Tim’s Gigglebot and turns on both the GiggleBot and the controller. She tilts the controller forward, instructing the GiggleBot to rotate its wheels in forward orientation relative to the bot. She continues to tilt the controller forward until she drives directly into the wall. She then tips the controller backwards, instructing the bot to rotate wheels in a backwards orientation relative to the bot. She continues to tilt the controller backwards until it rams directly into Tims ankle. She then repeats this process by tilting the controller to the right and then to the left.
Tim then picks up the controller for another bot in the same pod and turns on both the bot and the controller. Tim looks at Lucy and indicates that they are going to switch controls of the bots. Both Tim and Lucy pressed the A button to gain control of each others bots. They each look at their new bots and determine if the pot needs to move frontward, backward, to the left or to the right.
Two other students from Tim’s Human Machine System Design course pick up controllers for the other bots in the same pod. They each turn on their respective controllers and bots and begin driving them around the room. Now that all bots are turned on, the master controller, in this case being Lucy, determines she wants to gain control of all bots. Lucy observes the location of all the bots which direction she would like them to move. All at once, Lucy takes control over over all of the bots in the pod, moving them around the room in a group.
Reflections and Future Directions
This assignment brought forth some of the human factors challenges that come with swarm system design. The coordination that was needed during the design process between the coders was vital, and then getting everyone on their respective teams to understand the system proved to be key as well. Creating a universal system that is easy for everyone to use and that can allow more than one person to enter the path of control proved to be a very difficult task. There are some arbitrary concepts when it comes to control. For example “50% control” is arbitrary when we do not necessarily know what constitutes 50%. Designing the system forced us to define a lot of these unknowns. This project also helped us learn that human factors design isn’t necessarily always tactile. When figuring out exactly the system was going to work, everything was hypothetical until it was coded and tested. Visualization of a system is hard to do, and this project tested our abilities to take a task-analysis and transform it into an execution, rather than an interface or product. It definitely helped with the psychological side of the human factors process. In terms of designing the controller, using anthropometrics was the main challenge in finding a design that could fit the intended population. It would have been very easy to put the chip in a simple shape, but instead we took the time to find an intended audience, in this case 5%-95% of the male population, take the measurements, and create an adaptive ergonomic design that all members of our team could easily use. This was a great opportunity to take a real life case and design for someone that we could see using the product and make changes accordingly. Overall, this project tested on both sides of human factors: physical and system design that puts the user first.
Future directions of a project like this would be to increase the amount of robots that are being controlled, the amount of users, and being able to vary the amount of control a user or master user has. Creating flexibility for a user to determine how much control over the swarm is a very complicated task, and it again comes down to defining how much control 50% or 90% means. Especially with swarms that get great in size, passing control gets very complicated. Designing a system that seamlessly integrates how each user wants simultaneously would be critical to making it successful. Redesigning the interface would be very important as well. Instead of using two buttons to receive and give control, there could be some sort of interface that lets the user highlight what part of the swarm he/she would like to control, and thus there isn’t any sort of confusion or mixup when passing control. Having two buttons may create mistakes with who’s getting the control or not. In terms of the controller, creating a more ergonomic design with exterior materials that are more comfortable to use, rather than sheets of plastic, along with buttons that are easier to press. A new kind of interface, depending on the system, would help as well, such as a touchscreen with an ergonomic handle. Such a controller would be easy to figure out which user is controlling what, and thus making it simple to pass control within a big swarm.