This past February we posted about our progress during 2016 and our plans for 2017. In that post we identified two key goals for 2017, to be completed by SyndCon in August. Those goals were:

1. Finalize the hardware design needed to address the key feedback from demos at SyndCon 2016.
2. Run a private beta test program for Holoseat to vet the design before releasing version 1.0.

So how did we do? We got back from SyndCon a few weeks ago and I am happy to report it was a complete success. But I must admit, the way we achieved that success and the Holoseat we took to SyndCon were quite different than what I envisioned when we wrote that post back in February. To understand why it is best we take a look at each goal one at a time.

Goal 1 – Finalize Hardware Design

Two pieces of feedback drove the hardware design work called for in the first goal. The first piece of feedback was an unanticipated need to tweak Holoseat’s settings every time we changed players or games. One setting in particular, trigger cadence – the pedaling speed required for Holoseat to recognize a player is walking, took half of the demo time to dial in during most demos. Our intended solution was to migrate from an Arduino controller board to a significantly more powerful one, the CHIP Pro.  This change would enable on board management of player specific profiles. These profiles would capture each individual player’s settings per game enabling players to switch out Holoseat settings as easily as they switched between games.

The second piece of feedback driving Goal 1 was a desire for faster response times from Holoseat.  Take a look at the video below to see the v0.3 response times for yourself.

While not captured in the February blog post, we had a line of research lined up to address this request.   But, we prioritized this research lower than incorporating the new controller board. The irony of this decision will become apparent in Part 2 of this series of blog posts.

Goal 2 – Run the Beta Test

How would you fund the development and manufacturing of a beta design for a new hardware project? If your answer is “KickStarter!” you are very close to where we were in our thinking last February.

Sadly, running a successful crowd source campaign takes more time, and a greater social media presence, than we had in 2017. Thankfully we came to this realization (through careful research) before we got too far into the year. At the time we thought we were completely blocked on this goal.  So, we spent most of 2017 assuming we would have to wait at least a year before we could engage outside players as testers.

But in agile projects like Holoseat, being blocked does not mean things are hopeless. Blocks are meant to be resolved and once they are you can get back to working on implementing your plan. Sometimes the trick to resolving blocks is to recognize how a completely different solution, one that is not blocked, can achieve the stated goals.

Stay tuned for Part 2 where we share what actually happened in 2017 and Part 3 where we lay out the 2018 plan, which has us coming full circle in our quest to find the right controller board for Holoseat.

The post There and Back Again: An OSHW Project’s Tale – Part 1 appeared first on Model B.

SyndCon was amazing! Our fellow Syndies gave us great feedback and encouraged us to bring a Holoseat to market as soon as possible (some even volunteered to help with Holoseat development and testing). Needless to say, we came home with the wind at our backs, but work and life made it hard to fully capture that energy and we hit a snag in the following sprint. Still, we closed the year strong, updating our open source documentation and getting v0.3 certified as open source hardware.

Holoseat v0.3 OSHW Certification

So, what’s in store for 2017? We have two related goals for this year. The first goal is to finalize the hardware design for the Holoseat to support the features on our long term roadmap. The second goal is to run a private beta testing program.  Bryan and I are committed to delivering v1.0 compatible hardware to our beta testers so they can get production level features and support just by upgrading their firmware. This commitment is why it is so important that we finalize the hardware design this year.

While our first sprint of 2017 has not quite started yet, we have not been idle. Bryan and I have spent the first part of the year researching and testing new controller options for Holoseat.

From the beginning, the Holoseat Controller has been based on the Arduino family of development boards, starting with the Duemilanove to the Leonardo to Adafruit’s Feather boards.  Arduinos have served us well, but we are looking to much more with Holoseat and we need something with more power and more options for interfacing with the world. Today I am happy to report that we have selected Next Thing Computing‘s C.H.I.P platform, specifically their Chip Pro. We already have the dev kits in (shown below) and are super excited to be working with this exciting new platform.

CHIP Pro Dev Kit

Want to get involved?  Head on over to the project site and leave us a message on the forums.  Want to keep up with all things Holoseat?  Subscribe to our mailing list.  And stay tuned for the details of the first sprint of 2017.

The post From Arduino to CHIP – Looking Back on 2016 and Kicking Off 2017 appeared first on Model B.

