Welcome back to the MSP+Sphero Pilot! We all hope you had a great holiday weekend and fun 4th of July!
Hopefully you've been following along so far and checking out the MSP's Hackster.io and Github pages to follow along with the progress.
Also, if you’re interested in becoming an MSP yourself, remember to visit our website. Application deadline for the 2016 MSP Program ends July 15th!
Let's check out Group A's progress.
Technology Toolkit: Sphero, Azure
Hackster.io
Github
Where did I leave off last week? Last week I leveraged the sensor streaming to read and analyze IMU data.
What have I implemented/changed/updated/improved/etc. this week? Unfortunately I have to abandon my idea of using soft and hard taps to replicate a dot or a dash because there is no way to see how hard a collision is with the Sphero. In addition, as I was testing the concept I quickly got sore knuckles from tapping on the Sphero hard enough to register a collision. Instead I’ve decided to represent a dot with a roll to the left and a dash with a roll to the right. This is why I investigated the IMU sensor to see which element I would need to do this. I decided on using the roll angle to check for left and right rotation. For this to properly work you must disable stabilization. There is no built in method so you have to actually make a call to the Sphero to manually set that.
What I’m looking to accomplish next: Next week I’m hoping to go through the Azure part of the
project where I set up a database and start communicating with other Spheros!
Technology Toolkit: Sphero, Azure, Windows 8
Hackster.io
Github
Where did I leave off last week? Last week I left off with the front end nearly complete. I had also gotten the Sphero to connect to the game using node-web kit; that was probably the biggest hurdle of all. I thought last week that this week would be more oriented around connecting to Azure, but it turns out that I spent most of my time this week working on the calibration of the Sphero.
What have I implemented/changed/updated/improved/etc. this week? This week I worked on calibrating the Sphero. It is very simple if you want the user to have to calibrate the Sphero themselves. By this I mean you can use the command startCalibration, which requires the player to manually rotate the Sphero to the correct direction. However, with the following code snippet, you can rotate
the Sphero, and then later use the setHeading command to lock in that rotation.
What I’m looking to accomplish next: Next week I will actually be trying to connect the game to an Azure database. However, I’m not sure how far I will get because I do have an exam! Thanks for checking in!
Technology Toolkit: Sphero Robotic Ball, Sphero.js SDK, Apache Cordova, PeerJS, Microsoft Azure
Hackster.io
Github
Where did I leave off last week? Last week we had basic messaging, driving, and color controls in place, but no way to calibrate the Sphero. These commands were also all one-way and only supported one client.
What have I implemented/changed/updated/improved/etc. this week? This week I made two major changes: the complete implementation of the communications schema that I defined last week, and state syncing between multiple clients. Besides these two large changes, I made innumerable bug fixes and security improvements. As I can’t talk about even half my changes here, you can check them all out on my share-sphero-client and share-sphero-server repositories.
Implementing Multiuser: When implementing multiuser, it helps to think about the problem on a higher level first. Every connected controller has to display the same information. This means the message display function should be generalizable between the client and server.
Here’s that function:
On the server we additionally validate each message and broadcast it to the other clients. We do validation by checking that all messages contain the required fields in an allowable range and are permitted for the current state of the sender.
Message broadcasting is then as simple as: 
What I’m looking to accomplish next: I hope to polish the implementation of all the logic and begin designing the UI.
Click HERE for a demo video of the real-time sync between multiple users
Technology Toolkit: Sphero, Visual Studio
Hackster.io
Github
Where did I leave off last week? Last week I started working on a website to allow users to enter coordinates to direct the Sphero. This provides a front-end interface to interact with the Sphero Director application.
What have I implemented/changed/updated/improved/etc. this week? This week, I added to the website I began working on last week to help users enter coordinates to direct the Sphero. The user now sees the entered coordinates appear on a coordinate grid on the bottom part of the webpage. In addition, a line is drawn between coordinates in the order they are entered and tooltips appear when the mouse hovers over a point.
A screenshot of the improved webpage. Entered coordinates are plotted with lines drawn between points. Tooltips also display the coordinates of a point:
I have also started to integrate the site with Azure. I am looking to be able to host this website on Azure to be easily accessible.
My Azure dashboard for hosting the Director website:
What I’m looking to accomplish next: Moving forward, I will continue to work on the website integration with Azure. Then I will work on connecting the coordinates entered with the Sphero movements in the app.js file.
Technology Toolkit: Sphero, MYO, Windows Phone
Hackster.io
Github
Where did I leave off last week? Last week, I got an Azure account and started following directions on http://bit.ly/1ywVXLL. Unfortunately, I wasn’t able to get the ball rolling still via phone. I was able to run node.js via Azure but not with Windows 8.1 phone using JavaScript. I also connected Azure via local Git account.
What have I implemented/changed/updated/improved/etc. this week? This week, I broke down my project into three different parts: connecting cross-platform devices using the phone as the medium, creating my engine to dynamically generate games on the fly, and the UI. With only 2 weeks left in the program, set myself up for scrum management with different tasks. Because I was wasting too much time to find a way to use run node.js on the Windows phone, I decided to start with the game generating engine. From one of my previous weekly updates, I stated that I found a JavaScript library that reads the frequency from any audio files and spits back out the values. Using the library, I set the frequencies to certain ranges.
This is where things got tricky. I would read the mp3 file and set the frequency ranges and allocate those ranges to certain colors that the Spheros would react to. The game was generated. But when the music plays, I would have to sync that data with the music. Because this is such a precise game, it was very hard for me to sync it perfectly. Also, not only would I have to sync it, I would have to detect whether the movement made by the MYO was on point perfectly, mildly, or not at all. This was also another point in which things got tricky. Sometimes, the MYO would have latency. The directional movements would sometimes either be put into queue before being read or disappear into thin air. As more bugs arise, the harder it seems for the Sphero to have perfect movement.
It was time to pivot.
The special uniqueness of my app was the fact that the user could dynamically create any mp3 file on the spot. Instead of having the entire game full of MYO movements, I would make MYO a part of the game. The game would now consist of tapping on the windows phone based on what is required by the game. The MYO would kick in at random moments throughout the game where the
game would tell you to do certain movements where the users would be “fist bumping” into the air. Now the game is a modern EDM music production simulation game where the user would act as a DJ and would be on a Launchpad synthesizer where the user would tap on the screen and fist bump when needed.
What I’m looking to accomplish next: I think this would appeal more since now it has a theme. I didn’t completely scrap my last project but now it’s time to pick up the scraps and glue them together into something else. Behold for a prototype by the end of this week!
My app that pivoted from using MYO for the entire game, using it for certain movements generated within the game. The rest would be a tapping game directly on the Windows Phone.
Roll On