TurtleBot Hydro ISO Alpha 2

Progress continues.

http://data.iheartengineering.com/turtlebot-hydro-ubuntu-12.04.2-alpha2.iso

ROS Hydro Released + TurtleBot Hydro ISO Alpha

ROS Hydro Medusa has been release and we are close behind with an alpha release of the TurtleBot Hydro ISO Installer and we are hoping for a beta early next week.

http://data.iheartengineering.com/turtlebot-hydro-ubuntu-12.04.2-alpha1.iso

UPDATE: Problem with DNS propagation

adding this to your /etc/hosts should work for now

66.228.47.240 data.iheartengineering.com

Turtlebot Wanderer

The Wanderer program allows the turtlebot to move around randomly while avoiding any nearby objects.  Using the attached Xbox Kinect, the robot reads its laserscan messages and determines if there are any obstacles closer than 0.6 meters.  If there are none, it moves forward.  If it does detect any obstacles, it rotates away from them and then continues moving forward.

Turtlebot2 used with Wanderer to carry around drinks

Scan_msg class

Much of this program depends on a class called Scan_msg.  At it's initialization, a Scan_msg object creates a publisher, pub, for twist messages, variable msg to hold the twist message, variables sect_1, sect_2, and sect_3, and 3 dictionaries - ang, fwd, and dbgmsg- to hold the angular speed, linear speed, and debug message for each possible instance, respectively.
Variables sect_1, sect_2, and sect_3 each represent a specific part of the field of view of the turtlebot (see image below). 

 

Illustration of turtlebot field of view

 

The two main functions of this class are sort() and movement(). 

sort() takes in a laserscan message and goes through all the ranges read by the robot.  If any of the ranges is less than 0.6 m (an obstacle is detected), it determines which section of the field of view (sect_1, sect_2, or sect_3) the obstacle is located in and changes the value of that  section to 1.   
 
movement()  takes in the values of sect_1, sect_2, and sect_3 and uses them to determine how to move.  To do this, it creates a number with the values of these 3 variables and assigns that number to the  variable sect.  sect is then used with the class dictionaries to change the angular and linear velocities  of msg to the proper values and display the correct debug message.  Finally, movement() published this modified twist message (see code below).

sect = int(str(self.sect_1) + str(self.sect_2) + str(self.sect_3))
self.msg.angular.z = self.ang[sect]
self.msg.linear.x = self.fwd[sect]
rospy.loginfo(self.dbgmsg[sect])
self.pub.publish(self.msg)  

Finally, the reset_sect() function is run to reset the values of sect_1, sect_2, and sect_3 to 0.   

The function for_callback() takes in a laserscan message and runs both of the above functions. 

listener() and call_back functions
The listener() function first initializes the node navigation_sensors, and then creates a subscriber with callback function call_back().  call_back() takes a Scan_msg object and passes the laserscan message to the class function for_callback(). 

Overview 
At the start of this program, a Scan_msg object called sub_obj is created.  listener() is then run, starting the subscriber, which passes a laserscan message to the call_back() function.  call_back() passes the laserscan message to sub_obj's for_callback() function.  for_callback() first runs sort(), which updates variables sect_1, sect_2, and sect_3 accordingly, then passes these updated variables to movement() which uses them to determine where to go, updates the class twist message, and publishes that message.  This process repeats for each laserscan message. 

App Chooser
Wanderer was also added as an additional feature to  App Chooser (for android).  In order to do this, I wrote files wanderer.launch, wanderer.interface, and wanderer.app and added a wanderer_icon.jpeg (for the icon) in a folder called wanderer_app.  The interface file lists any publishers and subscribers.  In the wanderer app, there were none.  The launch file defines a single node, "navigation_sensors" from the wanderer.py program (see below).
<launch>
   <node name="navigation_sensors" pkg ="navigation_sensors" type="wanderer.py" cwd="node"/></launch>  

Lastly, the app file defines a few attributes of the app and also gives the package/name of the other files and image.  In order to add this app to App Chooser, I edited the file turtlebot_apps.installed to include the wanderer app.

 Wanderer appears on the far right along with the other apps in App Chooser

All source code available at: 
https://github.com/IHeartEngineering/ihe_turtlebot_wander

ROS Hydro Beta and T-Shirts

Now returning to our regularly scheduled programming.

ROS Hydro Beta 1 is now ready for testing. We also expect to have an ISO for the TurtleBot ready by the end of August.

Limited edition ROS Hydro T-Shirts are also available.

Hvernig segir maður robot á íslensku?

TurtleBot tala í Reykjavík.

