The demo at the Children’s Museum was, if anything, humbling.  Nothing seemed to function as planned and we became very frustrated with not only the physical project but began questioning the idea of it itself.  The PVC pipes were not nearly as resonant as expected, we had wiring issues with the solenoid, and the drum pedal was unable to effectively produce sound by hitting the pipes.  Despite the technical failures, we were able to learn a lot about how people approached the project and what they expected from it. It appears that the tube configuration was intriguing to people, as many approached the project and attempted to interact with it.  Children would step on the drum pedal just for the fun of it, trying to figure out how it connected to the rest of the functionality, and a few people banged on the box. Having moving, functional parts would definitely add more magic to the project, as well as aesthetic adjustments (such as colorful paint), and a second functionality that would create more pleasant feedback than simple acoustic elements (we were thinking of adding colored lights).  The visit really helped put our project into perspective; we now know the limitations of the materials we are working with, our own skill limitations, as well as how people approach the project and what expectations from the user we have to rise to meet.

Revision Plan:

We know that our main barrier in the successful completion of this project will be simple trial and error of the form of acoustic elements and the tectonics of the project as a whole (how elements will be coupled to the base).   Based on the museum demo we are revising the experience to include reactive lights and the use of drumsticks to produce sound as opposed to the drum pedal, not only because they are more effective at producing sound (at least with our particular material palette), but also because they allow the user more agency in where and how they can hit the various elements of the acoustic configuration.

1. Technical Limitations: The only technical limitation we encounter during the trip to the children’s museum is that our battery cannot last for the entire visiting session and we had to swap the battery in the middle of the visit, which interrupted user experience.
2. Moment of Delight: The graphical interface of the game involves a starting position and several goals (marked with yellow stars). Since this is a collaborative game, the users (both children and adults) will have a sensor of achievement after moving the ball to a certain goal by working together. This process involves getting familiar with the controller, establishing a mutual goal, and operating the machine to reach the goal, which is not an easy task for children, or even adults, to do within a short period of time. However, the efforts of figuring out the goal and playing the game with a partner highlight the value of the reward. We do believe that we can add more visual or sound features to the game to further enhance this sense of achievement after the users successfully achieve a goal.
3. Surprising Interactions: Since the game involves two players working together, it is almost impossible to reach any goal without the players establishing a mutual goal. This requirement of the game led to a very surprising result: the players were more likely to accomplish the goal if either the two players were very easy to collaborate (one twin brothers easily got to all the goals with excellent communication), or a strong leadership presented in one of the players (a parent/child pair or one of the child is really bossy). We did not expect to observe the second play mode until we did see it.
4. Additional or different interactions: Currently the game has human/machine playing mode, which allows the user to play the game by controlling only one degree of freedom, with the other degree of freedom controlled by the machine. However, we did observe that this human/machine play mode confused several children/adults since it was difficult for them to recognize how the machine responded to their control inputs. We also think it will be cool if we can have two of these machines side by side for two pairs of users to compete with each other.
5. How does the visit change our vision for a fully realized project: Our project was very close to a fully realized prototype at the last visit. From our feedback, we think it would be great if we could add more response to the users after they achieve goals. We also think that the human/machine mode might not be a good idea for a short exhibit game for children since the random motion of the machine does not help users to understand the game quickly.
6. Video Clips and Photos:

Revision Plan

1. Resolve known technical limitations:

We should bring more battery to the museum.

2.     How does the fundamental experience need to be modified?

We need to change the criteria to turn to kid-in-control mode. Previously, once kids press a button, only the axis align with that button will be in control. The other axis would keep the automatical movement. This confused a lot of kids whether they were in control or not. We will change this in a way that once a button is pressed, both axis will be in control of kids.

We also need to change the game to an open-ended game, which does not have a specific “start”. In this way, children can just start in the middle without start the game all over again.

3.    What new capability will you add beyond the initial objectives?

