9:00 am.

After a few iterations of the tube and wheel idea, our cherry dispenser is perfected.  We initially tried a model magic version of the wheel, which wasn’t precise enough:

Model Magic "Pac-Man" shape...

After some fooling around, we finally got to our final design. We cut up sheets of plastic and used a glue gun to assemble a water-wheel type of mechanism around a LEGO Wheel Hub:

Our successful, "water-wheel" mechanism.

The plastic sheet in front is to stop more than one cherry from falling out at a time.  The red stuff you see around the clear plastic tube is tissue paper, to cushion the tube and hold it gently in place in its LEGO cage.

11:41 am

Our first sundae!!!!!!! It’s not perfect, but it tastes pretty good.

Movie on 2011-06-28 at 11.37

3:00 pm

We’ve spent most of the day making sundaes for everyone!  These run throughs have led us to make many small adjustments to the Robo-Sundae Creator.  We ran into a small problem when one customer wanted no cherries.  Our program, however, didn’t recognize that correctly and gave him…infinity cherries.  We’d had it set so the cherry dispenser would continue going until the number of times it had dispensed matched the number entered by the customer: sounds good, right?  But the counter started at 1, so if a customer entered 0, it would never get there.  It was a relatively easy fix.  Here are all of our final programs:

Station 1:

Station 2:

Station 3:

Line following:

We also had to make a small addition to Bowl-Bot: a choco-shield for those unfortunate times when the chocolate syrup comes out for a bit too long.

You may also have noticed that we ended up laminating our paper track—it only took us two significant spills (and subsequent ripping out and replacing of ruined paper) to figure that one out.

Final Thoughts…

So what’s next? This is our last blog entry.  The design, construction and programming process is complete!  We have created a series of robots that work together wirelessly to produce a customized ice-cream sundae.  If ever we feel compelled to return to the project, we could always add more topping stations (candy, cookie crumbles, different syrups etc) or automate even more of the sundae making process (scooping ice cream, spoon dispensing, etc).  We’ve learned a lot while tackling design issues, and remembered the struggles and satisfactions of tackling a truly awesome problem.  Before we tackle another, we are working on turning our work into a comprehensive feature that will hopefully inspire others to tackle their own “Process Bot” projects. Be on the lookout on legoengineering.com for the final product!


As soon as we started the day, things seemed to be going well.  At last our code and Bluetooth had decided to cooperate for Station One, and the chocolate dispenser consistently lowered and applied pressure for the given amount of time.  We were elated with our immediate success, and then proceeded onto the next station: our old nemesis, the Whipped Creamer.

Station Two has a nasty habit of running forever and ever, regardless of the code we write or the commands we give it.  We’d tried restarting the code from scratch, changing the Bluetooth messaging method, and swapping out motors.  However, today will be different, we’re sure of it!  Our first idea was to display all messages and in use mailboxes to the screen of the NXT, to see exactly where the error originated.  Immediately something seemed strange; while the NXT in Station Two was supposed to receive two messages (one signaling the bowl-bot’s arrival and another containing the amount of whipped cream to dispense), only one was being recognized at the station.  Even after messing around with the code and swapping mailboxes, the first message was still the only one being transmitted.  Rather than working against Bluetooth and its mystifying properties, we decided it would be better to conform to its will, and only use one message.  This proved to be quite easy, but even after this simple change the improvement was remarkable.  The second station worked!

Lastly on the docket was the sprinkles/cherry station.  This station suffered from the same problems as Station Two; it tended to try and dispense sprinkles forever.  Luckily for us, we left the cap on for any and all tests, but something had to be done.  Having recently discovered the nature of Bluetooth messages and their tendency to ignore anything that wasn’t the first transmission, we immediately tried to condense all three of our messages (arrival, sprinkle shakes, cherries) into one message.  Using some simple multiplication code and division/remainder functions, we accomplished this quite easily.