Robotbespreking in Amsterdam

Woensdag 22 mei geef ik een korte lezing over Open Source robotica en zal ik onze Turtlebot demonstreren. 

Roboter erzählen und demonstrieren in Berlin

Datengarten: 16. Mai, 20 Uhr.

European Demo Month

May is European demo month!

I Heart Engineering will be at ROSCon in Stuttgart, Germany on May
11th and 12th. Any organizations located in Benelux, Germany, or the Czech Republic and
interested in a demo of the TurtleBot 2 during the month of May should email
sales@iheartengineering.

We are especially interested in presenting to Hackerspaces and commercial or academic robotics labs.

Free Robot App from IEEE Robotics and Automation Society

While iPad owners have not been able to run many of the latest robot apps, the IEEE Robotics and Automation Society is sponsoring free downloads of the IEEE Robot App during National Robotics Week.

This app has specifications, videos and photos of over 100 robots and is a great reference.

National Robotics Week 2013

It's that time of the year again, from April 6-14 we will be celebrating National Robotics Week. If you want to meet up, this year we will be at this event in NYC on Tuesday April 9

---

Honeybee Robotics, Huge, and the NYC Economic Development Corporation are organizing a National Robotics Week meetup here in New York on April 9.

Researchers, developers and enthusiasts are gathering for an evening of presentations, live demonstrations and inspired discussion. The theme: New Frontiers in Robotics: Extending the possible. It's a chance to learn about -- and see firsthand -- how machines built and used in New York City are transcending simple automation, instead enhancing new capabilities and enabling discoveries.

What: Presentations and demonstrations of leading robotics R&D from New York City
Where: HUGE, Inc -- 45 Main St, Suite 220, Brooklyn
When: Tuesday, April 9, 7-10pm
Why: To learn, to share, to show off some cool homegrown robots

The program is listed at http://nycroboticsweek.com/. RSVP required.

RFID Door - 1 of n

Often times an office finds the struggle of granting access to rooms without jeopardizing physical copies of keys. These struggles can be easily overcome with technologies such as facial recognition, finger print recognition, bar codes, radio frequency identification, and much more.
Here at I Heart Engineering, we felt the need to have awesome badges fit our daily attire, where we can have both style and access to our offices without the need of weighty keys by building a robot door.

Using the Arduino Ethernet along with Adafruit's PN-532 RFID/NFC Breakout Board, the badges were a mere grasp away from reality.

A circuit involving a relay powering 12vDC@1A to a RCI S65 electromagnetic door lock. The circuit was mounted onto an Arduino Protoboard alongside a circuit connecting the PN-532 breakout board to the Arduino.

Part	Price
Arduino POE Ethernet	$69.95
Adafruit PN-532 Breakout Board	$39.95
Arduino Proto Shield	$4.95
RCI S65 Electric Strike	$107.00
100~240VAC => 12vDC@1A Power Supply	$11.77
Tyco Electronics SPST Power Relay	$2.21
Total	$235.83*

*For single components, not including tax, shipping and handling, or packaged components

After the circuit above was tested on a breadboard, it was then put onto a protoboard and the Arduino set was completed. The speaker and variable resistor were used for key tones, hooked up to pin 7. This is not necessary, but it helps when debugging.

Left: Arduino Ethernet   Middle: Protoboard w/ circuit   Right: PN-532 Breakout Board

Bottom-side of the protoboard and the PN-532 breakout board

Put together into a neat package, ready for mounting

Now that the Arduino package is assembled, mounting of the rfid reader takes place. Using some masking tape and wire, a rough mounting test was enacted.

Test of mounting positions within the wall

A square was cut out into the door frame, and the RCI S65 was installed into the door frame, then hooked up to the Arduino protoboard.

Held into the aluminum with a series of screws, the lock became a neat addition to the door frame

Now we can print out our badges, put on an RFID tag, and program the UID and data into the Arduino.

Laminated identification card

Future plans include:

• Ethernet support, adding a control panel.
• Logging of cards (usage, amount of usage, etc)
• Time frames
• Proper mounting plate
• Genuine People Personality

Arduino code is available on the Github Repository. Stay tuned for more features.

Open Manufacturing: Laser Cut Packaging Solutions

I don't believe anyone can argue against the merits of attractive and functional packaging on a product.  Sometimes, the way a box looks may even be enough to persuade a potential customer.  There are thousands, maybe millions of unboxing videos posted to Youtube. Great packaging delivers its contents safely and gives its consumer a reason to smile.  But, we aren't here to discuss the merits of aesthetically pleasing packaging.  This is a post about building packaging that protects the integrity of the product being shipped and how to prototype that on your laser cutter.

