On Thursday we had a Robot Party LIVE from EMSL! There were many technical difficulties, but we appreciate everyone who showed up to the Ustream and participated in the hangout afterwards! Next week will be better because there will be faster internet. Yay!

While I’m here one of the things that has to get done is making RoboBrrd as a kit form. There’s lots of questions and redesigning. Here’s some revised CAD! As you can see, much more thick than the previous versions.

The beak mechanism is going to be a little different too. It will be a hinge using the same plasticky material as on the eggbot. I tried unsuccessfully to rip this material, it’s extremely durable!

Speaking of material, this is the 6.35mm (1/4inch) basswood. Wood is significantly less expensive than acrylic, more sturdy, can assemble strong using wood glue, anyone can drill into it easily, and best of all you can paint on it

Trying to figure out the kerf was a little horrible. With this material, a friction fit isn’t entirely necessary (because you can glue it), but having a bit of friction is nice. It took me a lot of tries, it was an epic fail, but eventually figured it out in the end!

Next time I’ll do a better job at figuring out kerf values. Live and learn.

Laser cutting the pieces is pretty fun! You have to mask the basswood before cutting otherwise there will be goop near the edges, making the piece a little discoloured and sticky. The basswood smells great!

Sometimes there are issues with cutting all the way through since basswood is a natural material. Sometimes it heats up a lot and you get bright sparks. You really have to keep an eye on the laser cutter and make sure you have an action plan if things get out of hand!

Inventor is so fantastic to figure help make sure all the tabs are lined up. I found a pretty cool program on Windows that can take timelapse screenshots, so this weekend perhaps there will be enough for yet another funky timelapse video!

Skipping along to the boards now, the boards didn’t really work before- but the issue was found and solved! Turned out the reset line didn’t have the capacitor and right resistor on it. Wooops! When that fix was made, it FINALLY WORKED! Uploading code and blinking an LED!

It also works great with the Googly Eye shield

However it did not work with the LoL Shield just yet. Perhaps it might be as simple as a power issue (because the 5V header is messed up on this one because I was trying to desolder something but failed). This will be debugged later on!

Speaking of desoldering, check out this really cool soldering station they have! The soldering iron is a Metcal, it heats up via RF waves rather than a heating element. It takes only 7 seconds to heat up! Holey moley!

There is also a very nice microscope here. You can look at a breadboard so close you can see deep into the breadboard holes. It’s like your trapped inside a breadboard and you can’t escape! Here are some pictures of various things taken with my iPhone. There is a camera mount, but there needs to be a better lighting setup for the photos to be captured properly.

We have visited a lot of interesting places around. Sooo many interesting places around here! The electronic stores are REALLY STELLAR! We also went to the SawdustShop (kind of like the TechShop but for woodworking), and I saw this clever hinge on a box that was neat!

Here was another cool place to go to, the Homebrew Robotics Group meeting! It was really cool to be with other robot builders as well. There are some really great robots there, and a lot of them were very successful at RoboGames! I presented my RoboBrrd at the meeting, it was fun! (Thanks @mifulapirus for the pic!)

This here is one of the main things I’m tasked with while being in the lab. Sort of. It should be really slick when complete. It’s pretty challenging as it is some stuff that I haven’t played with before!

In addition to all this amazing brain food, I’m learning how to make real food too! A huge part of this is making bread. Bread is actually quite optimal to make, more people should make it! Most of the food turns out to be really delicious. There’s lots of lemons, since lemons grow on trees here! This here is one of the nicer things, we made sorbet in a gelato machine. It was excitingly good!

At some point this week I will make some robobrrd and robot party hackerspace passport stamps! I unfortunately didn’t bring my Wacom tablet, so I’m not sure how I’m going to get the drawings into the computer. Eek! Hopefully the drawings will be spiffy enough!

RoboBrrd is of course enjoying its time sitting on the desk and watching cool stuff happen! Chirp chirp!

That’s all for this week! (Actually it was last week- this was supposed to be posted on Sunday haha) I’ll be posting up some more interesting things in the future! Maker Faire is swiftly approaching! Thanks to Lenore and Windell for the help so far! If you have a robot be sure to come to the Robot Party this week! It is going to be really exciting!

BubbleBoy’s behaviour is primarily focused on food and water. BubbleBoy lives its anthropomorphized life just be be fed/watered! This means that BubbleBoy will want to know when it will expect to be fed, so that way it can headbob at the most optimal times. Being fed/watered is having a button pressed on BubbleBoy’s green stage area (the part with the blue and white LCD).

BubbleBoy will have three sensors, and a rudimentary measure time. The three sensors are the LDR, lid switch, and Xbee. All of these are onboard the robot (except for the Xbee which isn’t implemented yet).

Here’s a broad flowchart of the behaviour, which I will then explain below in detail.

1. Creating the Expectation

