Picroft Survey 2018 – Results and Roadmap implications

Originally published at: http://mycroft.ai/blog/picroft-survey-2018-results/

A huge thank you to the more than 200 people who took a few minutes out of their busy day to respond to our recent Picroft Survey. As promised, we’re sharing the full results of the survey with you - in both graphical and machine readable format - and discussing what they mean for our Picroft Roadmap.

Why do we need a Roadmap?

Roadmaps are super important in product management and technology planning. They help us understand dependencies, optimize sequencing of activities and assist in planning critical resource availability. There are several inputs to a technical Roadmap;
  • customer and user feedback
  • emerging technology reports and industry information
  • internal error reports and monitoring information
  • strategic plans
And that's where the Picroft Survey comes in. To better understand what our priorities should be for Picroft, we wanted to better understand how our Community is currently using Picroft.

So, let’s step through the results!

Survey results

Where are you on your Picroft journey?


Raw data


This question was designed to find out where the Community was on their Picroft journey so that we can target effort and resources for the biggest impact. What we expected to find here was that there would be a large cohort actively using Picroft, but not wanting to do more with it, and perhaps another cohort who had heard of Picroft but hadn't done any planning yet to build one. The results turned this thinking on its head. Instead we found two large cohorts who are likely under-serviced at the moment;
  • Those who have a Raspberry Pi and are planning to install Picroft
  • Those who are already up and running with Picroft and want to extend it further

Key outcomes

  • We need to prioritize support for hardware like Google AIY Kits and other hardware that extends the Picroft platform
  • We need to look at ways to get people "up and running" quickly and easily with Picroft; we've previously had internal discussions around whether we should offer a "pre-made" Picroft kit with speakers / microphone that are known to work well.

What model Raspberry Pi do you have?


Raw data


Again, some of our early expectations here were invalidated by the survey data. We originally thought that the largest cohort here would be the RPi 3, with perhaps an emerging cohort of RPi 3B+ owners. The RPi 3B+ cohort was much larger than we anticipated. Interestingly, we also anticipated that the cohort with older models of RPi - RPi 2, Pi Zero etc - would be a lot smaller. Unfortunately there's not going to be a lot that we can do for people with older hardware - it simply doesn't have enough compute power or RAM to be able to run the Mycroft voice stack. Another interesting finding from this question was found in the free text responses. We saw quite a few folks with Odroid devices and even an ASUS Tinkerboard.

Key outcomes

  • A unified image that runs on both RPi 3 and RPi 3B+ needs to be a high priority
  • We need to be as clear as we possibly can about the Picroft hardware requirements; older RPi models aren't powerful enough to run the Mycroft voice stack
  • The single board computing landscape is fragmented; there is wide diversity of devices - we won't be able to support a wide range of them.

What do you think our priorities should be for Picroft?

Raw data


This was an incredible eye-opener. We knew that the demand for an image based on Raspbian Stretch Lite was beginning to grow; we didn't realize it was this strong. The desire for integration with other devices also mirrored the first question around where people were on their Picroft journey. We were also a little surprised that the priority ranking for better microphone support wasn't a little higher; microphone issues the highest issue by volume with Picroft hands down - literally 8 out of 10 issues that people report with using Picroft are related to symptoms such as;
  • microphone not recognized
  • microphone volume to low
  • microphone cuts out after some time
We were also concerned the Picroft documentation wasn't quite up to standard - although this doesn't appear to be as much of a concern as being able to support RPi 3B+ and extend Picroft.

There was also excellent value in the free text comments. Several key themes emerged here including the desire for better foreign language support. This is difficult to achieve, as covered in this blog post, however it was great to have this requirement again validated. Many of the comments requested specific hardware support for certain microphone and speaker models; again something we want to build into the next image. Again, the desire to extend Picroft with third-party hardware such as Google AIY was expressed multiple times. We also had several people mention they would like display support for the Picroft - the ability to express facial gestures similar to the Mark 1. Others mentioned closer integration with platforms like Home Assistant, Open Elec, and Magic Mirror. We’ve had some internal discussions already about reaching out to these communities to see if we can have more fluid experiences for people who want to use these with Picroft. Others expressed a desire for Picroft on other operating systems - such as Ubuntu Core. This will be more difficult to achieve; as it requires not just building an image but also supporting that image. Ideally we just want to be supporting one single unified Picroft image.

Key outcomes

  • Being able to support a wider range of microphones and speakers "out of the box" needs to be a priority; especially commercial grade microphones for superior sound
  • The ability to have better "out of the box" support for hardware such as the Google AIY kit
  • The Community has a strong desire for wider language support; this is going to take some time to deliver but is definitely something we want to do
  • Working more closely with related communities such as Home Assistant, Open Elec, and Magic Mirror for closer integration

In conclusion, this was a very useful exercise for us. Thank you again for taking the time to provide your feedback, and do feel free to have a read through the data and share your insights.



This is really awesome!


This kind of detailed feedback and thorough analysis is invaluable as we decide the directions of future efforts. Thanks to all!


Any chance these are killable with the same silver bullet? According to https://docs.snapcraft.io/core/install-raspbian, snaps are available on rapsbian (plus lots of other distros). The official image produced by the Mycroft could be either Snappy Core or Raspbian, with the other trivially support… plus easy install on desktops.

Unsure how feasible this is, but in my head it sounded like a decent theory. I know there was some effort to produce a snap a while back (GitHub - MycroftAI/snapcraft-mycroft-core: This project is for building mycroft-core snaps), so potentially there were/are pitfalls I’m unaware of.

1 Like

Excited to see the data. Thank you for getting this together, Kathy.

1 Like

Yesterday HassOS got released!

Now you might think, what has HASS todo with Mycroft other than the amazing work @btotharye has done connecting the two. HassOS basically is the new system based on Buildroot (I mentioned Buildroot earlier on the Mattermost servers as the best OS for Picroft in the future before).

Hass.io OS based on buildroot. It’s a hypervisor for Docker and supports various kind of IoT hardware. It is also available as virtual appliance. The whole system is optimized for embedded system and security. You can update the system simple with OTA updates or offline updates.

Now here comes the beauty; It’s a hypervisor for Docker and supports various kind of IoT hardware.

So “we” can easily fork it, disable the HASS package and insert a new Mycroft package that pulls in the new Docker from yet again @btotharye

It supports all RPi’s including the new 3B+, so all the development of the OS in relation to the hardware to run it itself can be seperated (or even fully left at the HASS guys) where development of the Picorft can just be migrated to the Docker image (or a seperate Docker including the Enclosure stuff)

If you look at the “future” section of the blog post;

> We have already started on making HassOS compatible with all kinds of hardware and are currently aiming to release support for new devices every 7-14 days and keeping this up until we support all major IoT boards.

So in the near future you could run Mycroft on a lot of other boards than RPi alone!