At I Heart Engineering, there have been a few cases in which a TurtleBot 2 was damaged during shipping.  One problem is that we currently do not manufacture our own boxes.  However, what we can do is come up with our own structural packaging solutions to protect our products working within the constraints of "stock" boxes acquired from elsewhere.  The first effort was directed at protecting the Kobuki base of the TurtleBot 2 during shipping.  Currently, the shipping department modifies the already existing Kobuki packaging to fit inside of a commonly available box and uses foam inserts to protect the plates. Our question now, is how to create support for the Kobuki base using our digital manufacturing tools, or if you prefer, the Epilog Helix Laser.

First, we need to understand the process of creating a "box."  Well, the unfolded form of packaging is referred to as a net.  This closely resembles the term flat-pattern which is used in sheet metal work.  Some techniques used by sheet metal workers can be applied when making your net out of certain materials.  In our case, we are limited to the use of 24" x 18" C-Flute Corrugated Cardboard which provided a few interesting issues.  Before you begin to CAD your net or flat-pattern, you should create a scale model of what you intend to build out of card stock. I recommend reading Paul Jackson's Structural Packaging Design Your Own Boxes and 3-D Forms for a full understanding of that process. The end results produce something similar to the picture below.

At this point, it is now okay to create your net in a CAD program of your choosing.  I should note that there is software available designed for this specific purpose, but it is not Open Source nor does it seem to be made for work with laser cutters and is geared toward industrial designers.  Parametric CAD suites like Solid Works and Creo [Pro/E] meet our needs in addition to tools such as Inkscape, GIMP, and Corel Draw.

Folding is key, how the material folds and the method of folding make all the difference in the actual design of your net. There are sheetmetal formulas for calculating the proper lengths of your folds legs.  However, in the case of cardboard and a laser cutter as a tool, things don't quite work exactly the same by our experiments.  Sheetmetal work has a principle of the neutral axis, that is, the axis between the tangent points of  a bend that is neither compressed nor stretched. In those formulas, this neutral axis is represented in what's called the K-Factor and Y-Factor [used in CAD software usually multiplying the K-Factor by number.] For this cardboard, the K-Factor is effectively 0 as all of the material compresses or stretches when bent at a 90deg angle.  This means that bend radius on the inside and outside of the bend are very close to 0 for all intents and purposes, but you still have to account for the material thickness when designing the actual folds in the net.  In other words, it is a good idea to offset some of your fold lines by some of the material's thickness to get a better fit.  I also recommend that you shorten the lengths of your tabs to avoid fold interference and using corner reliefs everywhere applicable.

In terms of cutting the net and fold lines, Vector cutting the entire net is your best option for rapid and mass production.  Using the raster feature to whittle away at the fold line would consume far too much time to make it useful in production.  Also, because the cardboard is corrugated, it doesn't provide any actual advantage at all in this situation.  There was no point in trying to vector the fold lines on low power to mimic a raster for that reason.  Instead, I opted to test various methods of vectoring the fold lines from replicating the SNIJ Hinge to dashed lines of various lengths.  I found that for our purposes a series of dashed lines similar to perforation were most effective in getting the cardboard to fold in a suitable manner for our purposes.

After many iterations, a version was made that is sufficient for packaging our TurtleBot more safely than it was before.  I will continue to iterate on it's design to make it even more effective, but this version was found to be sufficient.  Also, it would be greatly appreciated if anyone knows where we can purchase E-Flute corrugated cardboard in 24" x 18" sheets.  I have reasons to believe that it may be the most suitable size for this operation.

Here is a link to the net posted on Thingiverse: http://www.thingiverse.com/thing:64220

Open Manufacturing: A Home for the Beagle Bone Part 2

The 80/20 rule supposes that 80% of your results comes from 20% of the work you did. It has further been argued that the last 20% of a project is the most difficult and important. One can understand how these two ideas tie together and they indeed have some sort of merit. Those last few stages in preparing to bring a product to market/project to close are critical because the details are important. The last post ended with the Beagle Bone Case being at the 80% stage. The design language and major features have been settled. Now is the time to take the case and sort out imperfections, adjustments for changes in new/changed constraints, cost effective production and so forth. Basically, the iteration and revision of a design in the stages prior to being salable.

In this case, additional feature requests were made that changed core parts of the design. Room needed to be added to accommodate an additional shield or board, as well as any wiring. This resulted in the case being expanded 10mm on the sides and increasing the height by 18mm. Time was also taken at this stage to refine existing features. The SD Card port was enlarged for easier access and the press-fit to close system improved alongside adding Greebling to the case top. This version of the Beagle Bone Case was then 3D Printed.