At this point we just had to give ourselves high fives and fist bumps all around.

We had gone from an absolute quagmire of Bluetooth and unresponsive robots to a fully functioning system in a matter of hours.  We even tried running with condiments (but no ice cream) and it was entirely successful.  Without ice cream in the bowl, unfortunately, the sprinkles proved to be bouncier than anticipated, and we knew we were going to have a mess on our hands very soon.

Only one problem still reared its ugly head: the cherry dispenser.  After initial construction we believed the device to work well enough for final use, but now we see that we need improvements.  With any more than one cherry loaded, the paddles simply smash the queued cherries, getting juice everywhere and jamming up the system.  We need to rework the whole apparatus for a more useable and consistent approach.

Right now we are working on a hopper type of loader that opens up temporarily to allow cherries through.  We used a water bottle top and a plastic square to contain the cherries, and rotated the square in order to let out cherries.

The problem right now is that there isn’t enough force above the cherries to force them downwards through the aperture.  We are working right now to remodel, trying to combine the paddle idea and the rotating plate idea into a waterwheel type of dispenser.  Hopefully the idea will work!

3:27 PM:

Once again we’ve decided to change our game plan.  We think a conveyor belt + hopper might work the best, as long as the conveyor belt can somehow grab cherries out of the hopper.  We might have to use a glue gun and attach prongs of some sort along the belt.

4:51 PM:

After many failed attempts, we finally have a cherry dispenser design that we are sure will work.  It combines all the best elements of our previous ideas: 1) it holds many cherries so we don’t have to manually load them so often; 2) it dispenses only one at a time–consistently; and 3) it looks cool.

Basically it involves a vertical tube of cherries with a round knob at the bottom.  But the knob is shaped like pac-man–when the triangular cutout is facing up (aka, into the bottom of the tube) one cherry will fall into it.  As the knob continues to rotate, the cherry will be dumped into the sundae.  Yes.  We are extremely hopeful that tomorrow will bring sundaes!!

Day 10 Conclusions:

  • Bluetooth life is finally good! After many trials and tribulations, we’ve finally created what we hope is a foolproof code.
  • Cherries are an obscure item that requires a dispensing mechanism different than almost anything in existence.  However, many existing systems can be combined to make a great, customized dispenser.

To-Do for Day 11:

  • Finish cherry dispenser.
  • Make sundaes.
  • YES.

We started the day with a great leap of progress.  Right off the bat, we found the error in our chocolate squeezer program, and had it working in no time.  Unfortunately, the next two stations are still proving to be incredibly stubborn and completely bugging out on us.  More developments soon.

11:08 AM:

Good news and bad news.  The good news is that we’ve tracked down the problem.  The bad news is that the problem is nigh impossible to fix.  The NXT Bluetooth platform is actually a very bad system, constantly dropping signals or not sending/receiving messages.  Running the same program in the same situation multiple times may yield different results, simply because our Bluetooth messages might not get through.  This is the explanation for our strange, constantly running machines that worked just one trial earlier.

To add an extra element of confusion, the default value of Bluetooth mailboxes is -1.  So attempting to run a motor controlling the whipped cream for a time of -1 can result in some ridiculous sundaes.  It also makes it very difficult to control the number of sprinkle shakes, etc.  We need to find a way to ensure a message is sent and received each and every time if we want a consistent and reliable system.  How we do that, exactly, remains to be seen.

1:10 PM:

After brainstorming a few ideas, we’ve decided to try editing our bowl-bot code wherever a Bluetooth message is sent.  Since the bowl-bot always sends the message but it isn’t always received, we are going to try and make a loop that continuously sends the message until the client NXT confirms that it has gotten the number from the host.  It may be difficult to have this work smoothly with the rest of the project (waiting at each station for a message to be relayed, confirmed, then processed could get tiresome).

3:05 PM:

