• Author Author: pettitda
  • Date Created: Date Created
  • Views 2637 views
  • Likes 6 likes
  • Comments 17 comments
Related
Recommended

How To Deal with RoadTest Goals That Were Unachievable

pettitda

Shortly after the Raspberry Pi 3 was released, Element14 announced a new road test entitled RoadTest Review a Raspberry Pi 3 Model B !  I was instantly excited.  I had followed the Raspberry Pi project for several years and from all the specifications, this looked to be a fantastic new member of the RPI family.  So, I went to work crafting a project idea to use the capabilities of the RPi 3 to the fullest.  I had recently lost my home and half of it's contents to a flood and most of what I didn't lose was in storage while my family and I lived with my mother in law.  So, doing a full-on electronics hardware project was out of the question.  I eventually came up with what I thought was the perfect project considering the circumstances; one which was almost totally software work.  This would be an excellent way to keep my mind occupied while I waited for my house to be rebuilt.

 

I had been following the Numenta Hierachical Temporal Memory (HTM) project for several years.  I originally read about it in an issue of the IEEE Spectrum.  I knew the project was based upon a open source code base which aimed to simulate how the brains works.  I also knew that the code was successfully learning patterns of data, predicting the next data point in a series, and flagging anomalies in a data set.  What I didn't know at the time was how exactly the code went about learning patterns or what it's limitations were.  Nevertheless, I went forward to describe a project with what I would eventually come to realize were very aggressive goals.  I proposed to build a raspberry pi based computer which would recognize speech and trigger actions based upon that speech pattern. 

 

In a short amount of time, I learned that I had been selected to road test the RPi 3 and a few days after that I received the Pi.  I jumped in with both feet, ordered a USB sound adapter, microphone, case, power supply, and SD card, then started working on the software. Porting the Numenta project to run on the Pi was slow work, but I found the user group on Github to be friendly and willing to advise me on getting it to build and run.  After two or three weeks the project was ported, built, and running on the Pi.  From that point I spent a couple more weeks getting the project updates for building on RPi up to the project standards for inclusion in the main line code.  While not strictly necessary, I figured this was the least I could do considering how helpful the group had been to me. 

 

From this point, I jumped into the examples online to look for a starting point from which to build my project.  I found examples of predicting the energy usage in a gym and similar sets of data which were long arrays of fairly simple data (i.e. a watt-hour reading for energy usage taken every hour for several weeks).  However, what I didn't find was examples of processing dense, complex data such as a person's voice.  Eventually, I came to the realization that the project goals that I had given myself were more appropriate for a PhD student doing original research for a doctoral thesis than for an engineer tinkering with the software on his off hours.  I was seriously disheartened.

 

If you find yourself in a similar circumstance, here's what you should do.  First notify the road test manager of your problem.  Seriously, these people are friendly and understanding and they want to see you succeed.  Second consider how you could refocus the project in order to make it successful.  Talk it over with the road test manager and get their input.  Post a message on the road test area and get feedback from the other road testers.  Perhaps there's an alternative way of looking at the problem that could get you going.  Third, if you are totally up against a brick wall, you may have to abandon the original project and come up with an alternative.  Again the road test manager can be extremely helpful.  Just because your original project proposal is not achievable doesn't mean that you can't complete a perfectly acceptable review of the product.  In the end, the goal is a review of the product which is insightful and helpful to others considering using the product in one of their projects.  Finally, blog about your failure.  The experience you learned in failure may be extremely valuable to others considering similar projects. 

 

I hope my humbling story will encourage you to not simply give up but make the most of your situation.  Happy road testing!

  • in reply to rachaelp

    The FFT route is an interesting one.  There was another example in the project that did just that.  https://github.com/htm-community/nupic-example-code/tree/master/audiostream.  However, it's goal was more nebulous:

    A simple example that streams your mic input into the temporal pooler (TP), and outputs an anomaly score, based on how familiar the TP has become to that particular mic input sequence. Think of it as being able to recognize a song, or become more familiar with your speech pattern.

    The github page for the project now describes the example like this: "doesn't work well, but has potential".

     

    Thanks for your kind words.  We are mostly back to normal now.  We moved back into our house in August nearly five months after the flood.  The possessions are relatively easy to replace, but the peace of mind is much harder to replace.

  • in reply to Workshopshed

    Andy Clark (Workshopshed) wrote:

     

    I agree with Andy, that does sound like a big project.

     

    After two or three weeks the project was ported, built, and running on the Pi.

     

    This would have been a great point for a demo, and write up of your experience in getting complex software to run on the Pi.

    I totally agree with this. A write up of how you went about porting it and the limitations you've just described in what you were able to achieve followed by just running some of the existing examples on it and show how they performed would have been an excellent road test review. I hope you are able to find a way to do this and get it posted up,  as I think it would be really interesting to read about your experiences in more detail.

     

    With regard to what you were trying to do, I guess you could run your audio input stream through an FFT to give you the frequency content for blocks of data and then use how that data changes over time to train your Numentia software (I'm guessing here as I have never looked at this software before). I guess the key here would be getting the FFT right so you had enough frequency bins to adequately differentiate different speech patterns without it being too much of a processing overhead for the Pi. Hmmm, you got me thinking on this one now.... That's me not getting any more work done today image

     

    Finally, sorry to hear about your flood, it sounds like you're getting through it with great support from your family but a horrible thing to have happen. I hope it's all sorted out soon so you can get your life back to normal image

     

    Best Regards,

     

    Rachael

  • in reply to awneil

    I agree with Andy, that does sound like a big project.

     

    After two or three weeks the project was ported, built, and running on the Pi.

     

    This would have been a great point for a demo, and write up of your experience in getting complex software to run on the Pi.

  • I think you misunderstood the purpose of a "road test".

     

    Thinking generically;  not specific to E14:  a road test of a car is a quick try-out - it is not an expedition.

     

    The outcome of a "road test" is an opinion of the car - not a travelogue on your expedition.

     

    So, even if your expedition was not a "success", you can still give a review of how the car itself performed...

     

    Or, in this case, how the RPi itself performed.