Unfortunately, there is a problem with the case as designed; it takes over 5hrs 30min to complete in addition to suffering from curling due to its new size. Internally, a design that takes longer than 180-225min to 3D print is no longer affordable to offer as a product. The time removes full 3D printing as an option for manufacturing after including the cost of running the 3D Printer and man power.

Highlighting the curling on the edges. 

MDF as Case Top in Composite Test

Perhaps the design could be reworked, turning the case into a composite of materials? Doing that would reduce the print time, lowering the plastic used. So, I removed the roof of the case and instead opted to laser cut a top that would glue into place. The idea here being that the roof layers generated by Skeinforge take much longer to complete than the layers for the walls themselves. But while the print time was reduced, it was not reduced enough to justify offering the case as a salable product. That is not to say the Beagle Bone Case would be a poor product, it is just outside our current manufacturing capabilities to offer it as a product made and sold by I Heart Engineering.

Engineering asks that problems not only be solved by building something, but building it in a manner that is practically useful to all involved parties. This lead to the decision that the final version of the 3D Printed Case can still be offered to the community via Thingiverse to do with as they please and a new method of housing the Beagle Bone on the TurtleBot must be created. Another alternative would be to outsource the handling of the 3D Printing to a partner like Shapeways or travelling down the road of injection molding with services like Protomold. The injection molding route may yield the best results, but it comes with it's own requirements so the case will enter another lengthy design phase. In both situations, crowd sourcing initial interest would be the smartest way to judge whether its a worthwhile endeavor.

To reach this point, over 6 versions of the Beagle Bone Case were created, not including any of the test parts used. The project spanned 10 regular working days. More than 24 hours of actual 3D Printing Time were logged.

Overview of various case part iterations

Where the Project is Now

Testing Inserts Effect on Acrylic

Although the Full 3D Printed Case as a salable product was not achieved, the product idea itself does not die. The plan now is to scale back the design and focus of the simplicity of the intended function. We need a way to mount the Beagle Bone to the TurtleBot. The simplest and most effective way to achieve this is to create an adapter for the Beagle Bone to the TurtleBot. This can be achieved with a formed plate containing mounting points for the Board and TurtleBot. While not as consumer market friendly as the full case, it serves the core functionality, is within our current manufacturing ability, and is useful to our current and future customers.

Fortunately, we already have all the necessary dimensions and constraints on hand due to earlier work. Because this makes creating the adapter a much faster process, there was a realization that we can make this adapter plate universal between several development boards at once. What started as an idea to build cases for boards that had universal mounting points, is now a simple adapter plate that works with the Beagle Bone, Raspberry Pi, and Arduino suite of Boards.

The adapter is made of 1/4" thick Acrylic featuring 16 Brass Heated Inserts for 4 different hole patterns that comfortably accommodates the Beagle Bone, Raspberry Pi, and Arduino suite of Boards. It comes ready with Board Adapter Plate, (4) M3 1/4" spacers, (2) M2.5 1/4" spacers, (6) 10mm M3 socket head screws, (2) 10mm M2.5 socket head screws, and (4) 10mm M4 thumbscrews.

Pre-Oder your TurtleBot Universal Board Adapter here [Lead Time: 1 week]: http://store.iheartengineering.com/robots/turtlebot/accessories/ihe-2101-0003-0000.html

Open Manufacturing: A Home for the Beagle Bone

People often take for granted the amount of engineering that goes into simple everyday products and items. Very few people know or care why that door handle has a gusset or the reasons washers even exist. Even the most mundane of things have considerable engineering thought go into them. It was decided that I Heart Engineering needed a custom case for mounting a Beagle Bone to the TurtleBot. This is an attempt to walk readers through some of the thoughts and considerations that go into building something so small and seemingly trivial. After all, a case is just another box right?

The first thing is to frame what you want to build by constructing a list of constraints and intentions for guidance. In our case, we decided it needed to consider following:

1. Access to all of the ports with special consideration given to SD Card removal.
2. Maintaining minimal dimensions 
3. Able to be mounted to the TurtleBot using a universal set of mounting holes.
4. 3D Printable Design 

Doing this creates the "world" that your design lives in and as such the tools you may consider using and the initial ideas for construction.

The next step is to obtain or create a 3D Cad replica of the Beagle Bone board. If one has to create their own model for testing, it's best to note that only the major dimensions of the board and components necessary to the case are needed, but they must be accurate.  These include the board itself, it's ports, mounting holes, and anything that one may feel needs to be built around to complete the case. 