All attempts to make a well communicating system have thus far failed.  The client NXTs simply cannot reliably use Bluetooth.  No matter how cleverly we code the bowl-bot or the receiver bots, reliability is not an option.  However, we have one last ditch effort planned.  Instead of a clever loop system, or communication method, we simply plan on checking the message over and over through brute force.

No dice.  We are out of ideas here, but somehow we will create a solution.  If worse comes to worse, then we may have to switch back to a physical solution (sensors of some sort) instead of Bluetooth.  But we will stay the course for the time being.

All in all, today was a very disappointing and frustrating day.  Almost no progress was made, and we are no closer to solving our problem than we were yesterday (although we certainly have eliminated many possible solutions!).  With any luck we can get it to work soon, if not we may have to abandon the Bluetooth ship and try something else.

4:54 pm

We’ve managed to recover to about where we were this morning, with a new Choco-Station program that will hopefully work consistently (unlike this morning’s program.)  Here is our new program:

One of our problems ended up being Connection 1, which is aggrevating since it is irrelevant to anything we were doing.  By switching to Connection 2, we managed to get things working.  Who knows if Connection 1 will be useable ever again.  Hopefully, since we need all three!

On a good note, somewhere around lunchtime we got the song to run while bowl-bot drove along the course.  All in all, a frustrating day but some good stuff happening.

Day 9 Conclusions:

  • -2 Days in a row of little progress is very frustrating.
  • -However, we are slowly revamping everything so that it will eventually work.  In the long run, things should come together.

To Do for tomorrow:

  • pray

Starting off day 8 with some touch up coding, especially on Station 3 (sprinkles and cherries).  After this will come putting all the code together in a nice format and adding the customization through the front panel of the bowl-bot program.


We now have a nice, user friendly interface!

A screenshot of our LabVIEW 2010 Front Panel Interface

As you can see, this allows the sundae maker to specify how much of each topping they want on their sundae.  Next we have to alter the programs to make them actually react to these numbers.  We are going to do this through more Bluetooth wireless communication.  Basically, the interface is on the Bowl-Bot program, so we can take the numbers entered and send them via Bluetooth to the station that needs to know.  So the chocolate level will be sent to the Choco-Squeezer Station.  We are performing some basic math on the levels to make them correspond with the correct amount of time for each task.  We’ve noticed whipped cream comes out much faster than chocolate syrup—so the chocolate level gets multiplied by 2 while the whipped cream level gets multiplied by 0.3.


After some promising initial progress, we’ve hit some significant technical difficulties.  Something is not right in the receiving of the user-input messages.  To try and isolate the problem, we’ve begun writing some test programs that involve a similar process (one NXT sends a message to 3 other NXTs, with varying actions that depend on receiving the message.)  Unfortunately, the Bluetooth is no longer cooperating.  We finally thought we’d nailed the process of connecting computer to NXT (hint: you have to connect it in about 4 different places.  It’s rough.) but now the computer seems to be rejecting the connection.  We have no idea why.


We’ve come to the conclusion that the Bluetooth-BowlBot connection was interfering with the Bluetooth NXT-NXT connections.  While it pains us greatly, we think the program will have to be downloaded onto the BowlBot using a cord, not wirelessly.  Our workroom is just not conditioned correctly for so many different wireless signals.

On the bright side, when we download the program onto BowlBot using the USB cord, the first part of the program works perfectly!  The Choco-Squeezer portion of the system is working well—it alters the amount of syrup dispensed based on the user input.  Progress feels good!  Unfortunately, the Whipped Cream-O-Rama and the Sprinkle-Mania both still run on infinite loop.  It would be perfect if we were making a table-long sundae…


No change in the whipped creamer’s behavior.  Despite many, many changes in the program, we haven’t figured out why it keeps spazzing.  Ending the day on a slightly discouraging note, but hopefully we will have better luck figuring it out tomorrow.

Google Searches:

  • types of mountains
  • Whoa
  • Whoah (clearly had to settle a debate…)
  • A lot of boring ones involving some combination of “nxt,” “bluetooth,” “not working” etc

