This robot uses a reprogrammed Flashlight Cubelet to cause it to blink faster and faster as the sensor values it receives increase. Turn up the music; you’re ready to party with your very own strobe light robot! OK, ok. This robot might not be the life of the party on its own, but it’s an easy example to get started programming Cubelets.
What sort of robot would do well if it lived on a white table? How could it sense the edge and stop itself from tumbling over? If the robot had to keep moving, what sort of abilities would it need to keep from driving off? If the table were to change shape over time… or the robot were to be placed on a different table, what kind of robot rules would help it avoid a variety of edge shapes and angles of approach? How would it look? Could you reprogram the Cubelets to help ensure the survival of a table dwelling robot? These are the questions that guided the creation of the Cliff Scout.
Since the Cliff Scout will need to continuously move around the table, we can use two Drive Cubelets to create a robot that can travel and change directions. We could attempt to solve this problem by creating a robot that drives in a tight circle. Unfortunately, builders will discover that Cubelets robots will drift over time, and this may cause their robot to fall off the theoretical table.
So, we’ll need to reprogram the Drive Cubelets so they can spin in both directions and we’ll need to create some sort of triggering pattern to tell the robot when to turn. To detect the edge of a table, the Distance Sense Cubelets are placed at the front edges of the robot. This placement ensures that the robot can sense the edge as early as possible to avoid falling off. Placing the Distance Senses near the edges of the robot helps it avoid falls if it approaches an edge at an angle. The Distance Senses face down and are oriented in a way that allows them to detect the table edge quicker, giving the robot more time to react.
You’ll need the following Cubelets to build the Cliff Scout:
- 2 x Distance Cubelet
- 1 x Battery Cubelet
- 1 x Bluetooth Cubelet
- 2 x Passive Cubelet
- 1 x Flashlight Cubelet
- 1 x Rotate Cubelet
- 2 x Drive Cubelet
The C files for each Drive Cubelet are available for download by clicking HERE and HERE. Use Cubelets Flash to reprogram each Drive Cubelet. Ensure that you flash Drive Program 1 to one Drive Cubelet and Drive Program 2 to the other. If you don’t, your robot won’t turn properly.
In order for the Drive Cubelets to respond to table edge detections, you will need to update the Block IDs so that they match your two Distance Sensors.
- Use Cubelets Flash to identify your Block IDs by connecting your Bluetooth Cubelet, Battery Cubelet, and Distance Cubelets. If you’re not familiar with Cubelets Flash, click here to view a helpful tutorial video.
- Power on your robot and pair with the Bluetooth Cubelet using your system preferences or Bluetooth settings.
- Then open Cubelets Flash, select your Bluetooth Cubelet and click “Connect.”
- After you’ve successfully paired. You should see a Cubelets “block-map,” like the one pictured below.
- Click on the Distance Sense icon to bring up your block details.
- Write down the Block IDs for each of your Distance Sensors. Then power down your robot.
- Open the “Drive Program 1” C file in a plain-text-editor or other coding environment.
- Replace the Block ID markers in lines 11 and 12. They are noted with the marker “INSERT_BLOCK_ID.”
- Save your C file and repeat this sequence for the Drive Program 2 C file. Be sure to save your file as a “.c” file. Some text editors don’t save as .c by default so you may have to change the file extension manually!
- Reconstruct your robot to match the pictured robot. Below you will find a couple pictures to help you match the robot design.
- After you’ve completed your design, power on your robot and connect to the Bluetooth Cubelet. You should see a new map with more Cubelets.
- Select one of the two Drive Cubelets (for this robot it doesn’t really matter which one you choose.
- Find your modified Drive Program 1 C file and drag it into the box to reprogram your Drive Cubelet.
- Wait for the program to finish flashing, then click on the remaining Drive Cubelet.
- Find your modified Drive Program 2 C file and drag it into the box to reprogram the second Drive Cubelet.
- After you’ve successfully reprogrammed your Drive Cubelets, you’re ready to test out your robot.
- Place your robot in the center of the table. Bright surfaces work best, so you may have to lay down some white printer paper to get the proper behavior.
- Turn on your robot to see if it worked. You may want to be ready to catch your robot if you’re worried about your construction. But keep in mind you need to keep your hands away from the Distance Sensors, or they may interpret them as part of the table and you’ll cause your robot to fall!
- Once you’ve succeeded, or if you’ve devised a better robot solution let us know about it online with the hashtag #cubelets
Happy Building and stay tuned for more intensive robot activities!
Note: When you’re done playing with the Cliff Scout, you can restore your Cubelets to their default programming with Cubelets Flash. Just reconnect your robot, then select the Cubelet you’d like to restore. Then click “Restore Default Firmware.” Select the next Cubelet you’d like to restore and repeat.
Last week we launched a Cubelets Operating System update. While the point three makes it sound like a minor update, it’s actually kind of a big deal. OS 4.3 improves a bunch of little things, and it definitively fixes one particularly nefarious bug.
You know how we’re always talking about complexity and emergent behavior? About how Cubelets can be a great model for complex systems we see in the world like societies, ecosystems, and economies? About how play with Cubelets will help kids develop skills to solve problems in complex environments? Well, even though we play with Cubelets a lot around here, sometimes emergent problems in complex systems can be a real bear to figure out.
Take the Nefarious Bug, for instance. Since the release of OS4, we’ve seen a few Cubelets spontaneously lock up and stop functioning. It happened every once in a while in our factory, and we heard from a few customers that the same thing had happened out in the world. When we took these “bricked” Cubelets apart, we found that each one was missing a tiny little piece of memory — a random line of programming had somehow been erased. And while I can function pretty well having no idea what I ate for breakfast yesterday, the microcontrollers inside Cubelets are a little more brittle, their memories need to basically be perfect in order for them to function at all.
I’ll spare you the rundown of our debugging process. Suffice it to say that hypotheses were made, tested, and then re-made. Ideas and hopes and dreams were repeatedly generated and then dashed. It took weeks, but we finally figured it out. It was the combined behavior of a mechanical bug, an electronic bug, and a software bug, but we fixed it just with software.
The particulars of the problem are a bit obscure. Are you familiar with the Rotate Cubelet? If you’ve ever wondered how the rotating face can conduct power and data without a bunch of wires getting twisted up inside, the answer is that it uses a slip ring. Slip rings have contacts that slide around a rotating ring, using friction to make electrical contact. Sometimes this connection isn’t perfect (at least not as perfect as a soldered wire) so there tends to be some noise on the power line near Rotate Cubelets. While this shouldn’t be a problem, a big Cubelets robot has power flowing throughout all of the Cubelets and through all of the faces, and a bunch of noise on a bunch of connectors all at once ended up causing low voltage transients that wreaked a little havoc on those tiny, tiny brains.
Previously, Cubelets were riding a fine line between the voltage level at which they’d automatically shut down and the voltage level at which they could brick themselves and apparently (in less than 0.1% of Cubelets), noisy rotatey power connections could shock the Cubelet into crossing that line. Once we finally figured this out, it was pretty straightforward to repair by changing a few settings in software and testing profusely with the noisiest Rotate Cubelets we could find.
I’m Sawyer Bernath, Co-Head of Production at Modular Robotics. I started as an assembler four years ago, spent some time running our circuit board assembly line, and then moved into my current role. I’ve never written on this blog before, but something happened that I really wanted to share!
Earlier this month, Modular Robotics attended the first ever Colorado Manufacturing Awards, presented by CompanyWeek and Manufacturer’s Edge. We were nominated in the Aerospace & Electronics category, alongside Sierra Nevada Corporation’s Space Systems and Seagate. To be honest it was pretty intimidating, and we initially weren’t sure if it was even worth attending. We make toys. What are the chances our tiny robot factory could beat out a major satellite maker and an industry-leading storage manufacturer?
Apparently our chances were good, because we won!
After walking all the way to the podium from our spot in the back, I gave an awkward acceptance speech and rejoined our crew at the cool kids table (beer and toys). We were sitting with the guys from Ska Brewing and Colorado Malting Company, two other medium-sized companies who won their respective categories. It was pretty crazy to see CMC beat out Arrow Electronics, a Fortune 500 electronics supplier.
Overall, I was struck by the number and variety of attendees at the ceremony. Part of me was expecting a small event full of people trying to sell me stuff for our factory. But it totally was not that. The vast majority of attendees were bona fide Colorado manufacturers, making awesome products, and passionate about this growing sector of the Colorado economy. It’s a community I’m proud to be a part of.
Have you ever read Vehicles? It’s a favorite around modbot because it’s basically a set of thought experiments about how we can understand the world through simple robotic elements. As Braitenberg adds simple pieces of technology to tiny robots, the reader starts to see how lifelike complexity really can emerge from simple building blocks.
One of the little technological enhancements that results in interesting emergent behavior is stacking up simple sensors in a grid: this enables a robot to detect not only whether anything is in front of it, but to detect certain things. Apparently, we actually do a little bit of thinking with our eyes.
Take this simple Cubelets robot, for example. It’s a grid of twelve Distance sensors configured into a secret lock that can only be opened by a special key. Sure, Cubelets are robot blocks, and the resolution of the sensor grid is pretty low, but 2^12 means that there are 4096 possible combinations for a secret key. Pretty hard to hack for a toy.
Status lights are boring, though, right? Since Cubelets are modular, we’ll just snap on a few Drive blocks instead and turn the lock into a locked door. Look, candy!
I built these two robots a couple of weeks ago with a brand-new Cubelets programming system and I’ve been waiting to share them until it’s ready to launch. Today’s the day; if you’re interested, take a look at Cubelets Flash, download it, and start building some crazy custom robots.
Your Cubelets will all need to be running OS4 to connect to Cubelets Flash. Right now, if you have old Cubelets, you’ll have to use a mobile device running the Cubelets app to upgrade them first. This workflow is a little funny because we screwed up. We used to be able to program OS3 Cubelets using Cubelets Studio, and when we launched OS4 it was incompatible with Studio. It took us longer to release Flash than we thought it would, and I know that a lot of you are pretty excited to program your OS4 Cubelets. Right now it’s in beta release with only the most important functionality so that we could get it launched for you to play with as quickly as possible. Enjoy.
We just had a two-day Modular Robotics retreat in the mountains. We skied on Wednesday at Winter Park, stayed in a big house in Fraser, cooked together, and spent Thursday working on strategy and planning.
This year was different from last year; we brought all of the carpet people (carpet people are all non-elves) at modbot instead of a carpet subset. It was great: every time we take a day away we seem to make amazing progress. I started off Thursday with a little story about why I Modular Robotics and what gets me up in the morning and I thought I’d share it here too:
I’ve spent some time recently with my friends’ kid who is three years old. Her incessant “why” questions can often prove thought provoking. No matter how deep she digs, you can never tell a kid that something is just because it is. Although questions of fate and trajectory are interesting for adults to discuss, telling a kid that something happened because “it was meant to be” is just a cop out.
Her lines of questioning got me thinking deeply about why Modular Robotics?
Of course, that question has many answers. Because of luck, coincidence, being in a certain place at the right time, and because of a million books read, chance encounters, and free associations. But why am I doing Modular Robotics? is easier to answer.
I started and am running Modular Robotics because I want to give people tools that will help them think better about complex systems, emergence, and the ways in which the world really works. Why? Because better thinking about complexity will help us solve the world’s big problems.
I get frustrated sometimes not just by big problems in the world, but in our reaction to them. It feels to me like most of the time, our reaction (and probably, the way that we think) is often gross oversimplification. It’s an election year, for example, and if we think hard, we know that platforms and governance comprise an extremely nuanced and complex system, with thousands of interacting parts and conflicting aims. A glance at the news, however, paints issues in terms of black and white, red and blue, praise or outrage. Things are more complicated than that, and a failure or refusal to dig a little deeper and try to understand things a little better leaves us making bad decisions.
Consider social problems, mass shootings for example. It’s universally recognized that we should all work together to reduce this sort of thing, but it’s hard to find a smart conversation about it and not a thousand shouting matches that sound like “I love guns” versus “I hate guns”. The world is not that simple, and I think we can learn to think more deeply about problems in the world and make forward progress as a species.
To really understand complex systems, patterns, and emergent behavior, we could all study complexity theory, cellular automata, and chaos, but those are abstract, rarefied fields accessible usually only to academics. I think we’ll have better results getting kids to think differently about complexity, because their minds aren’t already made up and set in their ways.
Complexity science is all about taking things apart: looking at real world systems and distilling them down into theory. But kids, and adults, often learn best by building things. When we build things, or design things, we can see many different combinations of simple pieces we understand.
People have been trying to give kids little models of complex systems for a while, but most of those have been apps (the Sims, even) or other systems that encourage you to select some pixels and watch scenarios play out on a display. I think that sometimes pixels on a screen aren’t the best models for real-world systems, but that sometimes, robot blocks might be.
I’m not saying that playing with Cubelets teaches kids complexity science. But it helps them develop intuitions about complexity, emergence, patterns, networks, computation, and lots of STEM subjects, so that when they encounter those things later, they make sense. Playing with LEGO as a kid, by way of analogy, didn’t teach me the physics of friction, balance, shape, mass, and force, but when I got to Physics in twelfth grade, the laws made sense, and the equations were just another way to describe phenomena that I was already familiar with. Some people, who hadn’t gained these intuitions through experience, were lost in a sea of Greek letters.
I think that sets of robot blocks, designed, distributed, and well supported, can help make our kids smarter about the world than we are. I want to have a really broad impact with Cubelets and change as many kids’ minds as we can. That’s what gets me up in the morning.
Modular Robotics is in full North Pole mode, building as many Cubelets as we possibly can. Demand for the new Cubelets TWELVE kit is off the chart, so we’re working extra shifts and late into the night six days a week to make as many as possible. In other words, the factory is crazy. It occurred to me that unless you’ve been by, the last photos of the factory that you may have seen were from April when we moved into our new, then empty, space. The architects who helped us with the remodel came by the other day and put up some beautiful pictures of our factory in a blog post. Take a look here!
To celebrate the newest Cubelets Robot Blocks pack, we’re giving away 12 Cubelets TWELVE packs. Enter for a chance to win using the form below and best of luck!
Don’t want to chance it? Guarantee a pack of thought inspiring robot blocks this holiday season by ordering today!
A friend just emailed me a link to a video of a talk that I gave last year at Big Kansas City. I’m pretty happy with this one! If you want a 20 minute version of what we’re up to at Modular Robotics, this talk is way better than the TEDx one where the slides didn’t work and I ended up sweating profusely and waving my arms around.
Yesterday I tried a little experiment with my schedule: I switched all of my regular on-one-one meetings for the week to Tuesday, a single day with nine meetings in a row, no break.
The idea for this actually occurred on February 5 of this year, at our Q1 board meeting. I’m a little embarrassed that it took me this long to try. You see, somehow I found myself complaining to the board that I wasn’t able to find enough time to work on a few big projects that I knew I needed to be working on. This is not the typical stuff of board meetings. Anyway, I explained how for the last couple of years I’ve kept Wednesdays clear on my calendar, usually worked from home, and used it as design/writing/solo-thinking time because the other four days get consumed with collaboration: one-on-one and group meetings with the eight people I work most closely with at modbot. But lately, the collaboration days had gotten so busy, that Wednesdays had turned to email and administrivia catchup days and I needed more time in the week…
Brad made a suggestion: what if I were to completely flip the ratio, stack up all of my one-on-one meetings in a single weekday, and have four days to do my own work. I remember my head starting to explode a little bit and looking over at Mark and Mike who were nodding reasonably at me as if to say, “seems like a perfectly smart idea.”
While it might seem scary to stack up that many meetings in a row, I wasn’t too fazed by the idea: I like everyone on my team and the conversations are usually flowing and genuine. The part that gave me pause was wondering, all in an instant, what I might do if I had four-ish days a week to move things forward with my own projects, instead of less than one. Would I head to Japan and see what kind of cool tiny robots are happening there? Would I play around in our lab with electromagnetic bits and plastic? Check in with some of the robot labs at CU Boulder, right down the street? Finally build those little wooden robots we’ve been sketching for years? Look through a recent set of conference proceedings? Visit the Bay Area for a few days to catch up with my hardware startup friends? Read a few books about leadership, management, and inspiration and work on the parts of being a CEO that I suck at?
The idea was almost too much for me to process, but sounded tremendously tempting all the same, so I vacillated for a while before finally trying it yesterday. I’m happy to report that it was a great success! I learned some things!
Sometimes I do a little journaling in the morning. You know, Artist’s Way style or Jerry Colonna style. Previously, on meeting-heavy days, I’d think and write about the big important things that I needed to get done. Then I’d have a busy day of meetings and spontaneous business stuff, and in the evening I’d feel stressed and annoyed about not making progress on any of my big important things. Yesterday, though, I told myself in the morning that I wasn’t going to make progress on my stuff during the day, but that I was going to meet with a bunch of individuals, be present, listen, and see how I could help them. And that that might have compounding returns, and that it was valuable for modbot and an important part of my job. I think I did pretty well at that, so at the end of the day, I felt fulfilled and not exhausted. That sort of surprised me a little bit.
Another thing surprised me throughout the day. Having all of those meetings back-to-back made it easier for me to see a few trends. If the meetings had been spread throughout the week, I might not have noticed that multiple people were worried or nervous or thinking about a couple of problems that we should probably address directly and together. So we’ll try to, and that gives me a little bit of the great “we’re getting better at getting better!” feeling.
I’m not sure if today has been a great first result of having a clear meeting calendar. I went to the dentist and got a cavity filled, played with a test version of a new Cubelets operating system, and wrote this. But it’s a start. I’m definitely going to continue trying this meeting rhythm for a few more weeks.