Now that we have a physical and 3D model of the Beagle Bone, we can start to draw out the general outline and order of feature construction. I personally rough out a general model idea on paper and then begin creating in a CAD program of choice with the frame. Testing and experimentation are important parts of the design process. I constructed a rough case frame that wraps around the Beagle Bone and printed the piece to test the tolerances and fit. Doing this is beneficial to designers as it saves time over the long term versus running into an unaccounted error later in the process. The idea uses empirical analysis to verify quantitative and qualitative data.

Early test frame for tolerance checking.

After verifying the dimensions, I can now construct the bottom frame of the case. Here is where I asked: well just how high should the case be? To solve this problem, one has to consider the space between the bottom of the board and any components on its underside. In this case, it's ~6mm.  So, one can aim for the bottom half of the case to be 8-10mm or slightly more, but certainly not less. 

So you've built the bottom half of the case frame, now what? Well, you have to get the Beagle Bone mounted inside the frame somehow. Let's consider the 4 mounting holes on the board. I decided to construct bosses extruded from the bottom of the case coming up to the underside of the board. However, one cannot simply create a boss to your desire; this board has components on both sides that limit the amount of usable space. The design also has to be 3D printable which dictates a minimum thickness AND you have to consider the size of potential screw heads. This left only 2 mounting holes with sufficient space on either side for the design in mind.

Test Boss used to verify clearances

The same process is repeated as before, we create a test boss to test the tolerances and verify dimensions, but this time another problem arises. The bosses aren't very rigid and are susceptible to damage. How can one make them more stable and rigid? Well, it turns out the mounting holes are conveniently located close the inside frame of the wall. Therefore, we can build the bosses out from the inside wall, integrating them into the
case frame itself and solving the problem.

After another round of test and fit, we see that the Beagle Bone Board may still teeter and totter on the inside due to use of only 2 mounting holes. Depending on whether you view the amount of deflection as tolerable or not, you can opt to build two bosses located at the unused holes to provide more support. Remember, one has to take into account the actual diameter of usable space for each hole when constructing the bosses.

Internals of bottom half across revisions [left to right.] 

Now we can begin to cut out the access points for the ports on the Beagle Bone board that affect the bottom half of the case. The key thing here is to once again verify that your board dimensions are correct or the test prints will be useless.

Shot of  front side, bottom half port access points across revisions  [left to right.] 

Next, I constructed the mounting points and bottom support layout for the bottom of the case. Thankfully, a much simpler process.  However, we want to save on material to reduce cost and print time. So the bottom of the case does not have to be completely solid. Now we are creating a horizontal support structure that acts as the bottom of the case. One could either go with a simple geometrically rigid structure or use some physics to calculate some assumed forces and optimize accordingly.

Bottom of Case changes across revisions [left to right]

Building the top half of the case is a much simpler endeavor as it's a mirror of the bottom frame. For it, one only needs to consider the access points for ports and maximum vertical height. The access points are already defined and it was decided that the case should extend no more than 10mm from the highest board component.

What we have yet to discuss is exactly how this case fits together.  There are various joinery methods available to close the case. It was personal preference that motivate the decision to use a press fit method to restrict all lateral movement and some vertical movement. The ultimate endeavor is to implement a locking mechanism designed into the case itself that is 3D printable. However, a satisfactory resolution is not ready yet.  Therefore, two ports were added on the left and right sides of the case for use with a small velcro strap to prevent all vertical lift. At the cost of an integrated solution, the case can now be opened and closed with ease.

Close up of  Assembly Secured to TurtleBot 2

The final touches and adjustments necessary for a salable product remain. 3D Printing settings must be created to ensure consistent quality prints. The case top will be taller for accommodating a second potential board stack.  Dimensions may be altered to be better fit the installation of threaded inserts in certain locations. And closing methods may be altered for a better fit.

NOTE: .stl files for printing your own case should be up on Thingiverse on Tuesday afternoon EST.

Update 2/26/2013: Files uploaded to Thingiverse

TurtleBot2 demo in NYC

We will be presenting a live demo of the TurtleBot 2 tomorrow in Manhattan at the 6th NY Hardware Startup Meet up.

See you there!

Open Manufacturing: Laser Engraving and Logos

When you have a hammer, everything is a nail; when you have a laser cutter, everything needs to be engraved.

We have been engraving the backside of our plates with a QR Code and part number, so to improve readability and aesthetics we have been exploring ways to paint the plates.There are two points to cover 

1. Method of Application
2. Paint used in Application.