Day 8 Conclusions:

  • You can’t do EVERYTHING with bluetooth.  These guys get confused after a while.
  • Work on a bunch of little robots completing tasks and you’ll start to treat them like children.  Ours were seriously misbehaving today.  We even turned a few of them off for a while.
  • Not all days are exciting days.  Some just need a lot of perseverance and thought.
  • This part of the project is definitely the hardest part.  Toppings and ice cream may still be a few days away.

To Do for Day 9:

  • Figure out why the whipped cream tower and sprinkler are going infinitely.
  • Change that.
  • Hopefully get everything working all together.

Bluetooth; any NXT programmer’s bane.  In order to get the simple yet somehow frustrating mechanic to function properly, one simply needs to connect two NXT bricks, enter a passcode on them both, then connect.  Easy, right? Not so much.

Here are the problems we’ve encountered so far:

  • You should be able to connect 3 NXTs at once to a 4th.  However, upon connecting the second NXT, the first’s connection is overwritten.
  • There is not explicit way for connected bricks to communicate in the same program.  Instead, using different programs, the main NXT needs to send a “letter” of sorts, which the other NXT will read and react to.  As of yet, our attempts to receive letters have been unsuccessful.
  • Each NXT has 4 output channels (0-3) but only 3 input channels (1-3).  It boggles the mind.

Fun fact: the NXT Bluetooth search “loading bar” is actually just more and more question marks.  The irony inherent in this feature is almost too much to bear.

Sweet sweet progress????

After much painstaking searching and connecting, we have finally discovered the secret to connecting multiple NXTs.  Instead of using one brick as a hub for the others to connect to, instead we need to send out separate connections using our bowl-bot.  This way, the strange overwriting bug can’t happen.

Getting the Bluetooth NXTs to talk to one another is proving more and more difficult.  In an effort to track down the problem, we had each NXT display the value of the “mail” sent to it by the bowl-bot, and instead of the expected value of 7 we had the mysterious value of -1, which we can only assume is the default value of Bluetooth mailboxes.

As another update, we finally managed to coerce the stations into reacting to the bowl-bot.  For a while we couldn’t send the mail, but at last they work together.  Our only problem now is a pretty big one; upon arriving at the third station, the last NXT brick freezes up completely and won’t respond to button presses, and needs to have its battery unplugged in order to restart.  Hooray.

Sometime later…

Still no luck with the third station.  We attempted to switch NXT bricks but to no avail, so the problem must be somewhere in the code or with the Bluetooth.  Our guess is it’s in the code.  Since the only difference between this program and the other (working) ones is the use of a couple “for” loops, we think it’s possible that’s where the problem lies. We’re going to try replacing them with “while” loops.

At last, success!  The “for” loops were indeed the culprits, and after replacing them with while loops the programs ran successfully.  All that needs to be done for the third station is a small delay so the bowl-bot can pull under the cherry dispenser, and we should be ready for testing.

Conclusions for Day 7:

  • Bluetooth is very frustrating to set up, but once working it isn’t too much of a problem.
  • Bluetooth + For loops = Crashes, crashes everywhere.
  • Running 4 NXTs at once chews through batteries.

Goals for Day 8:

  • Finish coding for the stations, and do a few more test runs.
  • Adjust bowl-bot; doesn’t quite fit through station 2 at the moment.
  • Make a sundae!  Sans ice cream, unfortunately.

Today is an exciting step in our project; now that all of our condiment towers have been created, all that remains is to make a bowl-bot to carry the ice cream.  The interaction between the bowl-bot and each of the towers is a little bit complicated: not only does the bowl have to “know” when it reaches a station, but the stations each have to “know” when to perform their task.  After a few design iterations, we settled on using an ultrasonic sensor on the bowl-bot to sense the towers.

The first Bowl-Bot

