Monday, October 29, 2018
Saturday, October 27, 2018
Fac, ergo sum
I make, therefore I am.
A solitary human out on the African Savanna is mostly some other animal’s lunch; we aren’t particularly strong or fast. But we are crafty, and when we get together in groups we become formidable. So it is not surprising that we are social animals, and that we receive significant neurochemical rewards for social behavior.
Dunbar’s Number, 150, has now been found just about everywhere we look for the size of human communities, be they in Meatspace or Cyberspace. I suspect that the minimum number of human individuals required to make a functional, self-sustaining, durable collective is not surprisingly Dunbar’s Number. I would go so far as to suggest that we should redefine One Human as being made up of 150 individuals; any less or more than this is not sustainable. If this hypothesis has any merit we should find significant evidence for it, in the neurological rewards systems in the human brain, and the number of individuals we are hardwired to keep track of. We most certainly find it in data associated with the size of human communities.
Humans are also tool makers. And probably the greatest tool they have made is teaching other humans how to make tools. Civilization could be thought of as nothing more than a evolutionary framework for propagating the knowledge of how to make specific tools through spacetime. Given the massive evolutionary advantage that this ability has given us, one would imagine that we have evolved specific neurological mechanisms that would incentivize us to make tools and to teach others how to do so. It is highly likely that Making (which inherently includes the didactic component), is a natural and powerful antidepressant, which gives Makers a durable sense of purpose, meaning and accomplishment.
Given how beneficial Making is to our species, this also introduces the possibility that the primary purpose for human clumping, other than staying off the menu, is to maximize the opportunity for making tools and directly passing that knowledge on to others, while minimizing the caloric cost (cognition is SUPER expensive after all) of keeping track of the other constituents of one’s Human.
Given their utility, are tools not the most durable of memes?
Regardless of the validity of the above hypothesis, nobody can argue that Making, and then teaching others how to Make, is one of the most consistent sources of satisfaction and meaning. Certainly I have found being a Maker, along with investing in making other peoples’ lives better, to be the best anti-Nihilism I have come across.
Monday, October 8, 2018
Scoop of Death Junior – Making a Sumobot
I had not planned on entering this year’s
Microsoft Vancouver
annual
Sumobots contest
, and was most definitely not expecting to win it. I entered in 2016 as part of a team, and again in
2017
with a robot I designed and built myself, aptly named “Scoop of Death”
(
SoD
). I spent about a month working on
SoD, most of which was spent modeling a new body for the
Elegoo kit, and the scoop that gave the bot its name. All the modeling was done in
Autodesk’s Fusion 360, which I was just learning to use at the time. I also spent some of that time writing code to make
the
bot capable of competing autonomously, and even included a
Pixy camera
for hardware-accelerated computer vision. On the day however, given how many of the entrants were
going to be remote controlled, I decided to go with a simple RC solution via the Bluetooth component
and
accompanying iOS app supplied in the
Elegoo kit. Though the scoop on my bot got me all the way to the finals, I was not able to vanquish the
six-servo
metal beast that I faced, and was easily pushed out of the ring. I was totally happy with second place;
I
am generally not competitive, and participating in the event had given me an excellent opportunity to
up my
Maker game.
And in the year since that competition I have continued to improve my Maker Fu. I have started, and in most cases, completed, a handful of rather ambitious projects (for me anyway) this year. A couple of the most ambitious ones are still underway, which is why I had initially decided not to compete in this year’s Sumobot contest. However, a few weeks before the event, Stacy Mulcahy, who runs the Microsoft Vancouver Garage and the Sumobot event, asked if I would participate. If I were simply able to re-enter SoD in the competition, with only minor but devastating upgrades, it would have been a no-brainer. Alas this year they changed the restrictions to a max size of 6”x6”x"6” and no more than 6.6 lbs., and SoD was somewhat longer than 6”. I decided to participate after all and picked up one of the Pololu Zumo kits that the Garage was providing to entrants. I also decided to limit myself to only two days to design and assemble my bot (3D printing not included because, well, it takes FOREVER). Because of the time limit that I had set for myself I also planned to reuse my killer scoop design from SoD and borrow code very liberally from the examples that come with the Zumo kit.
The Zumo Shield uses a lot of GPIO pins by default for the integrated accelerometer, gyroscope, magnetometer, motor controller, buttons, buzzer, battery meter, and optional line follower. The kit we got came with a basic Arduino Uno, so almost every pin was already used for something. The first additional part I built for my bot was a hard-wired analog joystick. I used a GHI Joystick Module that the Garage donated to me, and modeled and printed a comfy housing for it.
Unfortunately the joystick pushed me beyond the pin capacity of the Uno, since it required two additional analog pins and one digital one (for an optional button). I also planned to include an ultrasonic rangefinder and LCD display, so I decided to replace the Uno with a Mega board that I had lying around, since it has a lot more of everything. The last addition was a small breadboard for the additional parts (though I am not afraid of soldering I try to avoid it if I can, to maximize the reuse of parts, without having to resort to de-soldering or snipping wires). Before testing any of the electronics I happily jumped right into Fusion 360 to model my bot.
In retrospect I wish I had respected the wisdom of RTFM, or at least tested the electronics before starting the modeling. I would have discovered very promptly that the Zumo Shield does not work with the Mega because of differences in how the GPIO pins are mapped to the capabilities of the microprocessor. So I naively took the scoop from SoD, scaled it down to size, added an integrated mounting plate for the Mega, the Zumo Shield (with its attached motors) and all the other bits and pieces I wanted to include.
I spent half a day modeling the part, printed it overnight, and then completed the assembly the next day. I sliced the part into four sections before printing to avoid having to print support. I have done a fair amount of 3D printing now and I have found that a part that is printed in sections and then glued with model glue makes for a very structurally sound finished product, and it is easier to fix mistakes because it only requires the reprint of a single slice. It also helps if you want to insert additional weights or structural support into the finished part. In this case I only had to reprint one slice and then I inserted some weights (ball bearings) into the bottom slice of the scoop, glued it all together, and sanded it to a lustrously smooth finish.
A cautionary aside is necessary at this point. I did not wear a respirator while sanding the part, which was rather irresponsible of me. PLA is probably slightly toxic, and you don’t really want to breath it into your lungs, but model glue however is nasty stuff and you most definitely do not want to breath that into your lungs mixed in with the PLA dust. After a few hours of sanding I definitely felt it in my chest. Don’t be like me – always wear a respirator when you sand – period!
Despite the possibly negative impact to my health, the part turned out beautifully, and everything fit almost perfectly. There were a few post-print modifications required, but thankfully PLA can be reshaped within reason with the aid of a heat gun. I then assembled the entire bot, along with all the electronics and uploaded a version of the Zumo RC example modified to work with the joystick. It was at this point that I was reminded of whose mother Assumption is. The bot went into what I can only describe as a robotic fit. I finally R’d the FM and discovered the incompatibility between the Zumo Shield and the Mega. I had just assumed that because most of the components on the Zumo use I²C to communicate with the microcontroller, everything should just work. It turned out to most definitely not to be the case and I now had to salvage the situation with no time to model or print a new body.
Thankfully the Uno and Mega do share a similar shape and a few mounting holes. It didn’t take long to retrofit the mounting plate to fit the Uno, by drilling a couple of holes in the mounting plate, and heat fitting a couple of long standoff nuts into those holes. I found that this technique is the best if you want to create 3D-printed PLA parts that you want to be able to disassemble later. Drill a hole that is a few mm smaller than the nut, heat the nut with a heat gun and then gently push it into the hole. Once it cools it should remain very firmly in place and you can place metal screws in one or both ends and tighten them pretty tight without the nuts slipping or coming out.
The return to the Uno meant that I had to make a choice; the bot had to either be autonomous or remote controlled. Not both, since there were simply not enough GPIO pins to support both scenarios. In the name of expedience, I abandoned the code for my loosely-coupled, message-based, interrupt-driven, finite state machine, and just took the original sketch I had created for the RV version of my bot. The result was a very zippy little remote controlled bot, which I had originally named “The Sixer”, for all of the new restrictions, but I decided that “Scoop of Death Junior” was a much better name.
Since I had already consumed most of the two days I had rationed myself to, I did nothing more to my bot until the day of the contest. I weighed Jnr that morning and it did not even weigh a full pound, despite my inclusion of weights in the scoop! It needed to pack on a few more pounds. So on the morning of the tournament I modeled a weight box for the back of the bot and set it to print. My fallback plan in case the print failed (because obviously that NEVER happens!) was to just cable tie bags of bearing balls to the front and back of the bot. The print finished with time to spare and I was able to firmly attach it to the body using the heated standoff nuts technique. I then filled the box with bearing balls, glued the box closed with model glue (mistake!) and headed off to the event, again without testing the bot (you may see a trend emerging here).
While waiting for the weigh-in I finally decided to test the bot. Everything worked perfectly… except I had put too many steel balls in the weight box, and significantly shifted the center of gravity of the bot up and to the rear. Now every time I drove it forward it would pull an awesome wheelie. This would not do! My primary weapon was my scoop, and a scoop is only good if it is under your opponent, not way up in the air! So I frantically ran back to my desk, strung some ball bearings on a cable tie and literally tied it on the front of the bot with hookup wire. It didn’t completely stop the wheelieing, but it did make it a little less extreme. In the end this wheelieing turned out to be something of a secret weapon.
The bravely-autonomous bot I faced in the first round, though cute, suffered from technical difficulties, and I was able to easily dispatch it. My subsequent matches were a little more challenging but I was consistently able to maneuver around my opponents, some of whom were remote controlled and some autonomous, and summarily push them out of the ring. I suspect that my advantage in most of these bouts (other than a human operator) was the weight I had added, since most of my opponents were using the standard kit that had been provided. Though I lost a couple of matches, I won every round, and then found myself in the semi-finals facing my nemesis from 2017 and the then reigning champion. He had also had to bring a new bot this year to comply with the new limits.
It was at this point that I thought I should put fresh batteries in my bot. This time I did test it, and the new batteries had made the wheelieing much worse! The extra juice was giving the motors extra torque – the lightest touch on the joystick had the scoop at 45 degrees and the bot headed forward at nearly full throttle. Perhaps I could use this in some way to give me an edge in the last couple of rounds. I had nothing to lose; I was in it for the Making, not the winning. If I let my opponent come to me, and get up over the lip of my scoop, I should be able to simply give it full throttle and use the torque to lift him, which should make it easier to push him out.
My opponent’s bot in the last two rounds (it was a double elimination tournament) was armed with 4x12v DC motors, while mine was running on the two “stock” 5v motors. In a straight head-to-head shoving match I didn’t stand a chance. In the end I suspect it all came down to three things – low latency, simplicity and build quality.
My decision to use a simple hard-wired controller, wired directly to two analog pins, meant that my bot was incredibly responsive. My opponent had chosen to go with an Xbox 360 controller, connected over RF to a receiver plugged into a USB shield, communicating with the microcontroller using a serial protocol. And those very powerful 12v motors were also a little on the slow side. My bot was significantly more agile and was able to move out of the way whenever we got into a head-to-head situation, and I was then able to come in from the side before he could turn, get the lip of my scoop under his treads, and then use the wheelie to lift and drive him out of the ring.
The other advantage was that my bot was very robustly constructed, and there just wasn’t a lot that could go wrong with it (other than human error – I lost one match because I forgot to turn my bot on). All the structural parts of my bot were 3D printed and either glued together with model glue or bolted in place. My opponent kept having technical difficulties, from his controller not working, to the treads coming off his bot. I suspect that if his bot had been just a little bit more robust, that I would not have stood a chance against those four 12v motors. In the end I suspect I won because I had to keep it simple to get it done in 2 days.
In the days since the contest I have continued to improve on the design of Jnr. I have added an additional weight box in the front and have reduced the size of the one in the back. Though it probably will not compete again I plan to print the parts and put them on the bot. I also plan to put all the models and code up so that others can improve on my design.
I continue to be incredibly grateful to Microsoft for the Garage, which has enabled all of this, and has given me the opportunity to learn so much.
And in the year since that competition I have continued to improve my Maker Fu. I have started, and in most cases, completed, a handful of rather ambitious projects (for me anyway) this year. A couple of the most ambitious ones are still underway, which is why I had initially decided not to compete in this year’s Sumobot contest. However, a few weeks before the event, Stacy Mulcahy, who runs the Microsoft Vancouver Garage and the Sumobot event, asked if I would participate. If I were simply able to re-enter SoD in the competition, with only minor but devastating upgrades, it would have been a no-brainer. Alas this year they changed the restrictions to a max size of 6”x6”x"6” and no more than 6.6 lbs., and SoD was somewhat longer than 6”. I decided to participate after all and picked up one of the Pololu Zumo kits that the Garage was providing to entrants. I also decided to limit myself to only two days to design and assemble my bot (3D printing not included because, well, it takes FOREVER). Because of the time limit that I had set for myself I also planned to reuse my killer scoop design from SoD and borrow code very liberally from the examples that come with the Zumo kit.
The Zumo Shield uses a lot of GPIO pins by default for the integrated accelerometer, gyroscope, magnetometer, motor controller, buttons, buzzer, battery meter, and optional line follower. The kit we got came with a basic Arduino Uno, so almost every pin was already used for something. The first additional part I built for my bot was a hard-wired analog joystick. I used a GHI Joystick Module that the Garage donated to me, and modeled and printed a comfy housing for it.
Unfortunately the joystick pushed me beyond the pin capacity of the Uno, since it required two additional analog pins and one digital one (for an optional button). I also planned to include an ultrasonic rangefinder and LCD display, so I decided to replace the Uno with a Mega board that I had lying around, since it has a lot more of everything. The last addition was a small breadboard for the additional parts (though I am not afraid of soldering I try to avoid it if I can, to maximize the reuse of parts, without having to resort to de-soldering or snipping wires). Before testing any of the electronics I happily jumped right into Fusion 360 to model my bot.
In retrospect I wish I had respected the wisdom of RTFM, or at least tested the electronics before starting the modeling. I would have discovered very promptly that the Zumo Shield does not work with the Mega because of differences in how the GPIO pins are mapped to the capabilities of the microprocessor. So I naively took the scoop from SoD, scaled it down to size, added an integrated mounting plate for the Mega, the Zumo Shield (with its attached motors) and all the other bits and pieces I wanted to include.
I spent half a day modeling the part, printed it overnight, and then completed the assembly the next day. I sliced the part into four sections before printing to avoid having to print support. I have done a fair amount of 3D printing now and I have found that a part that is printed in sections and then glued with model glue makes for a very structurally sound finished product, and it is easier to fix mistakes because it only requires the reprint of a single slice. It also helps if you want to insert additional weights or structural support into the finished part. In this case I only had to reprint one slice and then I inserted some weights (ball bearings) into the bottom slice of the scoop, glued it all together, and sanded it to a lustrously smooth finish.
A cautionary aside is necessary at this point. I did not wear a respirator while sanding the part, which was rather irresponsible of me. PLA is probably slightly toxic, and you don’t really want to breath it into your lungs, but model glue however is nasty stuff and you most definitely do not want to breath that into your lungs mixed in with the PLA dust. After a few hours of sanding I definitely felt it in my chest. Don’t be like me – always wear a respirator when you sand – period!
Despite the possibly negative impact to my health, the part turned out beautifully, and everything fit almost perfectly. There were a few post-print modifications required, but thankfully PLA can be reshaped within reason with the aid of a heat gun. I then assembled the entire bot, along with all the electronics and uploaded a version of the Zumo RC example modified to work with the joystick. It was at this point that I was reminded of whose mother Assumption is. The bot went into what I can only describe as a robotic fit. I finally R’d the FM and discovered the incompatibility between the Zumo Shield and the Mega. I had just assumed that because most of the components on the Zumo use I²C to communicate with the microcontroller, everything should just work. It turned out to most definitely not to be the case and I now had to salvage the situation with no time to model or print a new body.
Thankfully the Uno and Mega do share a similar shape and a few mounting holes. It didn’t take long to retrofit the mounting plate to fit the Uno, by drilling a couple of holes in the mounting plate, and heat fitting a couple of long standoff nuts into those holes. I found that this technique is the best if you want to create 3D-printed PLA parts that you want to be able to disassemble later. Drill a hole that is a few mm smaller than the nut, heat the nut with a heat gun and then gently push it into the hole. Once it cools it should remain very firmly in place and you can place metal screws in one or both ends and tighten them pretty tight without the nuts slipping or coming out.
The return to the Uno meant that I had to make a choice; the bot had to either be autonomous or remote controlled. Not both, since there were simply not enough GPIO pins to support both scenarios. In the name of expedience, I abandoned the code for my loosely-coupled, message-based, interrupt-driven, finite state machine, and just took the original sketch I had created for the RV version of my bot. The result was a very zippy little remote controlled bot, which I had originally named “The Sixer”, for all of the new restrictions, but I decided that “Scoop of Death Junior” was a much better name.
Since I had already consumed most of the two days I had rationed myself to, I did nothing more to my bot until the day of the contest. I weighed Jnr that morning and it did not even weigh a full pound, despite my inclusion of weights in the scoop! It needed to pack on a few more pounds. So on the morning of the tournament I modeled a weight box for the back of the bot and set it to print. My fallback plan in case the print failed (because obviously that NEVER happens!) was to just cable tie bags of bearing balls to the front and back of the bot. The print finished with time to spare and I was able to firmly attach it to the body using the heated standoff nuts technique. I then filled the box with bearing balls, glued the box closed with model glue (mistake!) and headed off to the event, again without testing the bot (you may see a trend emerging here).
While waiting for the weigh-in I finally decided to test the bot. Everything worked perfectly… except I had put too many steel balls in the weight box, and significantly shifted the center of gravity of the bot up and to the rear. Now every time I drove it forward it would pull an awesome wheelie. This would not do! My primary weapon was my scoop, and a scoop is only good if it is under your opponent, not way up in the air! So I frantically ran back to my desk, strung some ball bearings on a cable tie and literally tied it on the front of the bot with hookup wire. It didn’t completely stop the wheelieing, but it did make it a little less extreme. In the end this wheelieing turned out to be something of a secret weapon.
The bravely-autonomous bot I faced in the first round, though cute, suffered from technical difficulties, and I was able to easily dispatch it. My subsequent matches were a little more challenging but I was consistently able to maneuver around my opponents, some of whom were remote controlled and some autonomous, and summarily push them out of the ring. I suspect that my advantage in most of these bouts (other than a human operator) was the weight I had added, since most of my opponents were using the standard kit that had been provided. Though I lost a couple of matches, I won every round, and then found myself in the semi-finals facing my nemesis from 2017 and the then reigning champion. He had also had to bring a new bot this year to comply with the new limits.
It was at this point that I thought I should put fresh batteries in my bot. This time I did test it, and the new batteries had made the wheelieing much worse! The extra juice was giving the motors extra torque – the lightest touch on the joystick had the scoop at 45 degrees and the bot headed forward at nearly full throttle. Perhaps I could use this in some way to give me an edge in the last couple of rounds. I had nothing to lose; I was in it for the Making, not the winning. If I let my opponent come to me, and get up over the lip of my scoop, I should be able to simply give it full throttle and use the torque to lift him, which should make it easier to push him out.
My opponent’s bot in the last two rounds (it was a double elimination tournament) was armed with 4x12v DC motors, while mine was running on the two “stock” 5v motors. In a straight head-to-head shoving match I didn’t stand a chance. In the end I suspect it all came down to three things – low latency, simplicity and build quality.
My decision to use a simple hard-wired controller, wired directly to two analog pins, meant that my bot was incredibly responsive. My opponent had chosen to go with an Xbox 360 controller, connected over RF to a receiver plugged into a USB shield, communicating with the microcontroller using a serial protocol. And those very powerful 12v motors were also a little on the slow side. My bot was significantly more agile and was able to move out of the way whenever we got into a head-to-head situation, and I was then able to come in from the side before he could turn, get the lip of my scoop under his treads, and then use the wheelie to lift and drive him out of the ring.
The other advantage was that my bot was very robustly constructed, and there just wasn’t a lot that could go wrong with it (other than human error – I lost one match because I forgot to turn my bot on). All the structural parts of my bot were 3D printed and either glued together with model glue or bolted in place. My opponent kept having technical difficulties, from his controller not working, to the treads coming off his bot. I suspect that if his bot had been just a little bit more robust, that I would not have stood a chance against those four 12v motors. In the end I suspect I won because I had to keep it simple to get it done in 2 days.
In the days since the contest I have continued to improve on the design of Jnr. I have added an additional weight box in the front and have reduced the size of the one in the back. Though it probably will not compete again I plan to print the parts and put them on the bot. I also plan to put all the models and code up so that others can improve on my design.
I continue to be incredibly grateful to Microsoft for the Garage, which has enabled all of this, and has given me the opportunity to learn so much.
Subscribe to:
Posts (Atom)