The painting methodology was tested in two manners. The first, application of paint over the transfer tape. The tape was removed immediately, in one test, and after the paint had dried in another. Neither made a noticeable impact so long as the paint was able to dry undisturbed.

This picture, however, illustrates a flaw in the application using this method:

Paint applied and transfer tape removed after drying

The smudging and distortion of is caused by excessive application of paint. This should be kept in mind for manual use as well as future process automation. When done correctly, the end result so resemble this plate:

Successful Application

It also turns out that as long as the applier takes great care, similar results can be achieved without the use of transfer tape. One simply fills the engraved sections with paint and removes excess from the surface with a cloth moistened with acetone or paint thinner. The results of which are seen below.

Successful Application without Transfer Tape

However, looking at this image, one could say that the green isn't sufficient as some MDF can be seen through it. Perhaps we should look into using something as a base paint and then adding a coat of the intended color, much like priming a wall. Well we did test that and the results were not satisfactory.

Painted with White base layer and Green top coat

Resulted in a mess. This method was not successful in multiple attempts and shelved for later. It is a suspicion that this idea may work better depending on the type of paint used in the application. The necessity for something providing a similar hardness as enamel is understood, but perhaps their are paints available tailored to these types of jobs or more MDF friendly and so forth. We have yet to test this factor.  What we do know is that moderate application of paint and time to dry undisturbed are key to producing a quality fill. Perhaps a better way to mitigate the MDF coverage problem is to increase the depth of the engraving. It so happens that we tested this idea and with levels of success as well.

Why not do the same thing for the topside of the TurtleBot's top plate? Engraved text and images can replace stickers as means of identification and aesthetics.

This is a sticker that we currently have in use:

Companies have logos. Most agree, putting your logo on a product amounts to free advertising. Advertising is so pervasive in our culture products look strange without them. So far, the TurtleBot has only been branded with a simple stickers.  We have been looking at sticker manufacturers that could produce die cut stickers with fine line and details.

While the sticker is of good build quality, it does not entirely meet desired specifications. We wanted a sticker that felt like part of the product; cosmetically, we wanted to achieve finer line width on the lettering and "power heart."

Overall, this idea means we now have a cost effective means of producing high quality labels and logos for prototypes and low volume production runs. In the future, we would like to explore efficient methods of multiple color applications in addition to expanding application methods themselves such as spray painting. Part of that process includes finding solutions for achieving a satisfactory fill.

Fast Visual Odometry and Mapping with RGB-D data

More work from the team at the CCNY Robotics Lab

TurtleBot 2 ROS Groovy ISO BETA 4

If you have a TurtleBot 2 and don't mind re-installing please help us test this!
64-bit ROS Groovy installer for TurtleBot 2
turtlebot-groovy-ubuntu-12.04.1-RC4.iso
Md5sum: c59ad5f22a81a02b9e6b878f9571b656

Please submit bugs to the appropiate issue tracker on GitHub, or here.

RELEASE NOTES
=============
* Unity TurtleBot Dashboard launcher now works
* rosdep now preinstalled for ROS system user and for normal users
* Desktop GUI tools restored
* New Groovy TurtleBot wallpapers
* turtlebot-indicator
 * Provides "help" on initial startup
 * Displays User ROS is running as
 * Automatic startup of ROS can be enabled/disabled

KNOWN BUGS
==========
* SSIDs with spaces break ros-network-id
* Rviz default config needed
* Rename rumblepad2 -> logitech
* Notifications for start/stop
* Android Chirp does not currently work
* Nodelet development is complicated due to ROS System User
* sudo service turtlebot start is deprecated
* UPDATE DOCUMENTATION

Open Manufacturing: Tracking And Laser Cut QR Codes

People like to label things. Labeling, by human convention, provides a means of identification. Perhaps even greater, it gives us a way to create an identity, a story unique to the individual. We find this worth exploring. I Heart Engineering would like to contribute by showing the beginnings of answering the question: how does a small Open Manufacturing/Hardware company effectively organize, manage, and service its products with limited resources? How can we give our customers a way of identifying a part or component on a robot and how can they go about servicing or acquiring another one? Further, how do we give our parts and components an identity as if it were a spime? The TurtleBot 2 shipped from I Heart Engineering tests one of our initial ideas.

Over the past year, an internal part numbering scheme was created for our use.  In fact, the methodology for said system is located on our Wiki Page Learn.IHeartEngineering.com as well as other useful information. Creating a part number for every component and product comes with a set of advantages and disadvantages.