We also decided it would be best to use ultrasonic sensors on the towers.  This eliminates user input (the possibility of the user telling the system exactly how much of each topping should be on the sundae), but makes the whole system a lot more repeatable and reliable.  Everyone is simply going to have to eat the same sundae toppings!  Our “runway,” so to speak, is all of the stations in a straight line.

Possible Station Locations.

We are using a light sensor and a line made from tape to ensure the bowl-bot stays on the correct path and does not veer off away from or into any stations.  As of right now the course is straight, so the line following serves only to ensure a straight path (NXT motors are wont to not run at uniform speeds).  It looks something like this:

Line following Bowl-Bot

The whole setup

The paper is to prevent the translucent table from messing with the light sensor.  Right now we are writing our own program for the line following that will make it run smoothly.

20 min later….

Got it!  The Bowl-Bot follows lines brilliantly.

3:50 pm

After many trials, we’ve discarded the ultrasonic sensor on the bowl-bot.  It had too many issues with sensing a precise enough distance, especially when interacting with another active ultrasonic sensor.  We have replaced it with a light sensor, and have put black tape lines along the track that tell the bot where to stop.  This is much more effective and worked exactly as we wanted on the very first try.  The following video shows a trial of the bowl-bot finding the guide line and then parking under the chocolate syrup tower.

Movie on 2011-06-21 at 16.02

4:45 pm

While things are going well for the bowl-bot, the tower response is not looking so great.  We are running into problems using the “Wait for Ultrasonic” icon—it doesn’t seem to work the way we thought it would, or the sensor is having a lot of trouble finding the bowl-bot.   Either, way, we have to find a new way of communication for all of our different components.

At this point, we are wondering if it would be easier to connect all of the NXTs via Bluetooth.  Neither of us have much (read: any) experience in manipulating multiple NXTs via Bluetooth, so much of tomorrow will probably be dedicated to playing around with it and trying to establish simple communication back and forth.  It’s funny—we originally thought that the ultrasonic sensors would be the easier route, so we were willing to use them at the expense of some nice customization features we really wanted.  We will see in the next few days, but it seems like the easy way and the way to get everything we originally wanted working may, in fact, be one and the same.

Day 6 Google Searches:

  • Bluetooth NXT Labview establish connection
  • NXT Bluetooth mac
  • Ice cream truck music (we also spent a few minutes using the NXT Piano Player application….our bowl-bot will eventually play the ice-cream man song.)
  • Do your ears hang low sheet music

Day 6 Conclusions:

  • Don’t always be so quick to give up cool parts of your project—try and find an easier way to get what you want
  • Don’t be afraid to jump into using a program or technology you’ve never used before; it may just fix all your problems (or not… we will see tomorrow….)
  • Light sensors are wayyyy better than ultrasonic sensors.

To Do for Day 7:

  • Figure out Bluetooth control
  • Figure out how to program those NXTs involved in the Bluetooth connection using Labview—we eventually want to be able to control one NXT with another, remotely.
  • Coding, coding, and more coding.

Day 5 begins with a structural dilemma.  Well, not really a dilemma, we just have a lot of building to do.  We begin by building upwards behind the whipped cream canister holder.  We also add a weight in the back, since we know we will somehow have to balance out the extreme heaviness of a full can of whipped cream.

Next, the other holding ring is attached.  This will ensure the canister stays upright and doesn’t move around when its nozzle is pressed.

When the canister is loaded, the whole structure still falls over.  More scaffolding is added…. so it holds a full canister of whipped cream, just barely.  As you can see below, we also moved the weight to table level—it is more effective there because it brings the center of mass of the structure down, closer to table level.  This means that it takes a much heavier can of whipped cream to tip the structure over.

Not so sturdy...

The structure is still bending though, so something has to change.  We are thinking of building more up the back, and then using rubber bands to pull the tallest part back to the square position.

Much better.

