I run a codeclub in melbourne and intend to use the GoPigo to get the kids working with advanced robotics including programming in python.
While i like the idea of DexterOS i prefer being able to manage the OS via the CLI and keep the OS updated. Is there a way for me to “git clone url” for Bloxter and set it up for use on the Raspbian for Robots OS? Am using GoPiGo3 in class btw.
I don’t mind the technicality. Keen to make sure i have a manageble (SSH, CLI, etc.) ecosystem.
Unfortunately no, you can’t set up a Bloxter (DexterOS) environment just by using
git clone and then firing it up. We thought that having an image that doesn’t have to be set up / managed in any way is far easier for every hobbyist.
Thanks Rob. That’s a shame. I would think you guys would have made the code/project available for download so that those who needed the flexibility (Raspbian for Robots) are able to deploy the Bloxter on it and serve both the ends of the market.
The only option then for those who want to teach advanced robotics and basics of robotics using the GoPiGo is to have two sets of devices i.e. one with SD cards with bloxter and the other with SD cards for Raspbian for Robots.
You guys should really consider making the bloxter project/code part of Raspbian for Robots so that the GoPiGo can serve both ends of the market. Else you put the customer (and their investment) at a disadvantage.
This approach is what a lot of other manufacturers use i.e. Makeblock offers Makeblock 5 which allows you to code with blocks or if you want to (for advanced users) write Arduino C based programs using the same user interface. That way the teachers are not forced to purchase two sets of robots to educate kids at different ends of the (learning) spectrum.
You can still use the same GoPiGo for students who need blocks and students who don’t.
- DexterOS uses JupyterLab and Jupyter Notebooks now, with a Python3 kernel. It’s not limited to blocks
- If you do want the freedom of Raspbian for Robots, then it’s just an SD card away. Swap the cards, and the same robot is now in the other “mode”. So you can totally use the same hardware from one class to the next.
PS. we are not planning on moving Bloxter to Raspbian for Robots in the near future.
Am sure this is a product roadmap decision to not allow Bloxter to be used on the same SD card as Rapbian for robots.
If you try running a class for 20-30 students, pulling cables out of the GoPiGo midclass to switch SD cards, you’ll realize how much fun that is (and how much that reduces the life of the hardware as well).
why would you switch from one to the other in the middle of a class? I am genuinely interested in knowing more about your use case. So far, we’ve only had groups that use the robot for part of the year, then another group for another part of the year, meaning the SD cards get swapped once a year.
I would appreciate it if you could tell me more.
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.
Thank you for taking the time and making me understand your particular circumstances. A lot of our customers are not at ease with *nix, which is the main reason we developed DexterOS.
While not a perfect solution for you, may I suggest a couple of things until we can revisit whether we make Bloxter available to all?
- DexterOS does support Python and not just Bloxter. You can serve your Python-oriented kids with DexterOS too. We offer Jupyter notebooks, but you can also create straight .py files if you prefer. The kids/students/learners have access to a terminal if they want it, but they won’t have root access.
- Raspbian for Robots does offer Scratch as an alternative to Bloxter.
We will keep your use case in mind for sure when we get back to Bloxter development. And again, thank you for sharing your thoughts and situations. It will definitely help us in making better business decisions.