This is the observatory phase. BubbleBoy initially does not have any expectation of when to be fed, so it waits around. While it is waiting, its collecting data from all of the sensors and storing them to an array. There has to be 10 numbers in the array for each sensor before BubbleBoy can proceed to the next stage, pattern finding. Once this is fulfilled, and if BubbleBoy is fed/watered, then it goes on to find a pattern.

2. Pattern Finding

BubbleBoy is seen as a simple robot. Thereby, its pattern finding is relatively simple as well. The main idea is to check each sensor’s array and see if there is a pattern within the residuals. Meaning, if looking for a sequential pattern, the array would be iterated through (starting at i=0, stopping after i=8), and i+1 would be subtracted from i. An average of the residual change would be calculated at the same time. The array would be iterated through again, this time to count how many items are within +- 10% of the residual average. If the count is above 7, then it is said that there is a sequential pattern in there.

The same process is done for a secondary pattern, and a ‘thirdary’ pattern. Meaning, every 2nd number and 3rd number is checked to see if there is a pattern. It also goes through and checks with offsets, just incase the pattern is “even/odd/whatever”.

If there are no patterns, a random primary sensor is chosen for BubbleBoy to work with.

A problem exists in determining which pattern for which sensor to trust the most. A thirdary pattern for a photosensor is less dependable than a sequential pattern for a lid switch. This is handled in the next step.

3. Determining the Sensor to Use

The sensor with whatever pattern to follow is chosen through a Bayes Filter. This allows for a simple specification of confidence levels for a given sense resulting in a particular state through a table where all rows add up to 1.0. The sense columns are the sensor and pattern type. Meaning, there’s three sensors for every sensor, giving 9 senses in total. The states are confidence intervals. Anything >= 85 would be considered the most confident.



The numbers in bold are the ones that are more probable to be a result. A sensor in particular to look at is the Xbee for a thirdary pattern. The numbers are dispersed in such a way that it is almost a bimodal distribution. In order to understand why this is, imagine the scenario in real:

Xbee modems can communicate for up to a few meters. If BubbleBoy only receives a message every 3rd instance, it could either be a clever pattern, or it could be a miscommunication.

For this reason, the largest probability is given to the least confident state, and the second largest probability is given to the most confident state. It depends on the Bayes Filter and random roulette for what will actually be chosen.

This is just for determining what sensor is the most confident, that will provide the best result. This can mean that the chosen sensor will be followed, but it also may not. This will be explained in the next step.

4. Calculating the Cost Adjustment

The adjusted cost is determined by using the result from the previous step, and multiplying the probability by the inverse of whatever column it was situated in. In simpler terms, if the result was found in the best confidence interval state, then it would be multiplied by 5. If it was in ( 85, 70 ], it would be multiplied by 4…

This is then used as the sense for the next Bayes Filter. The state is how much of a cost to reduce the sense by.



Once the cost adjustment amount is determined, it is then subtracted from the cost of the particular sense’s cell. All of the senses are in a grid, with the most “primary” being the closest to BubbleBoy. An A* search is then used to choose the closest and least cost sensor. Once this is done, BubbleBoy can get on to entertaining its audience while waiting for food/water!

5. Following the Expectation

This is the main loop of the program. It’s where BubbleBoy is thinking in the present time about if it will be fed or not!

The key idea here is that BubbleBoy is thinking in the now. Meaning, it tracks the patterns differently than it does when it is reflecting back on them (in a “past” thought).

Sensor data is retrieved and placed into an array of size 10. The data at i is checked wither it is within +- 10% of the average in the pattern. The threshold percentage amount differs for the type of pattern, where secondary would be +- 20%, and thirdary would be +- 30%. If the data fits in to the check, then a “yes” counter is incremented.

Once the “yes” counter is >= 6, the food level will begin to decrease by (i/2)^2. At the same time, BubbleBoy will begin to show signs that he is excited to be fed/watered soon, by spinning its hat and bobbing its head.

If the “no” counter is >= 6, then it means that the expectation isn’t really working in the present thought. A flag is set to redo the expectation once BubbleBoy receives food and water.

i is then either incremented or reset to 0, depending if it hit 9 or not. (That’s a sort of obvious step)

6. Real-World Behaviors

When the time elapsed from not receiving food exceeds 150% of that of the observed elapsed time, BubbleBoy goes in to a “wallow” mode. When BubbleBoy is wallowing, it spins its hat slowly, and bobs rarely.

If the time elapsed is ( 150%, 100% ], BubbleBoy is “angry” because it did not receive its food exactly before the time elapsed. The hat will not spin, and BubbleBoy will bob side to side, and once (quickly) in the opposite axis to simulate a sort of “twitching” to all this anger!

If the time elapsed is ( 100%, 85% ], BubbleBoy is eager to please. Hat tricks will be common, same as delightful bobbing. Depending on how much food/water BubbleBoy has, it may also hoola hoop!