We will add more sound or light effect to confirm kids are they are rewarded when they move the ball to the stars. In order for the arduino to tell whether teh bal is atone start, we will use an IR proximity sensor to sense teh existence of the ball at stars.

1. The microphones didn’t pick up some claps, sometimes claps would make the robot drive the wrong way.
2. When it spun after 20s of idle, it really caught people’s eye. Also, when children were able to make it move by clapping they were very delighted.
3. To my surprise, not many kids tried to break it. Parents did a good job of saying “don’t touch!”. I was a little surprised at how well it worked with the kids knowing where to clap and what to do overall.
4. Adding LED lights to the base and 4-way motion using 2 additional microphones should be a big hit.
5. I’m super inspired after this visit and after seeing how the kids and parents interact with the robot, many good ideas and small tweaks came to mind.
6. No releases obtained for audiovisual documentation.

Revision Plan:

1. Adjusting sensitivity/directionality of microphones and adding omni-wheels will help. Also using a stronger battery power system so we don’t have to keep changing 9 volts will be good.
2. The fundamental experience was very successful. We will build upon it.
3. 4-way motion and LED lights. No additional functional capability otherwise.
4. Completed.
5. Order forms filled.

Top: Laser beam working prior to condensation obscuring the acrylic.

Bottom: Condensation on top panel hides the laser beam

Analysis:

Due to the technical limitation of fog condensing on the inside of our acrylic and preventing the laser’s path from being seen, our first presentation failed to invoke any moments of delight in the visitors. However, we did observe some interesting interactions despite our exhibits broken state. For instance, we observed that a lot of people assumed that our exhibit somehow controlled the larger “Lake Light” kinetic sculpture next to us. Often the visitors would turn the knob while looking at “Lake Light” instead of our project. This was mostly due to the fact that “Lake Light” was much bigger than ours and incorporated motion, sounds, and lights which drew in visitors. Because of this for our next iteration we plan to have completed our planned musical aspect and have the actuators fully operational to have a motion aspect to further draw in visitors. Previously we had thought that the light of the lasers would be enough to draw visitors in but after our observations at the museum we are planning to add additional LED to go with the musical element and help draw people in better.

Revision Plan:

Currently, in order to rectify the condensation limitation we have ordered anti-fog spray which should help prevent liquids from condensing on our viewing surfaces and obscuring the laser-show.

Overall the experience needs to be made more engaging so we will be increasing its size and number of actuators to allow the users to interact with it more. Additionally, we observed that the experience needs to generate some kind of effect beyond just the laser movement so we will be integrating music that is affected by the actuators in the second design to address this.

All new items which must be purchased are prepared on this form: Purchase Form

New Timeline

Code

/* Basic Code Base for Verifying All Core Functionality on a
 * Proof-of-Concept Box */

#include <Encoder.h>
#include <CheapStepper.h>

#define ENC_STEPS_PER_REV 80.0
Encoder EncO(3,4); // Output Encoder

const float MOT_STEPS_PER_REV = 4075.7728 * 43.0 / 11.0;
CheapStepper stepper(8,9,10,11);
bool movingClockwise = true;
unsigned long moveStartTime = 0; // this will save the time (millis()) when we started each new move

// Returns the Output Angle of the Encoder in Degrees
float outputAng(){
  return 360 * EncO.read() / ENC_STEPS_PER_REV;
} // #outputAng

struct CurrentMoveType{
  float start; // Starting Angle of Move [deg]
  float e; // Ending Angle of Move [deg]
  int stepLen; // Number of Steps in Move
} CurrentMove;

void goTo(float ang){
  static float commAng = 0.0; // Last Commanded Angle
  float Da = ang - commAng;
  CurrentMove.start = commAng;
  CurrentMove.e = ang;
  CurrentMove.stepLen = abs(Da) * MOT_STEPS_PER_REV / 360.0;

  movingClockwise = Da < 0;
  moveStartTime = millis();
  stepper.newMove(movingClockwise, CurrentMove.stepLen);
  commAng = ang;
} // #goTo

