An educator’s point of view on the best way to teach robotics and coding to students and children.
A note from the editor:
We first met Pete back in January 2018 (Issue 7) when we featured his Twitter hashtag driven LED Striplight project. Since then, Pete has continued to develop his code and tech training company, Nexgen Codecamp, teaching high school students how to code.
More recently, Pete has developed a robot built on Arduino technology for use in high schools and STEM clubs. Pete has kindly offered to share the development process with us, and provides some great insight into what should be considered when teaching kids about robotics and coding. Regardless if you are a maker, student, parent, or teacher, there are many interesting points to consider so that you get the most out of your codable robot.
When I was a child, robots were the stuff of science fiction - K9 in Dr Who, C3PO & R2D2 in Star Wars, and HAL - the AI computer in Arthur C Clarke’s 2001. In the 1970s, the promise of AI and real functioning robots was real but premature. Fast forward to 2021 and robots are everywhere. Moreover, with the rise of the Internet, we all have the opportunity to both learn about and build them.
Although STEM is about much more than robots, they are a great vehicle for engaging in problem based learning and for integrating the disciplines of science, mathematics, engineering and technology in an accessible and interactive way. Not to mention the fact that a robot can take many forms and be applied to many different problem spaces across the curriculum.
Since forming Nexgen Codecamp in 2016, I have seen many educational robots enter the market - aimed at individuals, schools and students. All of these solutions have some merit in the functionality and learning possibilities that they bring, however, I have always had a nagging doubt about what was on offer.
It was only after we started teaching with simple robots that we had built ourselves, that I began to realise that most off the shelf offerings had what I felt were serious limitations. I was also concerned about the high price tag that many seemed to carry for what they were offering.
What do we want from a robot?
In short, a robot should be affordable, modular, configurable, code-able, multi-function and extensible, ideally through a cost-effective solution such as 3D printing. When we investigated the current robots on offer to schools, we felt that there was a need for a robot that fulfilled all of the criteria mentioned above. Robots seemed to be either too expensive for what they offered or fairly simple black boxes with command modes of operation. Sure you could code them through a drag and drop coding language or perhaps Python, however, we didn’t really get a sense of how the robot was working. Whilst you benefit from solving problems through coding, you lose the hardware and integration aspects to the dreaded black box and therefore a whole bunch of critical learning is lost. We felt it was important to answer the questions: ‘how and why does this happen when I issue this particular code to the robot’ rather than just ‘what will happen when I issue this code to the robot’.
Introducing the Nexgen Rover
In the light of the reasons outlined above, we decided to build our own entry level robot that would hopefully compete with some of the higher priced offerings out there, but also bring a few more things to the table. The Nexgen Rover was born in Jan 2021 after a summer of design, prototyping and iteration. It was based around an aluminium tank chassis with a 3D printed base and attachments. The rest of this article expands on the answer to “What do we want in a robot?” and explains how we approached the problem with our own offering.
What we want from a robot
Buy robot at a ‘reasonable price’
What is a ‘reasonable price’ for a robot? $100? $500 or even $1000?. Well it really depends on what the robot is capable of and what your requirements are as to what you think is reasonable.
In reality, for a class of 20-30 students, anything north of $150 is a considerable investment and is usually out of reach of the public school system. This is already a tragedy, however, it gets worse as purchases are often made without realising the limitations and the true extent of the functionality of the purchase.
Our goal was to make the Nexgen Rover for around $100, certainly well under $150 and with future iterations, drive the price down. We are hoping to do that into 2022. For what the user is getting, we feel that this is real value for money.
Build from the ground up
‘From the ground up’ typically means that the student must assemble the robot from scratch.
Robots differ in this regard and sometimes for good reason. Robots for younger students (yr1-4) are fully assembled and rightly so. We are talking about robots for older students who are more likely to be interested in how exactly things work. We typically aim the Nexgen Rover courses at high school students.
Some robots come in pieces to be assembled (LEGO & Meccano types) which is great. Others come as a single piece (not so great). Why is this important? Many students are inquisitive and want to know how things work. This is a great opportunity for us as educators to give students confidence in their robot. If I know how something works, then I have more chance of fixing it if it goes wrong by testing each component. If it is a black box, I have little recourse other than to switch it off and on again (like our PCs and most of our devices at home!). At best, it may have error modes, however, that only helps us to understand its mode of operation rather than how it actually works - like your washing machine!
The assembly phase of the Nexgen Rover is an important and not an incidental part of the education process. Assembly involves putting the chassis together, adding all of the 3D printed parts, sensors and other components, wiring the whole thing together, installing the software/firmware and testing the robot. Only once all these tasks are completed, can a student say that their robot is up and running. This is not a simple set of tasks and requires some resilience on the part of the student, however, the result is a real sense of accomplishment once their Rover is running through its test routine with 100% success.
Understand each component
The problem with black box robots is that it is hard to distinguish the components from the whole. At best there may be a main module which has connection points for sensors which are often connected through RJ11 (telephone) cables. This is good because it means that the robot can be modified with different sensors in the future. On the other hand, the main module is often a bit of a mystery. Which microcontroller is it based on? Which pins are exposed? How many digital and analog pins are actually available for us to play with? Often the answer is only a few or even none.
When developing the Rover, we wanted to teach the core microcontroller theory and usage as well as all of the sensors and actuators, so it was important to us that students gained considerable experience with the microcontroller (an Arduino compatible product). This involved how to configure it, best practices with the IDE, how to write & upload code, debug and test. All of these tasks taken together help to assess digital literacy of the student which isn’t a bad thing! By exposing the microcontroller to the student, they can leverage its functionality for different problem domains, be they robot or non-robot specific. Proprietary boards are limited to the robot and these usually do not expose much functionality of the on-board microcontroller.
Understand the relationship between each component
Any project, be it a robot, an LED lamp, an MP3 player or whatever involves a bunch of components. In our view, it is important to understand how these components relate and work together to transform an input signal from a sensor into an output signal expressed by an actuator. Coding the robot is only one part of the equation. How is the sensor connected to the microcontroller? What are all the sensor pins for? What does a high or low signal mean? What is ‘ground’ anyway? A one size fits all connection interface suits the manufacturer more than the user as you will never understand the connection between sensor and module. You only know that if you plug it in, it should work. What if it doesn’t work? What do you test and how do you test it?
We should be creating content that embraces failure, especially in technology. Starting from scratch and using raw components may be more difficult from everybody’s perspective, however, it is a great way to learn. Programmers, engineers and designers spend a great deal of time recovering and learning from failure. In doing so, they build up a raft of skills and experience.
Plug and play has some advantages (especially for very young students), however, when it turns into plug and pray - you have little recourse other than to email support.
Install software/firmware onto the robot
Pretty much all of the robots we are talking about here will allow you to write and upload code to the robot - otherwise it would be kind of pointless right? The difference is that most of them have a proprietary coding interface that is more or less tied to the robot.
We wanted to design a robot that taught students within a coding environment that could be used for other projects. The code that they learn is directly transferable and the environment is the same. This means they wouldn’t waste time learning multiple coding environments every time they switched robots or microcontrollers and could focus on the code thus building confidence for the next Arduino based project.
Realise various types of functionalities of the robot
So what can the robot do? Most robots do pretty well here as they are loaded with sensors that can be coded, however, in a project based setting there would be more constraints as students would be restricted to the onboard sensors or the available bolt-on sensors in the form of upgrade kits, which are great but often way more expensive than they need to be. An ideal in this scenario would be that the robot could accept any sensor at all. That way, the student or school could order in what they need from the cheapest supplier, then build a bracket for the sensor and customise the robot - very creative!
Our current design is not as modular as we would like it to be, although we can replace sensors with different sensors via 3D printed brackets. In a future version, the Nexgen Rover will have a modular interface with mount points for sensors. That way, a student will be able to 3D model & print their own design and fit it on the Rover easily. Again, this gives a student way more learning capital through a project based experience.
3D print parts of the robot
At the moment, the Nexgen Rover is part bought in chassis, part 3D printed, however, our future plans will see our own chassis being developed and possibly our own 3D printed tracks. This will hopefully bring the cost of production down again - something I see as vitally important if robotics is to be equitable across all schools and not just the private sector. We are looking forward to seeing this vision realised!
Create new functionality for the robot
Finally, a robot should not be a finite creature - after all AI and ML teaches us that machines can learn, evolve and adapt. This will only become more sophisticated in the future. Hence our educational robots should be having this feature. What if I want to bolt on an accelerometer for a geography based project that involves mapping out terrain? What if I wanted to put a string of addressable LED lights onboard to give my robot the capability to be seen in the dark, and an infrared sensor so that it could ‘see’ in the dark? What if I want to give it Bluetooth control and develop my own app to control it? Or WiFi control? Speech recognition? Let’s face it, the list of possibilities is endless.
Conclusion
We have focussed in on the robot (hardware & software) in this article for obvious reasons but it is worth mentioning that without a decent course or project behind it, any robot will be of little use as they are all educational tools at the end of the day. We hope though that future products that are brought to market think through some of the arguments presented above to bring about the best experience and value for money to all school children everywhere in order to help them acquire real skills that will equip them for the future workforce.