In feedback from our first sprint, we were encouraged to decide a specific application and user experience for the robot.Early in the second sprint, we decided to focus on prospective students using the robot to visit the Olin Library. Realizing that the experience would now be about interacting with Olin Students in the library, We made some modifications to our product goals, prioritizing web access and a smooth end user experience over having a VR viewer and immersive experience - which our last sprint had taught us would be extremely difficult.
In order to have the experience we wanted, we knew our robot would have to be deployed in the library for extended periods of time without our intervention. As such, it had to be robust. Thinking that it would be difficult to simultaneously chase reliability and new features, we decided to deliver our mimimum viable product by the end of our second sprint.
We started our second sprint sketch modeling. Because so much of our new experience was how people interacted with our robot, we wanted to make sure our robot was something olin students wanted to interact with. Our sketch models helped guide us in figuring out what made a robot cute and approachable.
Our head at this point in the project consisted of a lasercut head attached to a center gimbal box through two coaxial servos for head tilt. The PVC ‘Neck’ was supported by a lasercut support structure with a servo in the base driving the head and neck’s pan functionality.Our body had two vex robotics track systems connected to 6 volt DC gearmotors we found in the stockroom, with a floating tensioner to ensure we could keep the belts tensioned.
Because we no longer needed to be immersive, we dropped one of the raspberry pis and cameras from our planned control system, but kept the architecture mostly the same as it had been in sprint one.
By the end of this sprint, our controls system reflected our planned final controls system in most aspects. There were some minor differences - we were using a USB webcam instead of a raspi camera due to lead time and a computer instead of a phone because it made modifying our display website easier. We did feel that by the end of this sprint we had elminated most of our control system risk.
Sprint two taught us that we had to design our system to be mechanically serviceable. We had to pull apart the glued-together head three times during assembly to correct mistakes, causing lots of issues.
Going into sprint three, our largest standing risk was reliability. We were also worried about better defining our user interaction with the robot and, given that the sprint had involved a huge time commitment from the team, team burnout. For our next sprint, we wanted to focus on creating a useful and pleasing experience for the user.