// Return the Current Commanded Motor Angle using Step Interpolation across 
// the Bounds of the Current Move
float getCommAng(){
  return CurrentMove.start + ((float)(CurrentMove.stepLen - abs(stepper.getStepsLeft()))) * (CurrentMove.e-CurrentMove.start) / ((float)CurrentMove.stepLen);
} // #getCommPos
void setup(){
  Serial.begin(9600);
  stepper.set4076StepMode();
  stepper.setRpm(36);
  goTo(180.0);
} // #setup

char dir = 1;
unsigned long last_update = -10000;
void loop(){
  stepper.run();
  if(millis() - last_update > 100){
    Serial.print(getCommAng());
    Serial.print(", ");
    Serial.println(outputAng());
    last_update = millis(); // Call at e of printing to have event e-start spacing
  }
  if(stepper.getStepsLeft() == 0){
    dir = !dir;
    goTo((dir ? 1 : -1) * 180.0);
  }
} // #loop

CAD

Series Elastic Actuator

Test Box

During our visit to the Children’s Museum, we found that we were quite limited by the temporary structure supporting the main mechanism and by the instability of the Arduino-Raspberry Pi connection.  Additionally, the rail system of the project would not always allow for free movement of the main stepper motor.  Overall, we observed that children were very interested in peering over at the project, although they were quite timid to do so.  We believe this was because the project did not exactly seem the most inviting or stable in structure (parents tended to discourage the children from touching or coming closer).  Children that did come closer to the project were most drawn to looking at and carefully feeling the fluffy texture of the artificial cloud.  We were surprised that the most interesting piece of our project seemed to be the cloud’s texture, rather than movement across the frame, though this may be because of the environment we were in (near the make shop, where settings are very hands-on).  Many of the children in the nearby area were also not yet walking, while we believe our project may be best suited for children who are slightly older.  Further debugging the cloud movement is paramount for visitors to further understand and perceive the “magic” in our project.  Adding motion in the y-axis will also help to achieve these goals.  Initially we felt the the structure containing the project was not as important as other components, but post-museum visit we understand that it is important for the project to seem safe and inviting, such that we can then more deeply observe visitors’ behaviors.  We have also realized that because of young children’s inherent desire to touch (fluffy) things, it may be best to redesign the container to be open in the front to encourage deeper interaction and to explore a second tactile experience within our project.

Revision Plan

Currently there are plans to redesign the rail system to be more robust and reliable.  We feel that the fundamental experience that was originally planned may not need to be drastically modified.  However, progress of the project was not quite as accomplished at the point of the museum as we would have originally thought due to unforeseen bottlenecks.  From museum observations, it is thought that we should forego the clear acrylic sheet that would serve as the “window screen,” so children can be free to touch the moving clouds.  We feel it is unnecessary to add additionally objectives to our plan (rather, we will further detail the original plan), as not all objectives have yet been completed.

Other Files:

The revised task list can be found here

Arduino Code: demo

Raspberry pi Code: reach_for_the_sky

(descriptions for files can be found in the  README file)

During our visit to the Children’s Museum, we discovered some limitations of our project. Firstly, the camera didn’t track the ball well due to the change of light. It requires calibration of the color threshold every time when the lighting condition is changed. Secondly, the pulley system and the motor were not functioning well, making the goalie not able to react quickly to the ball. Third, the programmed goalie motion was not responsive or too simple.

Despite the limitations, children and adults actually enjoyed the project in some ways. Mostly adults and elder children were able to notice the purpose of the project. For younger children, they usually didn’t know what the machine does initially. Once they realized it was a soccer or hockey game, they would try to shoot the ball. They also tried to “kick” in different directions or used the side rail to reflect the ball and fake the goalie.

