The post Our First Delivery! appeared first on Model B.

The post Finally Turning the Corner appeared first on Model B.

Top is picture of SyndCon 2017 configuration and bottom is newly installed 2018 configuration.

The post Look – No more black tape on Holoseat! appeared first on Model B.

Alpha Prototype Progress

First, we’ve got our prototyping done for most of our design changes.  And, we have some nice pictures so you can see for yourself how we are coming along.

The article picture shows our updated prototype setup on a breadboard using the new TRRS cable to connect the controller to the sensor and the new Cherry MX key switch for enabling Holoseat.  Using a network jack (look in the upper right corner) we connected it to the existing setup from one of our SyndCon demo units and I used it for a few hours.  Worked just as smooth as our assembled units, so we know these changes didn’t mess with a good thing.

Speaking of the key switch, did we happen to mention that we’re doing a custom keycap with the holoseat h?  Here’s what it looks like lit up on our couple of test key switches we were trying out:

That covers the main electronics review.  But what about the little bit of magic that pushed our accuracy up to the point where everything smoothed out?  The tone ring has gotten a bit of a makeover too.  We have split it into two pieces.

Tone ring parts, fresh off the 3D printer

Assembled tone ring

Why’d we split it?  We wanted  to have a cover over the magnets so they couldn’t come out.  It wasn’t an issue during the demos, but we felt that was a poor choice to have them pressure fitted like they were long term.  These are straight 3D prints from the drawings, so they’re still a little rough looking.  But you can get an idea for how the final tone ring will work.

Next Steps & Getting Involved in the Alpha

So that covers our progress so far.  But it still leaves quite a bit left to do.  And the majority of the remaining work is less about hardware development and more about getting ready to take on testers, getting our redesigned desktop software into shape, and sorting out a few things on the business side.

Moving forward what we need from those of you who follow this blog is some help.  Here’s a few spots where can make a difference for Holoseat:

• Do you have some ideas for questions we should be asking our Alpha testing users during the test program?  Post them here <link to google form for submitting questions>.
• Enjoy 3D modeling?  We could use your help porting our mechanical designs from Solidworks to  Autodesk Fusion 360.  Our volunteer mCAD modeler prefers Solidworks, but it is not an open platform, so we need to move our mCAD models.  If this sounds like something you would like to help out with, please fill out the volunteer form indicating you want to help with mCAD <form link>.
• Do you have a knack for python and enjoy development? Consider volunteering to help with the desktop application.  Again, the volunteer link is here.
• In the DC or Blacksburg, VA area and want to help with final assembly and shipping?  We’ll take volunteers for that too!  I’m guessing you know where this is going.

TL;DR

We’re behind (no Holoseats for Christmas), but we’re moving forward at a good pace.   We would rather be a couple of months late with a Holoseat you will love than ship something substandard on schedule.

Looking at the novel I’ve just written, it’s time to get back to work.

The post Alpha Status Update 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.