I’m interested in including addressable LEDs, I2C OLED displays, sound (buzzers/speakers) to add to the potential outputs available for student projects.
Are there plans to extend XRPCode to support these sort of devices?
Are there ways for people to contribute code?
I could do this in Micropython directly, but I’m planning on using XRPCode/Blockly for first-time programmers in my summer camp.
Thanks,
Wayne Seltzer
University of Colorado, Boulder
Science Discovery
Like you, I have been using an XRP with upper elementary school kids to show how things they are learning in classes connect to opportunities they will soon have. We use MicroBlocks for that work and strongly prefer it over Blockly.
Russell Owen, and John Maloney have developed libraries for the XRP in MicroBlocks that meet most of features that you specify in your request. They are documented on the MicroBlocks wiki:
and
Most importantly, MicroBlocks has a well-established world-wide community that would welcome contributions for learners like ours!
Hi @WayneSeltzer – I concur 100% with @SCSpaeth that MicroBlocks would be your best choice. It is the most intuitive means to learn physical computing because unlike Blockly or any other blocks program for physical computing, it’s the only one like Scratch, where the blocks are LIVE. I’ve used MicroBlocks to program the XRP and it worked great. The only unfortunate thing about the RPi Pico controller is that the BLE is yet to be supported by NimBLE, which is the BLE stack that MicroBlocks leverages, so you have to be connected over wired USB serial while modifying the blocks. ESP32 and nRF52 chips now support MicroBlocks programming wirelessly, using WebBLE available in Chrome. It’s magical. 
Thanks! Looking into MicroBlocks.
However, the plan was to use the XRP CodeEditor for starters, always observing the generated Python. Then, transition to Python only.
Looking forward to seeing the improvements that are in store for XRP CodeEditor / Blockly, and perhaps helping contributing to the project.
If you are an educator and your goal is teaching Python, then Blockly is indeed an oft-used UI for easing into the pain of text-based syntax.
But if your goal is learning or teaching robotics and physical computing, and getting others into it (my goal), then MicroBlocks is a no-brainer. And even though I am only a volunteer, you couldn’t pay me to teach physical computing with any other tool. 
Wayne:
Thanks for clarifying you intentions.
Can you (or any other participant in this forum) help us to understand why Python seems to be a penultimate goal for many XRP users and mentors? Thanks.
TL;DR Learning Python is applicable to many academic and professional roles.
See: The Top Programming Languages 2023 - IEEE Spectrum
I’ve been teaching summer robotic camps for high school students for about 6 years. These are mostly students with no programming experience, but some do.
(These are not the robotics club kids – they don’t need this camp. But some of my students might join their high school robotics clubs after this camp.)
My goal is to introduce students to computer science and electrical engineering, and STEAM in general. I am certain that many students are interested in playing with things that move, make noise, light up, sense their environment, display interesting behavior, etc. and are motivated to learn to code.
Some/most of these students might not be interested in a high school programming class that they perceive as boring or too academic.
I also seek students who are represented across the demographic of their high school. Getting better, but not there yet.
I am most interested in what students do after the camp. I want them to continue to use their robot platform on their own, perhaps as part of school projects. (Of course, the “robot” platform can be used for many non-robotic projects.)
I have taught with:
The RedBot with Arduino has had the best results, but I need a longer camp session to get into the real Arduino programming. One week is tough.
While Arduino is popular (duh!), and it is mostly C/C++ like, “real” projects don’t use Arduino code. (It’s unlikely that a person interviewing for a software engineering job would be asked about their Arduino experience.)
And, of course, it’s easy to add hardware and libraries to the Arduino enviroment.
With XPR, I had hoped to use XPRCode/Blockly as a gentle introduction, but always have students inspect and understand the generated Python. Then, move onto coding directly in Python, perhaps using XPRCode as an assistant.
I’d also like to enable students to add more hardware (addressable LEDs, I2C OLED displays, sound) to the XPR so they understand that what they are learning applies to other physical computing endeavors.
I made this post after I started working on my curriculum and wanted to design a simple “Hello, World” exercise. Blinking the LED, of course. Something to do before we assemble the robot hardware – just the Pico board.
But, the tiny LED on the Pico is not all that fun. So, I thought I’d add a large LED, connect it to the “Extra” connector, 3D print some sort of mount to attach to the XPR. Include some art exercise to create a personalized illuminated badge.
However … I was surprised to find that XPRCode does not include a block to turn on/off a specified output pin. Huh. I should have taken a closer look before I committed to ordering 40 XPR kits for my camps!
So, plan B will cause me to jump into Python coding on the very first exercise.
Maybe that will work out. Maybe it will scare away some of the students.
Or, even better, I learn how to help extend XPRCode and XPRLib to add some more blocks to support add-on hardware. Willing to collaborate and help!
I agree, Python is great language and used in many different fields. It’s a useful real-world language to know.
That said, it may not be the best first programming language, especially for younger learners or those who are already confident with technology. As you noticed, a week is not really enough time to bring beginners up to speed in Arduino C++, and it could be a discouraging experience for some people. Python is more friendly, than C++, but one can still make syntax and spelling errors. Even if your goal is to teach Python, it might make sense to start with MicroBlocks as a warm-up exercise.
Years ago, David Malan revised Harvard’s first programming course for CS majors. Before David took over the class, about a third of the students failed or dropped the class. One of his (many) innovations was to teach the first week of the class and have the first assignment done in Scratch. Incoming students who had learned Java and C++ in high school thought that was stupid – but they did not drop the class. But students who came into the class without any coding were able to succeed in the first assigment, which gave them the confidence to stick with the class even after they switched to C++ and things got tough. The drop/fail rate dropped to well under 10% and, more important, a much great percent of woman and students of underrepresented groups stuck with the course.
I think a similar approach might make sense for a week-long class: start with MicroBlocks and then switch to MicroPython after the first day. (I say MicroBlocks because it’s much more complete than Blockly.
I agree with much that has been posted here. I love Python. But think MicroBlocks may be a good place to start with this particular robot kit, especially if you have any interest in teaching motion control. Some reasons not yet mentioned:
Also, in case you want to try using microBlocks to command the XRP, it is easy to do:
Documentation for the XRP microBlocks library is here: XRP | MicroBlocks Wiki including sections on supporting extra DC motors and modifying the PID tuning parameters. See also documentation for the Encoded DC Motors library (…/edcmotors) and PID library (…/pid).
Russell:
Thanks for these elaborations on using the XRP libraries and the contrasts with Python and Blockly!
Wayne, you are preaching to the choir here. I also believe that what happens AFTER camp is most important. Even though I have my own FIRST teams (and hope learners join one) my main goal is to open their minds to the possibilities with physical computing (especially unrelated to robotics competitions). Thanks for your questions and the IEEE resource! You’ve sparked some great conversation!
These are GREAT resources. Like Wayne, I am preparing for my extended summer camp (6 weeks / 120 hours) and I will explore MicroBlocks to make the camp more engaging. I do, however, like the ability for XRPCode to show the generated Python code, so I may need to mix XRPcode =>Python with MicroBlocks => Python (based on content being learned)
My learners will spend 60 - 80 hours with directed challenges and then have 40 - 60 hours for a group capstone project. Learners will co-design the public showcase, the physical challenges, and their programming methods.
I’m excited about the new possibilities MicroBlocks seems to offer. I just wish I could find a programming solution that runs on Chromebooks!
@RoboticsLady
The third- through fifth-grade students I work with use school-issued Chromebooks to explore physical computing using MicroBlocks. They are amazed to see that something they do (e. g. turn a wheel or potentiometer, or grab a thermo sensor) is displayed in real-time on a MicroBlocks graph window or on an OLED attached to the XRP.
This will certainly broaden the access for my learners! Even though they will all be high school age, laptops are scarce. Perhaps I’ll have sourced more laptops by the time we begin (or IF we begin) using WPILIB.
I just finished browsing the MicroBlocks wiki. Now I know what I will be doing tomorrow while everyone else is grilling!
Jackie:
MicroBlocks exploration rather than the opening of grilling season? WOW!
You may want to make use of the MicroBlocks Forum on Discord to get a sense of the community supporting it:
Don’t be too impressed. I’ll still eat but the kids will do the grilling while I relax! (thanks for the link, I joined the Discord Server)
Hi there,
I’ve not read through this whole conversation in detail, but sounds like most f the discussion was on software, so figured I’d chime in with some info about the hardware additions that @WayneSeltzer asked about.
Addressable LED strips are pretty easy to add with the servo headers. MicroPython includes this library that you can use to control the strips: neopixel — control of WS2812 / NeoPixel LEDs — MicroPython latest documentation Just make sure you’re conscious about how much power you’re drawing from the LEDs!
You could also use the servo headers for adding buzzers and just outputting a PWM signal from the IO pin. The RedBot Buzzer can actually be connected directly into the servo headers, though the volume may be a bit quiet: SparkFun RedBot Buzzer - ROB-12567 - SparkFun Electronics
I2C devices can also be added via the Qwiic connector, though the software is a little tricky at the moment. We’ve got low-level driver implementations working with the XRP for a number of our existing Python libraries, and are currently working on making this easy to implement within XRPCode, though no promises on if/when that will happen. If you want to try it out now, I wrote some instructions a while back that I think should still work: (Where) is Qwiic demo code available (such as from the webinar)? - #6 by SparkFro
Hope this helps!
We’ve been following this conversation for a bit and have been impressed by the quality of the discussion. I especially appreciate the work that has been done on Microblocks to support XRP. It’s great to see so much innovation happening in the XRP ecosystem.
From an XRPCode point of view we hear the request for more devices. Here are some of the items on the roadmap:
Support of Sparkfun QWIIC devices that have Micropython libraries
Bluetooth support
Python editor
The idea to have Blockly support I/O at the pin level is one for us to consider. The problem is that with limited I/O pins on the Pico the I/O pins on the Extra connector are by default shared. It is described in this document Hardware Overview - SparkFun XRP Robot Controller Hardware Overview And specifically this paragraph:
Extra Connector
The Extra connector has pins for both power and ground as well as pins that connect to the Pico W’s GPIO28 and GPIO22. Note, these pins are shared with other functionality on the XRP Controller Board. GPIO28 is shared with the VIN Measure pin which lets you measure the voltage level on VIN so you can monitor the remaining battery charge. GPIO22 is shared with the User Button. Both pins’ primary functions can be disabled with the solder jumpers, refer to the Solder Jumpers section below for more information.
As for contributing to the XRPCode project. It is an open project and we encourage contributors. Although we suggest contacting us first before starting to code to make sure we are not already working on the same thing or already made a different decision.
@Fgrossman - thanks for your response.
This is all promising news!
Is there a date for the next release of the XRP Coder Editor?
As I’m been developing the curriculum for my high school class in July, I’m thinking that the most important need is wireless debugging.
So, for me, this is the highest priority:
Thanks,
Wayne Seltzer
University of Colorado, Boulder