7. Last part of Following the Expectation

Depending on when BubbleBoy was fed, if it was in ( whatever, 100 ], the expectation will be done. Essentially, BubbleBoy is a positive/eager thinker that believes it should always be fed before the elapsed observed time. What an attitude!

If it is in [ 85, 100 ), then the expectation will be kept.

To reformulate the expectation, the previous steps are executed on the collected data. Then, everything repeats!

What will be super interesting to see, in my opinion, will be when the discrepancies occur from past thought to present thought. It will be interesting to see which sensors fare better through that transformation.

It will also be interesting to see if this actually can work on an Arduino, and not in simulation. I created a simulated version of BubbleBoy in Processing earlier in the week.

I’ll do the initial coding and testing through this simulation, mainly because I already coded the Bayes Filter Algorithm (with random roulette) in Processing from 2009 Honors Summer Research. Plus, in Processing it is very simple to communicate to an Arduino through Firmata. I can read in the data from BubbleBoy through there.

Hopefully next Friday I will have devised a test sequence to test the soon-to-be-coded AI on. This will of course be Open Source, under the Attribution-NonCommercial-ShareAlike 3.0 Unported License (BY-NC-SA).

Let me know what you think of this AI in the comment section below! (And yes I know it is very linear, but BubbleBoy doesn’t have enough DOF in the real world to spend the effort making the AI more nonlinear, since the observed result will essentially be the same!)

The idea stemmed from the want to make a robot that can drive around on a table but not fall off. In particular, the table would be the table for the Autonomous Robotics Club at the admissions open house activity fair ^_^

Ultrasonic sensors are usually the best for this, since it depends on distance. Though, one could easily make a mechanism to trigger a touch sensor… or one could use a light sensor, but there is more possibility for error with a light sensor.

The design right now has the ultrasonic sensor sticking out more that that, since it wasn’t far enough out… this means that sometimes the NXT couldn’t tell the motors to stop in time, and it would fall off the table.

The motors are geared to be fast, since I want it to be fast like a fish!

The screen displays the ‘water level’ for the LED fish. In the picture, it used a method of drawing the level line by line, but I later refined it so that it uses a rectangle, and increments 3 pixels more so that it’s noticable when one presses the button.

The robot can zip around pretty quickly, which produces some interesting artsy stuff:

The LED fish are on the back of the robot, and the speed of their blinks is determined by how much ‘food’ they have. The more food, the more fast it is, the less food, the slower it is. When you press the button to feed the fish, it makes a bloop sound

The LED fish is what makes this project. No one can resist the power of super-cute LED fish. They’re just so happy!

Here’s a video of the robot in action. It’s running the old program, but it’s all pretty much the same thing

The code for this is pretty cool. The NXT can handle up to 10 different simultaneous tasks! I use this to check the sensors for food and water, drive the robot, and blink the LED fish at the same time. Now, I’m still experimenting with the code, which is why there are bugs, random functions, and no comments in it.

Eventually, I want to have the robot able to drive around in a square (a big square) autonomously. The square is around one of the dorm buildings, so there’s brick walls, stairs, fences, and people to avoid. I think it would be cool because the square is just so confusing at first. You can walk around it 5 times, and still think that you have gone somewhere.

Since a lot of smart people do this, if a robot does it we could imply that it is smart! Bahaha! Logic prevails!

I mentioned that this was originally intended for the activities fair. I also had MANOI there, doing its handshake routine! It went really good. We had a good 15 people show interest, which is surprisingly more than the orchestra, and the tables adjacent to ARC.

But, the table got hit by a frisbee. (Yes, my robot got hit by a frisbee) So, thanks to the jerks at the frisbee club, they messed up MANOI’s other knee (the good one– or what was the good one). So now MANOI has two bad knees, and can’t walk. The goal that I just obtained got wrecked. By a frisbee. Frisbee sucks, really bad.

(so, don’t join frisbee club, they’re morons)

Japan’s Ministry of Economy, Trade, and Industry (METI) 2007 Robot of tthe work-horse, industrial robot from Fanuc Ltd. called M-430iA. The multi-axis, greaseless (read: sanitary) robot is part of a food and pharmaceutical handling system. Unlike your unemployed uncle with his GED, this bot can work non-stop, 24 hours a day, accurately picking up 120 items per minute as they roll down a conveyor belt.

That’s cool, they have an annual ROBOT AWARD! I would get a kick out of it if it was named Yeti though. All jokes aside, a greaseless food handling system sounds great. Yet, with these robots comes unemployment issues. As the article mentions, "Unlike your unemployed uncle with his GED, this bot can work non-stop, 24 hours a day, accurately picking up 120 items per minute as they roll down a conveyor belt." that is great, but there should be a limit. Unemployment sucks, and many small towns depend on their local manufacturing plants to keep a steady payroll. I’m all for innovation, within limits.

Link.