However, one aspect of the interactions surprised me. Children actually “kick” the ball very gently. Initially, we thought they would try as fast as possible, even throw the ball to the goalie, however, they threw very gently. Some younger kids were not able to make the ball to reach the goal. Another aspect was that many children felt the game was too easy. They actually wanted to have a challenging game. Instead of scoring for most of the time, they would enjoy more if the goalie was able to block more. Also, some children tried to “cheat” in the game. They placed the ball right in front of the goal and poked it, making the goalie not able to react to the shot.

To improve the  interaction with the project, we could firstly aesthetically improve the goalie and play field. Currently, the goalie is representative of what it does, but hardly looks like an actual goalie. Additionally, there is no indication of a ‘D’ or where to place the ball to start (hence the children ‘cheating’ the game). The goalie could be made to look more like a human than a simple object, and arrows could prompt the direction of motion.

When the ball cleared the goalie, there was no confirmation that the player had actually scored without observing the balls placement in the goal. To improve this, we could install LEDs that shine when the user scores to remove any ambiguity. These LEDs will be signaled when a sensor detects the ball’s presence inside the goal.

Lastly, another feature that could be implemented is a simple obstacle the player must navigate the ball through first to then get to the goal, for example a horizontal beam placed across the playing field. This will not only reduce the incoming ball speed giving the goalie more time to react but also increase the challenge and interactivity of the game.

Revision Plan

In order to solve the camera tracking problem, we will implement an auto-tune function for the tracking. So for each time it starts, it searches for the ball and extract the color and uses the new color as the threshold for this run. Secondly, we might need to try different pulleys or redesign the pulley system. Also, we are going to try batteries since the power outlet is not able to supply higher power to the motor. Third, we are going to test using the motor encoder to track the goalie’s position instead of the two switches and reduce the camera tracking latency to make the goalie more responsive.

We think the fundamental experience was quite successful during the visit, so we are going to keep it as what it was, a table soccer game.

Project Revision Schedule

Demo Video

VIDEO

Justin Kufro

Oshada Gunasekara

Analysis

During our Children’s Museum visit we discovered that our magnet configuration was mostly sufficient to keep the car on the wheel. One limitation was that if the wheel was spun too fast, then the car would not be able to hold on. Another limitation was that our motors almost constantly stalled due to the magnetic force required to keep the car on the track. This ultimately caused faster usage of the battery and caused the car to not be able to move freely about the wheel. We imagine that if the car could drive on the track it may have trouble staying centered / avoiding bumping the sides of the track.

There are a few modes of usage for the project where children and adults found moments of delight with the project. Some children where especially interested in spinning the wheel, regardless of if the car was on it or not. Some children were interested in pushing the car around the garage floor on their own, entirely without the wheel. There were both children and adults who found a moment of delight in placing the car on the wheel and feel a satisfying magnetic click as it adhered to the track.

The visit changed our perception of the project in that the wheel isn’t completely necessary to have moments of delight. This does not mean that we want to get rid of the wheel, rather that we should consider supporting additional modes of usage with only the car.

https://www.youtube.com/watch?v=lNYcGvBiwrE

Revision Plan

The main resolution to our technical limitations is to redesign the car to better move about the wheel. This means ordering more powerful motors, making the car lighter, centering the drive wheels, and placing caster balls on either end of the car.

The redesign of the car changes the fundamental experience in that we now expect the geared-down motors to cause the car to move slowly about the track. We accept this as a good change because it better exaggerates the two modes of interaction that we intended with the car & wheel: users helping the car right itself to the top of the wheel, and users turning the wheel to cause the car to continually try to right itself.

We also plan on minor redesigns of the wheel. These include making the track less polygonal with better supporting structures, and adding a passive brake that keep the wheel from continually oscillating.

<link to detailed task list>

We already emailed our second order form that includes the parts necessary to make the second revision of the car.

BOM_V3

Purchasing List

Drawings:

CAD_FILES

BOM