FNR – BubbleBoy Behaviour AI

Posted by Erin, the RobotGrrl on Monday, July 12th, 2010

This week and this Friday Night Robotics I was working on a behaviour AI for the newly refurbished BubbleBoy! It is much easier to design an AI that you know will be interactable with thew orld! Without the headbobbing capability of BubbleBoy, this effort would not be worth it.

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!)

Posted in: Programming, Projects, Robot.

Grabbing MANOI’s Accelerometer and Gyro Data

Posted by Erin, the RobotGrrl on Wednesday, June 9th, 2010

Last FNR I embedded MANOI’s Accelerometer and Gyro into its back. Usually what people do first when they add these motion sensors is make their robot self balancing. For now, I’m going to see if I can do something a little cooler.

The idea stems from a Fast-Fourier Transform result for sound- where you can see the various volumes and such. (Check out my Processing Fancy FFT). What I’m aiming to create is a FFT for motion. Basically, if you move MANOI around, the algorithm will be able to detect a pattern and do stuff afterwards. Essentially what this is leading up to is an interesting dancing robot. =)

I’m starting off with a Processing program that will visualize and log the data (see above screenshot). I envision a split-view display with two cubes. One will be showing the live sensor input, the other will be showing the results of the pattern algorithm to the live data.

No idea yet how the algorithm will turn out. I’m probably going to start at a very basic level, and perhaps add complexities on later. It will be interesting to see how this will turn out!

Soon to be blogged…

• The FNR that I mentioned, but didn’t blog about
• RampageRobot!!!
• RoboGlyphs

Posted in: Programming, Projects.

Arduino SSC32 Library

Posted by Erin, the RobotGrrl on Tuesday, May 4th, 2010

When you google “Arduino SSC32″ my tutorial on Nuvvo is the first to show up, I figured I might as well make a library for the Arduino to help the other users out there get started with their SSC32.

There are three main parts to using this library:

• Initial positions
• Frames
• Set the frame

The initial positions are going to be your home position of all of your servos. For a humanoid, this is usually a standing position that is balanced. Setting the initial positions looks like this (in general):

In animation, the still pictures that make up a movie are called frames. Moving a bunch of servos or a robot according to frames would make sense. Here is an example of a home frame:

Initialize the SSC32 library by setting up the object like this:

The true/false parameter does not effect anything. It has to be there because, for some reason, the library doesn’t compile with no parameters.

In the setup() function, the servos have to be enabled. For MANOI, the arms are plugged in to ports 0-6, and the legs from 16-24 and the bad knee is on port 31.

The last step is pretty simple- just set the frame using this function:

Example:

Delay time is the amount of time you want to delay after the movement. Move time is how long the servos take to go from their current position to the positions in the frame.

Things that you must do in order for the library to work (mainly common sense):

• The frame references the position of the servos in sequential order. Meaning, it’s servo #0, #1, #2, #3 … #31. You can’t mix the order around, it won’t work.
• If the servo is in the frame, it has to be enabled. If it is not enabled, then everything will be confused.
• Have the SSC32 connected to the Serial port. If you need it to be Serial1, then you can change it in the library’s cpp file (just do a find+replace) ^_^

The SSC32 library uses the Arduiniana Streaming library. Be sure to download and install it into your sketches/libraries/ folder!

Download the SSC32 library here!

There is an example included.

Let me know of any bugs that you find, or how anything can be optimized!

Posted in: Programming, Projects.

Robot Operating System – turtlesim

Posted by Erin, the RobotGrrl on Monday, March 22nd, 2010

The Robot Operating System is a Free and Open Source software bundle of amazing libraries that can be used with your robot. There are oodles of libraries– OpenCV, Wiimote, iRobotCreate (!!! WOOT), NAO robots… and many more.

Installing the ROS has been an interesting process for me. I started with my Mac, which didn’t work (at first), then went to my Ubuntu 7 machine, killed it… Tried again on my Mac, followed everything down to the error that “file is not of required architecture) … Then I had Ubuntu 9 installed, installed ROS… posted a question about a “bug” (more of a misunderstanding on my end ) on the mailing list… and BAM! IT WORKS!

So, all in all:

• Haven’t made ROS work on a Mac yet
• You need to run roscore to initialize the ROS nodes
• This is awesome.

More later!

Posted in: Programming, Projects, Robot.

CMUcam2 in Matlab! & Project updates!

Posted by Erin, the RobotGrrl on Wednesday, February 24th, 2010

On Sunday, a breakthrough was made with regards to getting the CMUcam2 to send a frame back to Matlab! Amazing! It works!

