The (volunteer run) codeclub we run has kids of different age groups and aptitudes (more importantly) within those age groups which attend. The kids work on a lot of Scratch, micro:bit, electronics using the micro:bit and to some extent Makeblock range of robots and in the coming future GoPiGo’s (which we’ve obtained). You can check out the development tracks we work on at https://www.kidzcancode.com and the codeclub website at http://altonanorthdojo.com.
I happen to be quite conversant with unix/linux/*nix which means i am quite comfortable managing these devices using the CLI (and the GUI which i rather not use) and like keeping them updated. So the concept or having an isolated device that doesn’t update gets doesn’t resonate with me at all, which is another reason why the bloxter remote device concept isn’t working for me on another dimension. It’s probably a moot point given that you can see it clearly working for other customers who don’t want to be bothered with setting up Raspbian for Robots. I can definitely see how bloxter makes sense for those who can’t be bothered with setting up/managing their robots which is definitely not me (fortunately or un-fortunately).
As the codeclub lead (and customer) i would like to be able to get my older students us the python based API’s and get the robot to move around but also have the flexibility so that younger kids (also in the same class) can use bloxter when they want to at different times during the weekly classes. Is it reasonable to expect anyone to keep opening up the robot (mind you it’s not easy to change the SD card during class, i need to pull out the wires to the motor and change the SD card something i wouldn’t want to be doing every class)…i think not. We are volunteer run so have no $$ to cover operational costs other than the rare grant we might apply for.
So if the product feature requires one to re-configure the robot every time the use case changes (older kids programming v/s younger kids programming) then that would imply that the GoPigo is a fit for classes where the age groups don’t vary as much but not a fit for codeclubs or coding groups where the variance in age means that we have to cater to many different age/groups interests with very limited resources.