With parts in hand, I spent most of the day Saturday at Dayton Diode working on implementing the basic walk command. This feature recreates the functionality of the original prototype, simply giving the user the ability to walk in video games by pedaling a bike or elliptical machine. In addition to building the prototype, I also took some time to experiment with documenting OSHW projects. Using the Flickr app on my phone, I took photos of each step (making sure to enter useful titles and descriptions for each photo) and uploaded them to an assembly instructions photo set in Flickr. This let me quickly and easily take notes as I worked which I then copied and pasted into the Assembly Instructions in less than half an hour. Not a bad investment of time to get an entire weekend’s work documented.

By the end of the day Saturday I had things working well enough I could play games. So I went home and “tested” the Holoseat. By which, I mean I played several hours of Star Wars The Old Republic using the new Holoseat. I was basically pleased, but I noticed a couple of problems.

When I got up this morning, I decided to have a look at the previous night’s bugs. The first thing I did was to add serial debugging using this information on serial i/o (note the special case for the Leonardo) and this information on #ifdef (the #ifdef trick is something we use n C all the time, so it was nice to see it works in Arduino). I should also point out during all of this work with serial communications on the Leonardo, I stumbled upon a little oddity of the Leonardo. It turns out the board takes on two different COM ports in Windows. The first is the bootloader and is only visible when the board first starts up and when it is loading code. The second is the COM port of the virtual serial interface used when the board is running. This second port does not show up in my list of printers/devices in Windows, but does show up in the Device Manager. This second COM port is the one which the Arduino IDE should be set to use so it can automatically upload code correctly and the Serial Monitor can connect to the Arduino.

After I got the serial debug statements working, I found a number of bugs (I will spare you the gory details, but you can take a look at the source code in the SVN repository if you are interested). Thankfully, I was able to address all of the software bugs I found, thanks in no small part to the ability to send debug statement to my PC.

With the software bugs out of the way, I turned my attention to the system level bugs from the night before. While working on one of the issues, I had an inspiration to invert the walk speed calculations from counting steps to timing steps. This let me increase the frequency at which I poll for walking speed so the system can stop walking in under a second as opposed to the original code which could take as much as a second. Testing tonight shows this level of response in stopping is pretty close to what we need (if not exactly what we need). I was also able to deal with an odd stuttering on the first step in a walk cycle, which only leaves one issue from the first night of testing.

Considering the reviews of the reed switch said the magnet was too weak, this is hardly surprising. To be left with only this issue open after the first weekend’s work is great progress. The rest of the week will focus on testing to make sure the basic walk functionality is robust. Look for another report next weekend, when I should start working on the next feature.

The post Assembly has begun! appeared first on Model B.

Since I am an Amazon Prime member, I often turn to Amazon for my initial search for almost everything. And, it should come as no surprise that there are plenty of Arduino related products on Amazon. As I was searching for prototype shields, I quickly came across this one (see image below) from SainSmart. It looked like a pretty good deal. It’s a good price and includes jumper wires for use with the breadboard.

As I wrapped up the BOM and I continued looking around Amazon, I came across this Intro to Arduino Kit which includes a Leonardo board (see the Detailed Design for info on why we are moving to the Leonardo). Now this was very tempting. It includes pretty much everything from the BOM plus extra stuff for later experimentation, and at a nearly $20 savings over ordering components individually. Needless to say, I was pretty excited. But, I am thorough shopper, and truth be told I was not familiar with SainSmart. So, I decided to do some Googling to make sure this was really as good a deal as it seems. Boy am I glad I did.

At first, I didn’t find much info one way or another. There were a couple of somewhat negative forum posts which I didn’t find very helpful on their own. But then I came across this thread on Reddit. It looks like SainSmart is not being a good OSHW citizen (note, I have nothing against cloners, but I do have a problem with people not following license and trademark requirements, let alone changing components without proper documentation). Combined with the few bits I could gather from the other forum posts, I just cannot justify going with SainSmart for any components until I hear better news about their behavior with regards to OSHW.

So, back to Amazon and Google I went looking for a prototype shield. The good news is the Arduino team has an assembled shield which Amazon sells. Plus, there is a mini-breadboard at Amazon which looks like it should fit on the shield. A few quick adjustments to the Bill of Materials, and it was done. Now it’s time to order parts. Woot!

The post Bill of Materials drafted, let’s order some parts appeared first on Model B.