Without much time to prepare, really a month, including four 1.5 hour sessions, where my time was divided among 2 competitive teams, as well as the recreational CCA groups, one of the IDE Series entries – Garbage Boat – managed to catch the eyes of the judges and win a nice award. I have to say, the 2-boy team was extremely excited about the project from the beginning. When the motors that we had in class didn’t work well, they brought a couple of toy 3V motors from home and experimented with them. They designed the garbage scoop all on their own, and even re-engineered the boat from an air-propelled craft, to a more conventional water-propeller vehicle similar to regular boats.
As we entered the competition space, we realized the boat was in a very bad shape – all the wiring had to be redone. I worked with K-Boy, getting in a bit of experiential learning with a soldering iron, a crimping tool, and a glue gun. He managed to secure the micro:bits, motors and props just in time for his showcase (… and get the nurse to bandage his minor soldering iron burn…).
The all-girls Sail Train team didn’t win an award, but were very proud to participate and represent their school.
When I first prepared for teaching skills relevant to CoSpace Rescue I thought this would be a relatively poor platform for learning proper software engineering techniques and computational thinking. After teaching CoSpace-based curriculum for a few months in both Primary (Zhenghua) and Secondary (Pei Hwa) CCAs I have to admit the virtual simulation platform is starting to grow on me.
Unfortunately, as I have become more enthusiastic about the CoSpace framework, I’ve also simultaneously realized that my first instincts about it are also true. As a gamification system for coding, CoSpace Rescue works well. For the Primary School level, the GUI really helps in removing obstacles to getting started, as opposed to an all-text-based coding environment. Kids can quickly add rules and test various event-based decision trees, without knowing any coding language.
They quickly internalize boolean operator concepts, and competing decision priorities and choices. It isn’t a very big jump from that to utilizing state variables to create simple state machines. Still, it has been challenging to get students used to this environment to shed the security and comfort of the game GUI with the freedom and efficiency of pure and abstract C coding. Without the ability to abstract from the Simulation Gaming environment to the underlying C code, the students are unable to make the leap of faith and leap of computational confidence to go hacking. That’s where the benefits of the platform start hitting a serious wall – students inculcated in nothing else for several years turn into great CoSpace Rescue developers, but not great developers… A work in progress.
Still, I’m proud of the Junior team at Zhenghua who managed to clinch the ambiguous “Judge’s Award”!
We built and tested our Chihuahua (small, but loud) wall climbing robot in two weeks, or so. It was a fun process where none of us got electrocuted, despite losing magic smoke from various MOSFETs and diodes. We also didn’t lose any of our 10 fingers in the high-speed ducted fans, despite cutting through and splintering several propellers.
So, that’s a marked success.
Here’s a video of us testing a full run at home – the surfaces are all wrong, and the dimensions are much shorter than the real event:
With that fine working machine in the bag, and less than 24 hours to go, we decided to add more Time-of-Flight light distance sensors and a whole bunch of code, in order to be able to perform some alignment correction on the controlled fall back down. That seemed to have introduced unexpected I2C complexities, which we spent a lot of our day-of-competition practice time trying to understand and overcome.
Here’s one of our better practice performances:
By the time we had to cage our robot, we had some vague hopes that one of several runs might luck through the full challenge… Unfortunately, our little Chihuahua had stage fright in front of an expectant audience, which turned into a full meltdown, when one of its unprotected wires shorted and a billow of smoke erupted climactically from the belly of the beast.
Oh well! We did impress some people with our thrust-based design, and collected our Unique Design Special Award ceremoniously at the end of the event.
We plan to be back next year with another unique design in at least one challenge… Kudos to Singapore Robotics Games organizers for all their hard work and dedication to the open and free competition.
Last week, as I was getting excited about my work with FIRST LEGO League at the Innovation Lab (see last post), I spent some time scouting other local and regional robotics competitions. I happened on a very useful list from a competitor. It led me to investigate the Singapore Robotics Games (SRG) as a general platform for expressing our own innovative energy. I immediately got motivated to register our team of crack enthusiasts to showcase our talents, abilities, and our drive. Participating in and winning a robotics competition is both immensely rewarding and very valuable from a marketing standpoint – a powerful story to tell kids, parents, teachers, administrators and partners when we try to tout our product. As this event is organized by Singapore academia, it is more about fostering rapport between various organizations who have a stake in robotics research and its integration in academia and industry in Singapore, and so registration fees are waived by the organizers, who co-sponsor the event with the Science Centre and its government arm – the Science Centre Board, which is part of the Ministry of Education.
Shenghao (resident hacker) and I perused the competition documentation and decided to go for the Wall Climbing Robot Race, because we believed the challenge was simple enough to get at least partially right in a short amount of time. The historical participation rates for this event were not overwhelming, which was another bonus for us. We quickly ensnared the support of Cort, and immediately became embroiled in design discussions and strategies for winning. Laven (resident martian expert) joined our group as well, and I registered our 4-person team officially, once we had a consensus that this was worthy of our time and effort, and that we would all be OK making complete fools of ourselves in the worst case.
Homemade Thrust Testing Platform
Our current design is basically a car that climbs walls and stays upright by applying some force directly towards whatever surface it is on – it takes over for or fights against gravity when the plane of motion changes with respect to it. We are using electric ducted fans to try to achieve this. Currently we have a fairly complete design, but missing a few of the parts – namely, power switches for high-current applications, and wheels and tires. We also need to do some design work to get around any kind of wheel slip in our car, that would disorient it off its planned course – go straight. The variance in reflectance properties of the 3 surfaces we need to drive across seem to be complicating this to some degree.
Our budget of $500 is quickly being eaten away from paying premium prices for electronics, which we are sourcing locally, instead of through our usual, cheaper, global trade routes, simply for the expediency of time. We have about $150 sunk in drive and thrust systems (EDFs, gear motors), another $100 or so in the power system (with some spent on reserves for the sake of rapid-ish prototyping), and say $50-100 allocated for chassis, controller, sensors and the rest of the electronics, a lot of which we already had.
We’ve done about 3 days of work, and I foresee about 3-5 more before we have a testable platform. Depending on the sanity of our design choices and integration work, we may be close to done at that point, or scramble back to the drawing board, with very little time to spare before the competition.
No mountain too high for A Posteriori Wall Climbing Robot Team!