That idea seems to be working fantastically.  It looks a little…..less than perfect, but it is definitely more square.  The rubber band can also be switched out for a stronger or weaker one based on the amount of whipped cream left in the can.  We also added some rubber grip material onto the arm that presses the whipped cream nozzle, to prevent slippage.

1 hr later…

We’ve figured out, after another series of disappointments, that the last problem lies with the strength of the NXT motor.  Even at full strength, there simply isn’t enough power to make the nozzle bend sufficiently, dispensing the whipped cream.  This means we will have to add another motor to the same axle and use them both simultaneously, to simulate a stronger motor.

Two motors are better than one.

Great news; the dispenser finally dispenses!  After the addition of another NXT motor, we finally created a system that could push the whipped cream nozzle with enough force.  The only remaining problem is that the second motor tends to be ripped out of the structure by its own strength.

20 min later…

Not to worry, we’ve now attached it more securely.  Unfortunately, the can still wiggles 🙁


But with a small adjustment….

Note the extra beam between the can and the edge of the contraption.



Here is the code we used to test out our whipped cream dispenser:

Day 5 Conclusions:

  • LEGO motors are still not known for their power.  Surprise!
  • Sometimes integrating non-LEGO material into a LEGO project can do great things (rubber bands, grippy stuff…)
  • Likewise, the NXT LEGOs are not always exactly what you need.  Sometimes the more traditional bricks can help you out.
  • In design projects, a small change can really help you out.  When your project doesn’t do quite what you want it to, you don’t always have to tear it down and reconstruct–try adding or changing one small detail.

To Do for Day 6:

  • Begin the combination process: line everything up and make some decisions about how this thing will work.
  • Bowl-Bot!

Day four of our project begins, and with it the new challenge of the cherry dispensing mechanism.  Our first idea and attempt is going to be a sort of “rack” of cherries with dowels through them.  The dowels will be resting on two angled tracks, and a four-toothed gear attached to the motor will rotate to allow one cherry through at a time.

Prepare yourselves for a magnificent display of artistic prowess:

Our rough sketch of the idea.

This design doesn’t seem too hard to accomplish, but some potential problems are already apparent:

  • As of right now, we have nothing to guarantee that the cherries will roll straight down the rack.  They could possibly roll off to the side, though the size of the cherry should stop that.
  • The size of the cherry might not be enough to separate the dowels individually.
  • The rack may be intruding on the sprinkler shaker’s area.

We also did some work to stabilize the entire structure, since the very large weight of the sprinkler canister coupled with its height above the table made for an unstable system (see video from day 3!).  Although we used a lot more pieces, it definitely seems more stable.  Surprisingly, the cherry rack didn’t interfere with the sprinkles dispenser.

At first, the cherry rack seemed unusable because the cherry dowels wouldn’t fit.  However, after a few slight adjustments we positioned the rack so that the dowels can be held in place and rotated through by the gear.  Already we can see the main problem; when the dowel comes to rest on the gear, the other side continues down the rack and the whole dowel falls off.  We may have to use another form of support to maintain a straight alignment.

Construction with four tooth gear.

After many different attempts at keeping the cherry dowel aligned, we concluded that we needed a different approach.  The unbalanced nature of our four tooth gear simply couldn’t keep the dowels straight.  We are replacing the gear with an impromptu paddle mechanism that should swipe one cherry through at a time.

Our dispenser immediately before addition of paddles.

1:26 PM

Unfortunately, our paddle mechanism is just barely too long for one cherry, which results in it coming down on the next cherry and smashing it.  We’re going to make a couple adjustments and then go for it.

1:35 PM

Success! The cherry dispensing machine works well, contrary to our initial beliefs.  Here is the video of the machine in action:

Movie on 2011-06-16 at 13.45

Sometimes the paddle gets stuck on two, but as of now the biggest problem we have with the dispenser is the fact that Maraschino cherry juice gets all over everything.  We’ll most likely end up using plastic wrap to protect the rest of our structure.