Check out the screenshots:

(something bright was being shone onto the camera)

(lens cap on (yes they make lens caps that small))

It’s quite noticeable that the resolution is very small. In fact, it’s only about 10 pixels in size!

I started off small so that we could have something that works, then go from there. It’s only sending the green channel too, which helps improve the latency.

The way it works now is that it asks for a few hundred bytes of data. From there, we search through the array to find a 1, or the start of the frame, until a 3, or the end of the frame. This is stored into a new variable so that we can search through it (again!) and plot the data.

Plotting the data needs some improvement. Not too sure how to handle this yet– should I make a Processing app that will be able to save the image as a .png? Or can Matlab write images too? Hmm!

Post a comment if you want me to post the code, I just don’t want to post something that’s incomplete and will essentially confuse everyone.

Other projects statii:

PR2 Proposal

Out of the 120 Letters of Intent that WillowGarage received for the PR2 Beta program, one of them is one from Clarkson University!

There are ten robots that are going to be given away. Coincidentally, the research teams that win will be notified on March 26th — that’s the date of the Boston FIRST regional (which Team 229 is attending and is going to ROCK THE ROBOT HOUSE)!

We’re giving it our best shot, and it’s looking really cool! If you see me around, ask me about it!

This whole process has been super exciting. Our proposal is being wrapped up, though it’s only due March 1st (that’s in six days, we still have plenty of time). My two sections are pretty much complete except for some stuff. I’ll be blogging about it on March 1st at 8:00PM, so keep an eye out!

---

Sociable Robotics

The Socializing a Social Robot with an Artificial Society SURE abstract from the summer has been added to the Honors Summer Research 2009 page! Finally! ^_^

Also, I refined my paper with logic that can easily be followed now, and included Zoomify graphs of the results. This makes it easy for readers to scan and interpret the graphs themselves. Plus, Zoomify graphs are always fun.

As for the code… I still have to get on to documenting it. It’s a lot of work, so I’m just getting through it step by step. Lesson learned: although comments are distracting when you’re working on the code, it’s horrible to go back and then spend time to comment it. Always comment. No exceptions!

---

SecondLife Statistics Project

We finally parsed through the data and found something really striking. When the economic downturn in real life appeared, the usage hours on SecondLife rose, and kept on rising for a few months! The virtual economy was booming. It’s almost like as if people were tired of the real life, and wanted the easy success of the virtual world.

Though, there was eventually a decrease in the usage hours on SecondLife. This leads us to wonder if…
1) Is there a lag between RL and SL?
2) Did people notice that there weren’t as many opportunities on SL as when they first joined?

It’s really cool to think about this sort of stuff. It makes you wonder what Oreo sales have been like throughout this modern recession. I would love to study Oreo sales, I think they would be really representative of the economic situations. Either that, or Oreo sales always remain constant.

---

Team 229

This build season I helped out with the website a lot. We were coming from nothing, and now we have a beautiful source of information, all collected together!

It was quite a load of work, however help from the teammates and mentors helped very much. Go check it out!

---

Physics Team Design

In Physics II there are two lab sections that allow you to participate in a team based design course. The challenge is to model the velocity of a hobby train with given voltages. We do this using photogates… and a piece of National Instruments hardware that measures data at a rate of 400,000. I’m not sure what the units are, but it’s pretty amazing! The challenge sessions are where we apply this model, trying to predict the train’s movements based on the data that we have collected.

The way the data is collected is through LabView. Unfourtunately, the program that is used was deleted… so the professor/TA needed some help to fix it. After working on it for a few hours, we figured it out and got it to work!

---

iPhone Stuff

I’ve been playing around with core-plot and working on an app lately- it’s 80% done, and will be out on the App store within the next few weeks!

We’re still trying to sort out if we’re going to Open Source it, and how that would work (since we want people to buy the App too…!). Perhaps we could just *suggest* a donation whenever people try to download the code? Anyone have any experience with Open Source App business model plans?

---

Random

Coming back from winter break to school was tricky this time around… since I was outside the entire day playing hockey during the break!!! Although Clarkson has open skate, their ice mixture is really weird, and there’s no pickup hockey games Better than nothing, though.

I bought two shirts from shirt.woot, and they are awesome. One of them is ‘I Fought the Laws’, and has three pictures of crazy robots. The other is a robot that is plugged in to a wall outlet, leading to its heart. ^_^

---

That’s all for now! Keep it real, humans and robots. =)

Posted in: Art, Other, Programming, Projects, Robot, School.