Here’s our batch of brand new Mirobot v3 kits on their arrival in Australia, dozens stacked. Since the v3 have a neat acrylic frame, I think I’ll do a proper “unboxing” and first build video of one soon, so you can see for yourself what this is about.
Many classes of year 5 and 6 students around Brisbane and their teachers have done our Robotics Workshops in recent years (using the Mirobot v1 and v2), and others have purchased their own Mirobot to build and use at home. And schools around Australia order sets to run their own programs.
What’s special about the v3 is that it’s now possible to repeatedly build and (carefully) disassemble the Mirobots, which means that not only the programming but also the assembly process can be repeated for future cohorts.
Below is an animation of the v3 kit build process:
The Mirobot is a “logo” turtle: it takes a pen (up&down) and can move forward/reverse (in mm) and turn left/right (in degrees). So, Mirobot can draw, and that’s really important because it provides students with very direct feedback for their programming. There are also bump and line-following sensors.
Students engage with inquiry-based learning: first the build which involves learning about the components and the mechanical structure – then, programming from a “simple” square, to a house, circle, stars and much more complex patterns. Students also make them write letters. Sure!
Most of the current batch was already pre-ordered, but we have some regular stock.
The Mirobot v2 logo turtle robotics kits will be here shortly. These are the updated version of the kits we have been using at primary schools (year 4-6) this year in our Robotics and Programming workshops. The new model doesn’t require little pegs any more, the structure now holds itself together with a beautiful designed slot mechanism. Kudos to Ben Pirt for an awesome design!
The robot frames are made of lasercut MDF, and the circuit board is Arduino controlled. All aspects of the design is open and available. The robot can be used to draw, but now also comes with bump sensors and line following capabilities. Communication is through wifi over a raw or web socket. There are a number of programming and control options, from Scratch-style visual systems to a brand new Python library!
By default the v2 comes with a pre-soldered circuit board, but especially for OpenSTEM Ben is offering a non-soldered PCB so we can continue doing the soldering part with classes also. We have found this to be both a great enabler for students, as well as teach that people can build things almost from scratch. But you choose… we keep both the soldered and un-soldered kits. Either way, this is a great project to do with your kids at home, quite a few parents of students that do our workshops also continue in this way.
If you order now, we’ll still be able to include you in the first shipment!
Now for Electronics Soldering!If you or your children want to also do some soldering but don’t have the necessary tools yet, we now have sets available. We assemble our own classroom soldering kits ourselves from a number of sources, as sets found in shops have flimsy or awkward stands. We use a solid steel stand, that also features a wire cleaning ball – this works much better than a wet sponge and it is much easier to maintain. We also include a number of other useful items.
Shipping of orders including Mirobots will be in November. This is likely to be our final Mirobot order this side of Christmas, so we do recommend you order now if you want to have the kit available over the holidays.
Being involved with teaching young students to code, I have come to the tentative conclusion that many coding kids have not actually been taught programming. This has been going on for a while, so some of this cohort are now themselves teaching others.
I have noticed that many people doing programming actually lack many of the fundamental skills that would make their programs efficient, less buggy and even just functional.
Naturally, many (most!) of the things described there are familiar to me, and it’s interesting to review them. But contrary to Esther, I still do apply some of those techniques – I don’t want to miss them, as they serve a very important purpose, in understanding as well as for producing better code. And I teach them to students.
Programming is about smartly applied laziness. Students are typically aghast when I use that word, which is exactly why I use it, but the point is that smartly applied laziness is not the same as slackness. It’s simply a juicy way of describing “efficient”.
Suppose you need to shift some buckets of water. You could carry one bucket at a time, but you’ll quickly find that it’s hard on your arm and shoulders, as well as wasting the other arm you have. So we learn that if you have more than one bucket to shift, carrying only one bucket at a time is not the best way of going about it. Similarly, trying to carry three or more buckets is probably going to cost more time than it saves, as well as likely spilling water all over the place.
Thus, and this was of course worked out many centuries ago, carrying two buckets works best and is the most efficient as well as being quite comfortable – particularly when using a neat yet simple tool called a yoke (as pictured).
Inevitably, most kids will have at some time explored this issue themselves (perhaps while camping), and generally come to the same conclusion and insight. This is possible because the issue is fairly straightforward, and not obscured by other factors. In programming, things are not always so transparent.
Our modern programming tools (high-level languages, loose typing, visual programming, extensive APIs and libraries) enable us to have more convenience. But that convenience can only be applied judiciously when the programmer has the knowledge and skills required to make appropriate judgements. Without that, code can still be produced rapidly, but the results are not so good.
Some would say “good enough”, and that is somewhat true – when you have an abundance of computing power, memory and storage, what do a few bytes or cycles matter? But add together many of those inefficiencies, and it does become a rather dreadful mess. These days the luxury of abundance has become seriously abused. In our everyday life using laptops, smart-phones, tablets and other devices, we frequently encounter the consequences, and somehow regard it as “normal”. However, crashing apps (extreme case but very common) are not normal, and we should not regard any of this as good enough.
I see kids being taught to code using tools such as MIT’s Scratch. I reckon that’s fine as a tool, but in my observations so far the kids are only being shown how to do specific things the particular app or environment. Some kids will have a natural knack for it and figure out how to do things properly, others will plod along and indeed get through by sheer determination, and some will give up – they might conclude that programming is not for them. I think that’s more than a pity. It’s wrong.
When you think about it, what’s actually happening… in natural language, do we just give a person a dictionary and some reference to grammar, and expect them to effectively use that language? We wouldn’t (well actually, it is what my French teachers did, which is why I didn’t pick up that language in school). And why would computer programming languages be different?
Given even a few fundamental programming techniques, the students become vastly more competent and effective and produce better code that actually works reliably. Is such understanding an optional extra that we don’t really care about, or should it be regarded as essential to the teaching?
I think we should set the bar higher. I believe that anyone learning programming should learn fundamentals of how and why a computer works the way it does, and the various techniques that make a computer program efficient and maintainable (among other attributes). Because programming is so much more than syntax.
I’m not a great fan of flow-charts when it comes to programming, but I reckon this one with the lyrics of the classic Beatles song Hey Jude is pretty cool: (click on the image to see it at full size)
If you like that kind of geeky fun… a few years ago there was a Twitter trend #songsincode (links to the archive) in which thousands of people captured the title of a song using a bit of (pseudo-)code (of whatever programming language), of course also bound by Twitter’s 140 character message limit.
I’ve written earlier that my first “real” computer was the Acorn BBC Micro. I did have a Sinclair ZX80 a bit before then, but that little machine only had 1KB of RAM and a very shabby flat touch keyboard. The Acorn BBC had a real properly clicky keyboard, vastly more RAM (32KB 😉 and twice the CPU speed as well as many more options for attaching devices and hacking around in both hardware and software space. I didn’t quite realise all that, but I knew I wanted one and it was an amazing experience to play with and learn from.
In 1984 a new game came out, Elite. Very different from the other stuff that had been around. It was 3D, in space, and didn’t have the typical “3 lives, a few challenges, and N minutes of game play”. In the video below, BBC’s Peter Snow visits the Elite authors David Braben and Ian Bell, to explore how the game was developed. It’s a most interesting story. I didn’t know the 3D space radar screen had been a last minute addition. Indeed it turned out to be one of the key features!
The video doesn’t mention that many aspects of Elite were based on the Classic Traveller RPG (Role Playing Game), including ship designs and trading approach. The authors did acknowledge this elsewhere. It’s fine, just good to know about heritage and influences.
Of course the gaming world has moved on, itself influenced in a major way by Elite. The game Elite itself is also still around, with David Braben most recently developing Elite: Dangerous.
Elite taught interesting lessons for game developers, which are sometimes forgotten today. It’s not all about the fancy graphics, the game play experience is much more than that (and actually not necessarily about the graphics at all). Size matters, even today – inevitably, if you have load more data from disk, it’s slightly slower. So if you’re more space efficient, the broader game will appear snappier: more responsive and faster.
“Tight code” and design is not typically something programmers focus on now, but it’s a real asset. It requires proper understanding of a system, down the software layers into the hardware. It’s worthwhile, even if you’re not planning on writing the next amazing video game. I don’t like to delve into the common Intel based PCs as they’re overly complex and really quite messy. But looking at Arduino micro-controller environments is entirely feasible, and also Raspberry Pi. And that’s also the kind of understanding that we work on in our OpenSTEM workshops and programs for school classes.
Mark Pesce writes about kids solving real world problems.
They create code (programming) but these days it’s not always necessarily about that. I think that makes sense. When I got into coding, it was quite hard to solve real world problems that way or interface with the real world. It’s actually just a reflection of where the hardware and related infrastructure was at – at that time.
Back then kids (or any people) explored computers and programming as a target in itself, not as a tool to be used. Obviously it was still a tool, but the primary use case was clearly different for those explorers (of which I was one).
Here’s our batch of brand new Mirobot v3 kits on their arrival in Australia, dozens stacked. Since the v3 have a neat acrylic frame, I think I’ll do a proper “unboxing” and first build video of one soon, so you can see for yourself what this is about.
I played this game 3 or 4 times with my grade 4 son. He said he would enjoy it more…
Brad