Right now we’ve started the whipped cream dispenser, the last of our structures for condiments.  The whipped cream canister is the heaviest of all toppings, but luckily we don’t need to move it around, only hold it still while we apply pressure to the nozzle.  Unfortunately, as the chocolate sauce dispenser has proven, applying controlled pressure with these motors is quite difficult.  Our two options are:

  • Hold the canister still while we push on the nozzle
  • Put a loop of some sort around the nozzle, and pull when we want to dispense

Just to keep a little variety in our constructions, we decided to choose a pulling device instead of a pushing device.  That design seems like it would work better as well.

3:00 PM

Construction on the whipped cream tower is going well, but the whipped cream container is going to have to be very high above the ground, which could cause problems.  In addition, the container has to be very far out from the base.  Hopefully we’ll be able to work around the limitations.

Initial construction of the whipped cream structure.

4:00 PM

After contemplating a “garage” approach to the structure, we remodeled and put heavy support on the back of the structure so we could reach it out over the table.  The large mass of the whipped cream can might cause a lot of tension on the structure and break it apart.

Day 4 Google searches:

  • structures holding up heavy loads

Day 4 Conclusions:

Maraschino cherries are quite messy, but easily dispensed via lego motors.  Even though we can only put two or three cherries on our machine, it works quite well and can be controlled pretty easily with sensors.  Also, a whipped cream canister is extremely heavy, and very difficult to hold up with a Mindstorms kit.  Additionally, we cannot allocate a smaller amount of whipped cream to a different container, like we could with the chocolate syrup or cherries.

To Do for Day 5:

  • stabilize the whipped cream structure
  • create a nozzle push/pull device
  • brainstorm for the car/sundae carrier

Day 3 brings trouble on the horizon.  The rack and pinion system for the “squeezer” is not working as planned, and it looks like a great disassemble and redesign is in order.  Preliminary testing does not look good: we think we’d better put syrup in it and really test it out to make sure we know exactly what isn’t working.

Testing Squeezer v 1.0

As you can see, some chocolate sauce does come out.  However, it’s not very much and the gears slide along the rack instead of pressing securely against the bottle.  Conclusion: The LEGO gears sadly are not made to transfer power—the linear motion squeezer didn’t have enough force to actually squeeze the chocolate syrup out of the bottle.

Next step: Disassembling and going back to an upgrade of the original plan: attaching angled pieces onto axles going directly into the motors.  This not only conserves pieces, but also doesn’t use any gearing and is much simpler.

Iteration #2....

This one didn’t really do its job… It’s not squeezing….

So we made some alterations.  Unfortunately, this resulted in a terrifying moment: Things fall apart…..

Finally: 1:25 pm

After many rebuilds, we finally have a working “Choco-Squeezer!”

A close up of the final product

It works!

Here is a photo of the code we wrote for the Choco-Squeezer in LabVIEW 2010 for LEGO Mindstorms:

It is fairly straightforward, and mostly based on the time it takes to complete each movement.  The initialization of the process and the squeezing motion are both started by a touch sensor (the pressing of a button).  If you are looking for some help learning how to use LabVIEW 2010 for LEGO Mindstorms, check out this great collection of examples we pulled together last week: http://legoengineering.com/library/cat_view/28-code/164-labview-for-lego-mindstorms.html .

Next up: Creating the Sprinkle Station

While brainstorming ideas for the sprinkle station, we thought it would be a good idea to combine it with the cherry station, since they are a similar dumping motion.  It would not be difficult to put them both on one station–one NXT, one tower/base…it just seems like a good plan.


This was our initial plan:

After building one side, it became clear to us that the design was not sturdy enough to support the motor and the heavy sprinkle container in the position we wanted it.  We changed tactics and are now implementing a similar design as the first part of the Choco-Squeeze.

4:04 pm