A major responsibility is proper maintenance and sequencing of internal components (a task that may require dedicated staff as the business scales upward.)  Often, it is necessary to augment your system to include a type of part, component, or product previously excluded. For example, we now have a Kinect Sensor Standoff and Xtion Sensor Standoff for the TurtleBot 2.  In some ways, the Xtion Sensor Standoff is a revision of the Kinect version (removed taper and M4 threaded holes vs 6-32 stud on one end.) A different perspective identifies the Xtion Standoff as an individual part because of its intended use with the Asus Xtion vs the Kinect.  We decided to treat it as an individual part and have assigned the Xtion Sensor Standoff a new part number over making its number a revision of the Kinect Sensor Standoff.

Some things are produced in-house, others outsourced. In the case of outsourced manufacturing, an internal part numbering system proves to be extremely beneficial. Placing orders between you and your manufacturer becomes effortless after providing them with properly documented information. It also keeps the flow of information between departments from being corrupted.  Instead of holding your accounting department's hand when ordering more inventory, you can simply provide an order with references to the internal part numbers.

In some scenarios, we are simply ordering materials and items from a vendor or distributor.  These items have 2 sets of part numbers. One from I Heart Engineering and the other from the vendor/distributor themselves. This gives the ability to purchase similar commodities from various sources and treat them as the same item.  The task, then, is to create a system in which we can identify an item by its internal and external part number. This information is consolidated by our use of an Open Source Inventory management system called PartKeepr. In it, we are building an entire catalog of internal inventory. Items may be categorized by "what" they are, but their pages tell us "who." Meaning the internal and external part number as well as that vendor/distributor's information for placing the order. Built up over time, it makes being able to stay focused on working easier as the business begins to scale.

The first consumer facing application of our system appears on TurtleBot 2's distributed by I Heart Engineering. Users should notice a QR Code and Part Number located on the underside of their TurtleBot 2 Plates.

Scanning the QR Code directs the user to the product's wiki page. [TurtleBot 2 Disk 1 Wiki Page] All of the information useful for manufacturing the Disk can be found here, as well as linking to the store for purchase.  When your business begins to scale, a second or augmented part number can be created to possibly denote time and location of manufacture. 

Some Things About Lasers and Codes

During test manufacturing of the QR Codes, some interesting things were noticed. One is the conflict presented by contrast. The other is that the "Buffer Zone" surrounding the QR Code itself is critical for success, but can be flexible in certain conditions. (1)

Notice the difference in the 3 rows pictured, each has a different sized border.  

1. No Border
2. Border is approximately equal to size of single QR Code data square
3. Border is approximately 4x the size of a single QR Code data square

QR Code best practices recommends that 4x the data square be the standard for Buffer Zones.  However, the Row 2 Codes were able to be scanned by some QR Code readers sporadically and others not at all. The performance was not suitable for a shipping product, it was just interesting to note that the contrast of light brown on Black was enough to offset the recommended Buffer Size in some [admittedly few] situations. It stands to reason that possibly increasing the Row 2 Buffer Zone to 2x the size of a data square would boost reliability to that suitable for a shipping product.

Remaining on proper contrast for one's QR Codes. Black MDF provided an interesting quirk. The QR Code generators I've used seem to all generate Black on White QR Codes. If you raster the MDF with the codes as is, they will be unusable for reasons illustrated below.

For the sake of argument, let us assume that the Black squares on the QR Codes represent the actual data (instead of really being a matrix of data.)  Laser Cutters do not raster the white areas, they raster the black weighted lines and objects.  This means that, on Black MDF, the data is "inverted" and thus unusable.  To remedy this, invert the color of the QR Code and then place the properly sized "Buffer Zone." 

Another interesting characteristic of the QR Codes found on our TurtleBot2 Disks are that they can only be scanned within 120.8mm or ≈5inches.  This was calculated using the formula: 

Minimum QR Code Size = (Scanning Distance / Distance Factor) * Data Density Factor (1)

The Distance Factor is a constant from 10 to 1 based on the lighting conditions.  Data Density Factor is the number of data columns in one's QR Code divided by 25. 

Approximating Scanning Distance ≈ (14mm * 10) / (29 data columns / 25)
                                                    ≈ 140mm / 1.16
                                                    ≈ 120mm or ~5"

Also, for those of you with access to laser cutters looking for a better finish on MDF raster jobs without much effort, use Transfer Tape when engraving the object.  The CO2 laser burns some of the tape material onto the MDF creating a sort of white fill over the raster area adding some polish. I have not tested this effect on other materials in our Helix. 

1. QR Stuff. http://www.qrstuff.com/blog/2011/01/18/what-size-should-a-qr-code-be

32 Bit TurtleBot 2 ISO

