Carnival Ball!

Published December 15, 2017

This is a post about the last stage of our arcade / carnival game construction and coding.  For a bit more about the project’s conception and prototyping, look here, and for our planning process, look here, and for some on our fabrication, look here.

After last week’s user testing session in class, April and I focussed our last week of work on improving two aspects of our construction and design:

  • Physically, it was important that the ping pong both didn’t bounce out of the goals and reliably returned to the players.  Because ping pong balls are designed to bounce (and do this quite well), this proved to be more of a challenge than expected.

  • In terms of the code, it was necessary that the goal sensing/ score detection worked without fail.

Physical Construction:

At first, I made several attempts to design goals which worked reliably (didn’t allow bounce-out) from 14” luan.  My process involved mocking up the panel shapes with cardboard, cutting them out of luan, and gluing them together.  The angles were designed to redirect the forward motion of the ball downward.  Despite my cardboard mockups working quite well, however, luan ended up being much too spring-y of a material to reliably avoid having the balls bounce out.  So, I cut our final goals out of cardboard, which has just enough sponginess to avoid the balls bouncing out.

Goal sensing:

Piezo sensors proved too noise-y to reliably sense a single goal.  So for our final version, we returned to light-sensitive resistors as a way of sensing goals.  We had moved away from this method for cost reasons, as the light sensitive resistors embedded in color sensors were quite expensive but having decided not to sense ball-color, the light sensitive resistors themselves were both reliable and cheap.  For each goal, we positioned a white LED aimed at a LSR hooked into our Arduino’s analog input.   The ball would fall between the LED and LSR and create a drop in voltage seen at the analog input pin.  In code, we used a peak detection method described here to sense this drop as a score for either the red or blue team.  Because the mounting for each goal was slightly different, we had to individually set the threshold values for the six goals.

Serial Communication between P5.js and Arduino:

Our final challenge this week was developing a protocol for communication between the p5.js sketch and our Arduino.  Our midterm project used a reliable two-way Serial protocol with a handshake method (as described here) to send scores from the Arduino to the p5.js sketch and to reset the score.  For our final, however, we had the added element of setting each of the goal states as either “red,” “blue,” or “off.“  This would indicate that a goal could be scored upon by the red team, blue team, or neither, respectively.  At first, we hoped all of the logic behind changing goal states could be handled on the p5.js side (where the rest of the game-related logic lived), and goal state information would be sent to the Arduino as a string.  In the Arduino, the goal state would be used to determine which team’s score was added to when a goal was made, and which LED’s were turned on.

This protocol worked quite well in isolation.   From the Arduino Serial Monitor, we could send strings of “gRRBBRB” to set the goal states to red, red, blue, blue, red, blue and the Arduino would switch it’s internal scoring logic as well as lighting accordingly.  However, once this was incorporated with the rest of the p5.js serial protocol, we began to notice strange behavior: goal states would be sent from p5.js to the Arduino but not change the goal states, or other failures would occur.  I believe this is due to the p5.js sketch timing – and the fact that asking the Arduino for the score (by sending an “x” serially) could happen in the middle of sending a goal state update.  I am reworking this protocol to avoid this.