The primitive sprinkler prototype is complete! The structure is pretty shakey, but once we add the cherry mechanism on the other side we will support the whole thing.

Sprinkler v1.0

Day 3 Google Searches:

  • Robots ice cream (I forget what we were looking for, but this came up:  http://www.robotsandicecream.com/… whaat?)

Day 3 Conclusions:

  • LEGO motors are pretty weak.  LEGO gears are even weaker.
  • Most of the time, your first instinct about a design is spot-on, even if it seems “too simple.”  Better simple and functioning than overly complicated.
  • Don’t do something new just for the sake of doing something new.  For our sprinkler, we originally wanted to do something different (aka orienting the motors perpendicular to the way they are in the Choco-Squeezer).  Turns out, the reason the Choco-Squeezer works is because that design really is the best.  Don’t fix something that ain’t broke!
  • Like sprinkles?  We hope so.

To Do for Day 4:

  • construct cherry dropping mechanism
  • stabilize structure
  • code, test structure
  • perfect it
  • begin thinking about whipped cream-er

Today our focus is the device that will apply chocolate syrup to the sundae.  Before we began building, however, we brainstormed the overall design of the project a little further.

A collective decision has been made to move the sundae around to each station with another robot (a “Bowl-Bot”).

Sundae Movement

  • Make a separate robot/car to carry bowl
  • Sturdy, well fitted (inverted pyramid)
  • Some sort of sensor system to stop at each station
  • Car moves back and forth at syrup/whipped cream – drizzle effect?

This should make for easier transport and more accurate stops at each station.

Back to the hot fudge tower:

One immediate problem that arose was that the chocolate syrup bottle is much too large, and most likely unable to be supported by the NXT kit.  We will have to find a smaller squeeze bottle to hold a smaller amount of syrup if we want to succeed.

1 hour later…

After a trip to the store, we now have a perfect squeezable bottle for the syrup, a sprinkler shaker, and tiny dowels for the cherries.  All that’s left for the assembly line is the whipped cream canister, which can wait for now.

Luckily, the bottle has an opening just wide enough for syrup. It seems all we will need to do is tilt the bottle downwards and apply a small amount of pressure with the two other motors.  This is great news, because while the motors certainly are capable of putting out a lot of force, this will allow us to be more exact.

1:35 PM

Construction is coming along fine.  Motor positioning is complete, and the syrup bottle has a holding cage as well.  No major roadblocks so far.

"Squeezer Bot" construction update

2:05 PM

Making the squeezing mechanism will be more difficult than we first expected, but with a few gears and racks, we have a clear end result in mind.  The only question is whether it will hold up in the end!

inspiration for the squeezing mechanism

2:50 PM

Still working on the gears and squeezing.  Turning out better than we expected, however.

Iteration 1 of Gearing

3:40 PM

The unsteadiness of the structure has forced us to construct many trusses and supports in order to have a clean gear meshing.  This also means that our ice cream movement design will need to pull in to each station, as opposed to running through all of them.  Not a huge deal, however.  Construction continues!

Iteration 2 of Gearing

4:36 PM

Nearing the completion of the chocolate syrup pouring apparatus.

Day 2 Google Searches:

  • Michael’s 02155 (searching for a Michael’s so we could purchase a more appropriate bottle)
  • Linear motion gear

Day 2 Conclusions:

  • Using SO MANY pieces, but it really can’t be avoided.
  • We have learned a lot about the LEGO gears and exactly how much support they need (read: a lot.)  They are not super sturdy or powerful.   We’ll see how big a problem this is later.
  • After almost a complete deconstruct and rebuild process and about two or three other iterations, we’ve got a design that (hopefully!) will work.  The tricky part will be making sure we get the motor speed and other programming exactly right in order to actually squeeze out the chocolate.

To Do for Day 3:

  • Test the choco-squeezer
  • Fix it
  • Test it again
  • Fix it again
  • Fill it with chocolate syrup
  • Test it again.
  • Repeat.