If 32-Bit are all you got, this ISO should get your TurtleBot 2 up and running 32-Bit TurtleBot 2 ROS Groovy ISO Beta 2 (1.2GB)

http://data.iheartengineering.com/files/turtlebot-groovy-ubuntu-12.04.1-i386-beta2.iso

md5sum: e8e1537f6294c0de5e5e2a53d88f6775

Work Continues

This video demonstrates the TurtleBot 2 mobile robot performing automatic docking maneuvres using an Android app. This demo works out of the box and only requires that the TurtleBot has a working wifi connection. Once docked, the mobile base and the on-board laptop both begin charging so the robot is always ready for whatever tasks are queued.

To get the robot to start ROS on bootup with minimal configuration we have developed an external Debian package ros-system-daemon-groovy. This package provides infrastructure to run ROS system wide as user 'ros' in a way that is compliant with the Debian FHS with logs written to /var/log/ros and rotated on a daily basis and expired after a week. The package includes network autoconfiguration tools that query NetworkManager via D-Bus and Upstart scripts that start ROS once a network connection becomes active.

This package is designed not just to work with the TurtleBot, but we hope that it can be useful for other robot developers who need a way to start ROS at bootup.

Basic documentation for the package can be found here.

Feedback is greatly appreciated and please submit bugs and feature requests to the issue tracker on Github.

TurtleBot 2 ROS Groovy ISO BETA 2

Round 2, Start!


THIS ISO INSTALLER (1.2GB) CURRENTLY ONLY SUPPORTS TURTLEBOT 2 however patches and bug reports for TurtleBots using the Create mobile base are appreciated. Please file bug reports via the associated github issue tracker. If you can not find the correct tracker, please file bugs against https://github.com/TurtleBot-Mfg/turtlebot-iso

The current plan is to release support for TurtleBot 2 later this week and then proceed with backporting support for TurtleBots with Create base.

External Debian System integration packages can be found here.
https://github.com/TurtleBot-Mfg

PPA for ROS + Ubuntu Integration
https://launchpad.net/~iheartengineering/+archive/ros-support
TurtleBot 2 ROS Groovy ISO Beta 2 (1.2GB)

http://data.iheartengineering.com/files/turtlebot-groovy-ubuntu-12.04.1-beta2.iso

Selected Features

This release resolves some minor bugs, and more importantly merges the latest packages synced from shadow-fixed.

md5sum: 5fb0897d5995ce312e714619b1ee9781

TurtleBot 2 ROS Groovy ISO BETA 1

We are now working on fixing all of the remaining issues for a new TurtleBot 2 ROS Groovy release and if you have a TurtleBot 2 we can use your help testing.

THIS ISO INSTALLER (1.2GB) CURRENTLY ONLY SUPPORTS TURTLEBOT 2 however patches and bug reports for TurtleBots using the Create mobile base are appreciated. Please file bug reports via the associated github issue tracker.

The current plan is to release support for TurtleBot 2 next week and then proceed with backporting support for TurtleBots with Create base.

External Debian System integration packages can be found here.
https://github.com/TurtleBot-Mfg

PPA for ROS + Ubuntu Integration
https://launchpad.net/~iheartengineering/+archive/ros-support
TurtleBot 2 ROS Groovy ISO Beta 1 (1.2GB)

http://data.iheartengineering.com/files/turtlebot-groovy-ubuntu-12.04.1-beta1.iso

Selected Features

• https://github.com/TurtleBot-Mfg/turtlebot-ros-groovy
• rosdep automatically initialized offline for user 'ros'
• https://github.com/TurtleBot-Mfg/ros-system-daemon-gr1oovy 
• ROS runs as user 'ros'
• ROS starts automatically once WiFi network is configured
• rosctl replaces turtlebot-start, turtlebot-stop
• logrotate used to automatically rotate logs daily and delete after a week
• turtlebot-network renamed to ros-network 
• https://github.com/TurtleBot-Mfg/turtlebot-env-groovy 
•  kobuki udev rules installed automatically

Known Bugs

• turtlebot-doc-groovy installed documentation needs to be updated.
• http://ros.org/wiki/kobuki_node
• http://kobuki.yujinrobot.com/documentation/
• http://learn.iheartengineering.com/wiki/TurtleBot

ROS Groovy

ROS Groovy is now available along with updated tutorials.

Having recently realized that we built our own version of Bloom,

We are now looking forward to switching to Catkin/Bloom so we can create applications that can integrate better with Ubuntu/XDG/Indicators/Unity/etc and still take advantage of the common efforts of the build tools developed for ROS.