For best results, training should be considered a full time job. One’s entire lifestyle must be directed towards this objective. This lifestyle will also require following the correct training program religiously over time.

All athletes are limited more by their minds more than their bodies

One needs to develop a winning attitude. One needs to combine physical fitness with mental fitness.

This chapter touches on a few mental opportunities for success:

• Motivation – Competitive cycling demands an inner drive to excel. Everything in your life must be focused on the goal
• Dreams, goals, and missions – high performance starts with a dream. This turns into a goal, and ultimately the mission. Are you willing to make any sacrifice, ride any number of miles, or do any workouts deemed beneficial to achieving the goal?
• Believe to achieve – there are bound to be setbacks. One needs to remain confident, patient and mentally tough to power through. Relive each day’s wins, big or small to boost self-confidence
• Mental toughness – when we’re at our limits, fatigue sets in, and the mind tries to make compromises. A fully committed rider gets through it
• Patience – success won’t come quickly. We can introduce incremental change, like: sleeping 30 minutes earlier each day, cutting out 10% of junk food from our diets, etc.
• Commitment and tenacity – there are moments where fatigue says to stop, but the fully commited and tenacious rider finds a way to keep going
• Consistency and routines – the mind and body like regular and standard schedules. Things like jobs, families, and other responsibilities may interfere
• Your high-performance team – surrounding each champion is a network of family, friends, teammates, coaches, etc.

This topic can get rather deep, so there is value in reading other books on the subject and speaking with other successful professionals from all walks of life.

By improving one’s mental approach to cycling, their training and racing will benefit greatly too.

Next: Chapter 2 – Physical performance
Chapter list: Chapter summaries

It’s reminiscent of other developing Asian nations. People are riding around in motorbikes, pedestrians cross the street by weaving through vehicles, and there’s so much traffic that it kicks up a ton of dust. Cars here often don’t have AC and more often than not have hand cranked windows. The official language is Nepali, but many people speak Hindi or at least know some words. It’s timezone is also quite interesting… Its offset is 5:45 from UTC meaning it’s got a timezone that shifts in 15 minutes instead of a whole hour. And I thought India’s 30 minute shift was annoying.

Durbar Square once held the palaces over the kings that ruled over the city. In the surrounding area, there are also some courtyards and temples. The architecture of the temples is reminiscent of temples in China, which makes sense since Buddhism is quite prevalent in both countries.

In the center of the square, masses of street vendors sell trinkets to visitors. The trinkets are mainly Buddhist prayer bowls, and other religious paraphernalia.

The most shocking thing to me in Nepal, is that as a part of their Hindu and Buddhist traditions, people worship “kumari“, young prepubescent girls that represent the manifestation of divine female energy.

The worship of the goddess in a young girl represents the worship of divine consciousness spread all over the creation. As the supreme goddess is thought to have manifested this entire cosmos out of her womb, she exists equally in animate as well as inanimate objects

Wikipedia

Within Durbar Square, in an almost non-descript brick building, the kumari appears from time to time within the windows that look into the courtyard of the building, but no photography is allowed. I had randomly stumbled upon this building only because there were so many people around it.

The Boudhanath is one of the largest Buddhist stupas Nepal, and it’s architecture is unlike anything in the city, so it’s quite prominent. The prayer flags have five colours, which represent different “elements”: earth, water, fire, air, and space. The elements are also represented as a part of the structure with the base as earth, the dome as water, the square platform as fire, the spire as air, and the umbrella as space.

The Pashupatinath Temple is situated on the banks of the Bagmati River, and is a Hindu religious place. Where the fires burning in the picture is the actual place where cremations happen. Within the area are a collection of different temples, but I wasn’t allowed to visit them because I’m not a Hindu. I never thought I’d ever be discriminated for my religion (or lack thereof)!

See more pictures of my trip to Kathmandu here

My computer specifications:

• Intel Core i5-4570
• 16 GB Memory
• Radeon HD 5770

I followed the instructions here, with these changes:

• Using video driver “fglrx-updates” (the tutorial talks about NVIDIA cards)
• Did not install TuxLoL
• Did not do anything regarding the “Maestro error” since it only applies to Optimus Notebook users
• Did not follow step 6 because I did not run into the problem for big item icon text for the item shop
• EDIT: Thanks to Ingvar’s comment, the installation progress for the game can be viewed like so: open terminal (Ctrl+Alt+T) and execute:

tail -f ~/.PlayOnLinux/wineprefix/LeagueOfLegends/drive_c/Riot\ Games/League\ of\ Legends/Logs/Patcher\ Logs/*.log

There are also other steps that I had to do, which I read from here:

• Click configure for the “League of Legends” entry in “PlayOnLinux” and find the “Display” tab and then choose the following options:
  • Direct Draw Renderer – gdi
  • Video memory size – 4096 (or something else depending on graphics card)
  • Offscreen rendering mode – fbo\0
  • Everything else on default
• Create a file called “game.cfg” in the directory “/home/your-username-here/PlayOnLinux’s virtual drives/LeagueOfLegends/drive_c/Riot Games/League of Legends/Config”. Below is what I have in my “game.cfg”:

[General]
EnableAudio=1
GameMouseSpeed=10
UserSetResolution=1
BindSysKeys=0
SnapCameraOnRespawn=0
OSXMouseAcceleration=1
AutoAcquireTarget=0
EnableLightFx=0
WindowMode=0
ShowTurretRangeIndicators=0
PredictMovement=0
WaitForVerticalSync=0
Colors=32
Height=1080
Width=1920
SystemMouseSpeed=0
CfgVersion=5.3.296
x3d_platform=1

[HUD]
CameraLockMode=0
MiddleClickDragScrollEnabled=0
KeyboardScrollSpeed=0.5000
ChatScale=50
ObjectTooltips=0
AutoDisplayTarget=0
ShowAllChannelChat=1
ShowTimestamps=1
ItemShopPrevY=39
ItemShopPrevX=106
NameTagDisplay=1
ShowChampionIndicator=0
ShowSummonerNames=1
ScrollSmoothingEnabled=0
MiddleMouseScrollSpeed=0.5000
MapScrollSpeed=0.5000
ShowAttackRadius=0
NumericCooldownFormat=1
SmartCastOnKeyRelease=0
EnableLineMissileVis=0
FlipMiniMap=1
ItemShopResizeHeight=0
ItemShopResizeWidth=164
ItemShopPrevResizeHeight=1080
ItemShopPrevResizeWidth=1920
ItemShopItemDisplayMode=1
ItemShopStartPane=1

[Performance]
CharacterInking=1
ShadowsEnabled=1
EnableHUDAnimations=0
PerPixelPointLighting=0
EnableParticleOptimizations=0
BudgetOverdrawAverage=0
BudgetSkinnedVertexCount=0
BudgetSkinnedDrawCallCount=0
BudgetTextureUsage=0
BudgetVertexCount=0
BudgetTriangleCount=0
BudgetDrawCallCount=0
EnableGrassSwaying=0
EnableFXAA=0
AdvancedShader=0
FrameCapType=6
GammaEnabled=0
Full3DModeEnabled=0
AutoPerformanceSettings=0
CharacterQuality=4
EffectsQuality=4
EnvironmentQuality=4
ShadowQuality=4
GraphicsSlider=6
paths=0

[FloatingText]
EnemyTrueDamageCritical_Enabled=1
EnemyMagicalDamageCritical_Enabled=1
EnemyPhysicalDamageCritical_Enabled=1
TrueDamageCritical_Enabled=1
MagicalDamageCritical_Enabled=1
PhysicalDamageCritical_Enabled=1
Countdown_Enabled=0
EnemyTrueDamage_Enabled=0
EnemyMagicalDamage_Enabled=0
EnemyPhysicalDamage_Enabled=0
TrueDamage_Enabled=0
MagicalDamage_Enabled=0
PhysicalDamage_Enabled=0
Score_Enabled=0
QuestComplete_Enabled=0
QuestReceived_Enabled=0
Disable_Enabled=0
Level_Enabled=0
Dodge_Enabled=0
Heal_Enabled=0
Special_Enabled=0
Invulnerable_Enabled=0
Debug_Enabled=0
Absorbed_Enabled=0
OMW_Enabled=0
EnemyCritical_Enabled=0
MagicCritical_Enabled=0
Critical_Enabled=0

[Volume]
SfxVolume=0.5
MasterVolume=0.5

Looking back, I should have used a book like the “UnrealScript Game Programming Cookbook” by Dave Voyles.  This book is directed towards audiences who have never touched Unreal programming before.  However, it does require readers to have some familiarity with general object oriented programming knowledge.

This book in particular follows a recipe-based approach for teaching the basics of Unreal programming and covers the core topics in programming for UDK.  The recipes are designed to be basic in order to give learners good exposure without too much of a knowledge dump.  Some may argue that having a recipe-based approach doesn’t teach people how to synthesize solutions for themselves.  I see recipes as a good stepping stone.

This book is not meant to teach you everything there is to know about UDK, but enough for people to get started with a good foundation to learn off of.  From the book, I would have liked to see more details about the nuances of the UnrealScript language, as well as a more big picture view of how all the different topics illustrated in the book fit together – perhaps a chapter dedicated to that.  The way it is organized right now is that the big picture is explained, but the explanations are scattered throughout the book.  I am someone who much prefers a more top-down approach on topics like this.

In any case, this book is still a great resource for learning Unreal programming and I would recommend it to people who would like to start their learning adventure in UDK.  Here is a sample chapter of the book for those who are curious in seeing for themselves what this book has to offer (here).  For more information about the book, click here.

Print Volume

This is the amount volume that the printer is able to print in.  Generally, the measurement is given by the three dimensions of a rectangular prism.  The thing to watch out for here is that just because a printer has a large print volume, it does not mean the printer can reliably print in all of it.  Say the design calls for a thin flat plate.  If the plate is too wide, then the edges of the plate will peel/warp during the print and the flat shape that was intended will be slightly curved.  To visualize what warping is, imagine a flat plate lying on the print bed as it is being printed.  Warping is when the corners of the plate start peeling off the base during a print.  Warping will be explained in a little more detail later on.

Resolution

This describes the accuracy of the nozzle’s positioning.  It is usually measured in microns or inches.  Clearly a smaller value means that the printer will be more accurate in its position.

Layer Thickness

Because the printer works by extruding layers of plastic, thinner layers allow for more fine details.  However, more layers means that the part will take longer to print (all other things being equal).

Print Speed

3D printing is generally a slow process, but a faster print speed could definitely help offset that.

Nozzle Diameter

A small nozzle diameter means that the extruded plastic will be narrow and thus allow for fine details.  It also improves the smoothness of the printed object.

Ease of Removing Parts off the Platform

Because during a print, the base of the part (ideally) should be firmly adhered to the print bed, one must take care when removing the part from the print bed.  In some cases, removing a part requires a little bit of force to pry the part off the print bed.  This application of force may affect the alignment of the print bed relative to the nozzle.  In lower quality printers this can permanently affect the alignment or require frequent re-calibration   Seeing how “rigid” the print bed assembly can help assess how the machine accuracy can be affect during part removal.  For example, if the print bed is mounted on really large support structure, then the affect of misalignment is less of a problem than a machine where the print bed is mounted in a smaller support.

Enclosure

Some printers enclose the part to be printed in a box and some don’t.  The reason an enclosure exists is so that the machine is able to prevent the part being printed from losing too much heat during print.  Loss of heat during a print negatively affects the adhesion of the printed plastic.  Also a larger temperature difference means the part will warp more.  Without an enclosure, heat is able to freely transfer to the ambient.  High quality printers generally have an enclosure.

Variety of Printed Materials

A common material to print with is ABS.  Other materials such as PLA can be printed as well.  The use of the particular material can be quite dependent on the application of the printed part.  The cost of material also differs.  It is worthwhile to determine what material will be printed.  In many cases, ABS should be sufficient.

Warping

This is probably one of the biggest limitations of 3D printing.  Because of the use of heat during print, it is natural for the part to shrink as it cools down.  The problem is that the shrinkage is not uniform.  Some parts of the model shrink more than others and most of the time it is very unpredictable.  While there are some general guidelines that designers can follow to reduce warping, there are definitely some machine features that are good to have to help reduce warping even further.  Because the nature of the way the printer prints is that plastic is extruded layer by layer, the plastic layer at the very bottom is the first to cool down.  Cooling down means shrinkage.  This also means that as the bottom of the model shrinks, the printer is still printing on top of a slightly shrunken part.  Sometimes the shrinkage can be so bad that the part pulls itself off the print bed.  When the part is no longer securely adhered to the print bed, the part may slide around and ruin the entire print.  Warping is the enemy of 3D printing.

Below are some qualities of a machine that help reduce shrinkage:

• Heated print bed – a heated print bed keeps the plastic hot during the print and does not let the base cool down as much as if there were no heated print bed
• Enclosure – described above

There are more ways to reduce warping that the designer can do, but that is outside the scope of this article.

Number of Nozzles

A lot of printers just have the one print nozzle, but there are some with multiple.  This allows printing with multiple colours or in some cases printing with a water soluble support material.  Generally, support material has to be manually removed from the printed part, but if the support material is water soluble, this saves a lot of the manual labor involved in cleaning up the model.

Nozzle Maintenance

Through extended use, the nozzle can become quite dirty, that is black gunk starts building up on the surface of the nozzle.  If one is not careful, this can clog the print nozzle.  It is worthwhile to find out how often the nozzle needs to be replaced.  There are also other factors that may result in the need to replace a nozzle.  This is a recurring cost of maintaining the printer.  Some nozzles are cheaper and more common than others and it is worth it to see how often the nozzle needs to be replaced and how much it will cost each time.  Machines may come with extra nozzles.

Lubrication

Over time, moving parts may have to be lubricated.  Printers should come with a maintenance manual to help instruct the user how to do this.  It is also helpful to know the cost of the lubricant and how often it will be required.

Machine Lifetime Cost

Aside from the cost of the machine, operating a 3D printer can also incur the following costs:

• Shipping
• Insurance
• Brokerage fees
• Tools for removing support material
• Currency conversion
• Sales tax
• Print material (recurring)
• Replacement nozzles (recurring)
• Lubricants for moving parts (recurring)

As it can be seen, the extra costs can be quite significant.

Conclusion

Hopefully this has given a good general overview of some of the considerations in buying a 3D printer.  Different people will value different things in the printer and hopefully this subset of possible considerations for buying a 3D printer helps people make a decision as to what to look for in a printer.

Flying to Mexico City

When we got to Dallas Airport, we had a stopover of few hours, so we decided to have some Texan steak – or at least as Texan as we tried to get without leaving the airport.  We ended up at TGI Fridays.  It was the first steak that I’ve had in a long time, and I definitely could use another one.  The steak even came with “Jack Daniel’s Sauce”, which made it that much better.

After eating, we met up with two others on the team who had flown from San Jose and Toronto.  After a four hour flight to Dallas, and other few hours of stopover there, we had to fly for another two and a half hours to get to Mexico City.

As my friend said, “it’s like China happened”.  The Benito Juárez International Airport was probably the most disorganized airport I’ve ever seen.  It’s as if every single flight landed at the same time.  The lineup to grow through customs took at least forty-five minutes.  During this whole time, everyone was tired and wanted get their sleep.  A lot of the people on the team hadn’t slept the night before (rather than sleep 2 or 3 hours to wake up early for the flight right?).  While in this lineup, we saw a couple of other RoboCup teams landing as well (Skuba, MRL, among others).  After finally getting through customs and a security check, we got a ride to our hostel via transportation that we organized with the hostel prior to our departure.

Hostel Mundo Joven Catedral

The hostel we stayed had very nice staff that really cared about making its guests feel safe there.  It’s a common feeling among travelers to think that Mexico City is definitely not one of the safer places to travel to.  To combat that, the hostel had its own security guards, security cameras, and they even called legitimate taxi’s for its guests.  They even told us which direction to walk when leaving the hostel to avoid going to the shadier parts of town.  Furthermore, it was situated in the historic center of Mexico City, within walking distance of the Metropolitan Cathedral of the Assumption of Mary of Mexico City and the Plaza de la Constitución.  From some of the rooms at the hostel, there was a nice view of the cathedral.

Work Day

We spent the next day working on the robots to make sure none of the mechanical parts had been affected during the flight from Vancouver.  We had packed all the robots in a regular suitcase with packing foam all around it to protect it.  Looking over the mechanical parts, everything was in order.  The main things we had to fix were tightening screws, adjusting the wiring etc.  The software team had very little to do because they’ve written all the code they could, and just needed robots to test with.  The electrical team on the other hand, toiled tirelessly to troubleshoot all the boards and make sure they were all functioning properly.

RoboCup Begins!

We arrived at the competition venue, the World Trade Center at 8 AM to find a slew of other teams patiently waiting to register.  After probably an hour long wait, we all finally moved in and set up our work places.  When we looked at the field the robots would be playing on, we noticed that the organizers hadn’t yet set up the cameras yet (required for the robots to “see” where they’re going).  This meant that no teams could test.  Teams that were ready could only wait until the organizers got those set up.  Because of this delay, the games had to be delayed as well.  This gave us more time to get the robots ready.  For the next little while, we were the first team to arrive and the last team to leave everyday.  The electrical team needed all the time they could get to finish everything.

Because we had already finished most our maintenance work the day before, there wasn’t a whole lot we could do.  The electrical team had to continue working on their stuff to get as many robots ready as possible.  For the next day and a half, we let the electrical team do their work and we’d help them along the way by replacing parts that were broken (encoders and such).  Otherwise, there wasn’t much we could help with.

Food for the next Week

When we got hungry during the competition, we did a little bit of exploration to find food.  Eventually, all the teams wound up at the same shopping mall for food.  There was a supermarket downstairs to buy water and a food court upstairs with a variety of foods.  We went to this mall pretty much everyday for as long as we were at the World Trade Center.  One day we’d try Mexican food, other days we’d try plain-old hamburgers and other days we’d try even Chinese food (at least the white person’s interpretation of it).  It wasn’t really healthy for us, but we figured it was only for a week.

For dinner, most teams ended up ordering pizza from the nearby Domino’s.  We ate it so much that everybody got sick of having pizza.  Sometimes, we’d have dinner with other teams at our hostel restaurant so we could get to know them a little bit better.  After all, the competition is more about mutual learning and robotics advancement rather than about winning.

Let the Games Begin

Because our team wasn’t that ready to begin with, we had to forfeit our first game against the Immortals from Iran.  By the time we got three robots up and running, we played against the RoboJackets from Georgia Tech.  They only fielded five robots out of the total six.  For most of the game, both teams played pretty evenly, despite their two-robot advantage.  All was going well until one of the opponent’s robots chipped the ball that hit the top of one of our robots, bounced off and rolled into the goal.  In that particular situation, the referee had called an “indirect free kick”, meaning the shot, even if it went in the net, would not count.  But unfortunately, that rule was not applicable because it hit off of another robot.  It was an unlucky goal for us, and we definitely could not score a goal to tie up the game.  We ended up losing one-nil.  For the next few days, we kept complaining about that goal.

In our third game, we played against RoboFEI from Brazil.  There were so many good scoring chances in this game from both our teams that made this game so intense.  Even though we were only watching machines play, everybody cheered them on.  We had four robots on the field this game and they all worked like a charm.  The mechanical system, electrical system, and the artificial intelligence worked so well together.  It was a great feeling for everyone on our team – to see our design work.  After almost a year of hard work, this was it.  We saw our robots move, intercept balls, shoot on the goal, etc.  A lot of the robot shortcomings from the North American Open were also dealt with, such as the problem of the break beam sensors not working, and the robot not moving accurately on the field.  When we scored, we cheered so loud that every single person in the room could hear us (there were probably about 1000 people in that room).  We all got an immense feeling of satisfaction in seeing our working robots score their first goal.  A few minutes later, the other team scored a goal.  It didn’t matter to us, we were still high in the clouds in terms of our mood.  The game ended 1-1.  Despite the tie game, everyone on the team was so happy in seeing our robots work, it didn’t matter what the result was.

This was a great morale boost for the team because for our forth and last game, we played against BRocks from Turkey.  This time, we had our full fleet of robots.  We played our first six on six game.  Yet again, we saw our robots work.  Nothing broke down during the game and everything just worked.  It was quite rare for us to just put our robots on the field and have nothing go wrong.  At one point, our robot shot the ball into the opposing robot and a piece fell off of it.  We knew our design worked when stuff like this happens.  This game was less intense for us than our previous game, but we did end up winning.  That put our record at 1 win, 1 tie, and 2 losses – a total of 4 points.  Unfortunately, this wasn’t enough for us to advance to the next round of the competition and as a result we finished 13th out of 20 teams in the league.  Not so bad for having zero working robots when we got to Mexico.

After the official games, we played a couple friendly games with other teams.  The first game we played was against the Mannheim Tigers.  The game was going well, until we found problems where some of the screws on the robot weren’t tightened sufficiently.  As a result, things well off the robot when we played.  It was quite embarrassing to see.  At least it was only  something minor like putting in a screw, and not something major like a design problem.  In our second friendly game, this time against ER-Force from Erlangen, we found some electrical parts frying randomly on the board, which wasn’t good either.  Out of six working robots, we now had three – still a net gain I guess.

After we were done playing, we watched the other teams play for first place.  From watching their games, it was clear that they played on a way higher level than we did.  Everything that their robots did were way better than ours.  Shooting was faster, chipping went further, robots moved faster, kicks were more accurate, etc.  Everything about their robots was just better.  There is definitely a lot we could learn from these teams.  The final winner of this year’s competition ended up being Skuba from Thailand, who beat ZJUNLict from China.  Both teams analyzed each others strategies for days, but only one team could come out on top.  And now for the fourth year in a row, Skuba remains the undefeated winner of the competition.

Other Leagues in RoboCup

During our idle time, we walked around the other rooms to see how the other teams were working.  RoboCup has many different competitions under its name, while our Small Size League competition is only one small part of it.  Leagues range from soccer robots, rescue, simulation, to even home care robotics.  In the home care robotics league, the competition involved a robotic navigating through a mock house to perform certain chores such as picking up objects to hand to people, speaking and hearing instructions, etc.  It was an admittedly difficult task to do for these robots, but many teams were quite successful at it.

Accidents Happen

Just like in the North American Open, there was yet again another accident involving batteries.  Except this time, nobody noticed and the whole battery lit up in flames.  Somebody just yelled “fire, fire!” and started trying to pat it down with something.  Knowing that I was too far away to do anything, I just took out my camera and snapped a picture of the whole thing.  Eventually, someone just poured lots of water over it to put our the fire.  In retrospect, that might not have been a good idea since water in an electrical fire is not really a good thing.  Nobody got hurt though, which is good.  Afterward, the organizers didn’t let us charge batteries nearby our work space anymore.

Some Design Shortcomings

Knowing that our ball kicker would be able to withstand impacts of the ball, what we had forgotten to analyze was how well the kicker would hold up if it hit a object fixed to the ground.  We found out the hard way at the competition after a few games when we discovered that our robot kicker head was bent out of shape.  We also had a lot of turf buildup inside the robot that was enough to slow down the wheel during the game.  This turf had to be cleaned out after every match.

For the kicking mechanism, the robot uses a solenoid/plunger mechanism.  Activating the coil would cause the plunger inside the core to move quickly to hit the ball.  A rubber band secured to the end of it would allow the plunger to return to its initial position.  The problem with this setup was that the rubber band would easily break and had to be replaced after every game.  When we took out the rubber band, we could always see cut marks along it.  In another instance, a chipper solenoid on a robot almost popped out.  It’s not really clear why this happened at all, but it could have been a screw that was not very tight to begin with.

RoboCup Closing

To close the competition, there was a soccer game where humans played against the middle size league robots.  It was pretty funny to see the robots struggle to take the ball away from people who could handle the ball way better.  At the same time, the humans were really scared of the robots since if a human ever got hit by the kicker head from the robot, it would break bones.  The robot goalie however, proved quite competent in blocking shots – better than the human goal from what I saw.  Or maybe the human goalie wasn’t trying very hard.  I’m not sure who won the game since I didn’t watch the whole thing, but it was still really interesting to see.

Afterward, all the teams packed up their things and waited for the closing banquet.  At the closing banquet, they served a standard meal for everyone.  It was a really good chance for teams to celebrate their achievements and finally relax a little bit after the competition.  Everyone deserved a rest after all of that.

First Real Tour of Mexico – Teotihuacan

After the competitions ended, most teams stayed an extra day or two to see the sights in Mexico City.  The organizers of the Small Size League were nice enough to organize a tour for everyone the day after the competition ended.  Most of the SSL teams went with us to the Aztec pyramids in Teotihuacan.  The tour first showed us how their predecessors used different plants and minerals to make tools such as knives and sewing thread.  That part was interesting at first, but I think what a lot of us really wanted to see were the pyramids.  Afterward, the tour guide led us to the gift shop.  For some reason, most of the people were so interested there, it took about an hour for everyone to finish so that we could move on with the tour.  After the gift shop, we finally made it to the pyramids.

After walking up and down the pyramids, we had lunch and went back to Mexico City to see the Basilica of Our Lady of Guadalupe.  This was one of the most visited Catholic shrines in the world.  But because I had already visited so many churchs and cathedrals from my tour around Europe, this part of the tour was less interesting for me.

Historic City Center

The team would fly back to Vancouver on the day after visiting the pyramids.  But before leaving, we made sure to visit the Metropolitan Cathedral of the Assumption of Mary of Mexico City and the Plaza de la Constitución.  In the plaza, hung a giant flag of Mexico.  This is where the city center used to be, at least during the 19th century.

Going Home

After 10 days in Mexico, we all longed to go home.  It had been a long week – full of stress, adrenaline pumping excitement and overall a good experience.  But after all that, we were ready to go.  We flew out in the afternoon from Mexico City.  Apparently, at around the same time that we were at the airport in Mexico City, three cops had been shot to death.  While we were there though, we didn’t hear anything of it.  We safely arrived in Dallas for a brief stopover and arrived back in Vancouver at about 8:30 PM, just in time to go home, wash up and go to bed.

More photos here

Team Formation

I think this is where a lot of students struggle when things go wrong.  It’s always possible to get a teammate that is hard to work with.  While it is no fault of either person, the two personalities (either in values, cultural background, style of working, way of thinking, etc.) are different enough to cause disagreements.  At times, the disagreements can become so heated that the team’s progress in the project is hindered.

I realized that there were communication issues among each other in the group, which delayed progress in the early stages of the project.  These issues came about in the form of misunderstandings of what people said during team meetings.  I found myself in the position where I was expressing my own interpretation of what people said in the hopes that everyone would reach a common understanding.  As the project went on, family issues prevented one member from continuing this project further.  In a way, this eased our communication problems since communication between three people was a lot easier than between four people, based on what I experienced in the project.  Afterward, our team became a lot more efficient and progressed at a faster rate than before.

One of the things that the mechanical engineering curriculum at UBC teaches is team dynamics.  After learning a lot of theory as to how to work best with teams, doing projects with other people puts that knowledge to the test.  Some people don’t really manage working with others and feel set in their ways.  Differences among people exist and I realize that adjustments in the way I work with them is required in order to promote a healthy functioning group.

Project Scope

In retrospect, I would have advocated reducing the project scope since; I feel that the hours we put in were beyond what the course asked for.  I estimate that each member put in over 300 hours on the project.  Since a large part of this course is about design justification, time is very realistic constraint that can limit project scope.  At the same time, there are other courses to worry about.  By spending extra time on 45X, less time is available for other courses.

In the beginning of the project, I couldn’t predict well how long things would take.  Therefore, time for “messing up” or “unforeseen consequences” should be budgeted for.  Many people say things like “I can finish this in about 2 hours”, but in reality, it will take him two days.

Documentation

Very often I found myself referring to old dossier documents to find out information that I needed to know. For example, if I forgot how much something cost, I looked back on the dossier to find out.  If I forgot one of the project requirements, back to the dossier I looked.  At times, it is a bit of a pain to write some sections of the dossier since I couldn’t make sense of the some of the wording.  To deal with it, I had to ask the project supervisor during team meetings.

Project Logistics

I booked as much machine shop time as we could ahead of time knowing that we would need it.  The team would have liked to send in parts for the waterjet or have the technicians work on them, but we were way too late for that.  With a simpler project scope, we could have designed our parts faster and could have been further ahead in those manufacturing lineups to decrease the lead time.  My teammates and I spent quite a bit of time in the machine shop to get as much as we could ready for the design review.  At the same time, I had to look at when ordered parts arrived such that things would arrive in time so that we had everything prepared while building the prototype.

Time Management

While doing 45X, I was also working on New Venture Design and Thunderbots at the same time, which also took up a lot of my time.  As with design projects, they take up the most time relative to other courses.  For me, I had to juggle these three for the entire year.  This gave me a lot of stress at times, but it taught me to be more productive.  For example, on the way home, I would be responding to e-mails that I received during the day so I would have more time to work on the project when I got home.  Since my commute to campus is 1.5 hours just to get to campus (one direction), I had to learn how to make use of this time.

Project Management

I took up the role of “project manager” in the beginning of the project and this role showed me a lot of the logistics that had to be considered in a project.  Very often I found myself asking for progress on certain tasks and pushing teammates to finish faster.  Different issues often came to my head that I had to find an answer for such as “are our parts going to arrive in time for machining” or “do we need to have another meeting with the client”.

For Future 45X Students

Don’t wait until the last minute to do something.  There is always something that needs to be done in this course from beginning to end.  Mech students like to aim high, which is good, but 99% of the time there is not enough time to accomplish the “perfect” design that they always aim for.  This leads to a lot of sleepless nights or worse, a prototype that isn’t ready to be handed in.  Be ready to bite the bullet and make compromises like cutting features to make work less for the team and to meet deadlines.  No design will be “perfect” at the end of the course and this fact, however brutal it may be, must be accepted.

1.0 Motors

The chosen motors are:

• Finger grasping – Cytron IG32E-264K at a cost of USD $57.03 from RobotShop
• Finger sliding – Cytron MO-SPG-30E-20K at a cost of USD $22.58 from RobotShop

Both motors meet the torque speed requirements for this project.

1.1 Finger Grasping Actuation

From the initial budget, the budget set for actuators was set at $325.  The torque requirement needed for gripping was also calculated and each finger would require 4 Nm at its output to lift a 4 kg object using only the fingertips.  The evaluation criteria states that the device grasp as fast as possible and that the client would have the highest satisfaction if the device cost was less than $700.

Looking on several websites that sold motors, the following DC motor was chosen: Cytron IG32E-264K at a cost of USD $57.03 from RobotShop.  The specifications are as follows:

At 12 V with gearing included, the stall torque would be 20.7 Nm (without consideration of mechanical efficiency).  A motor with a high stall torque is also beneficial because it lowers the gear ratio required, which leads to the use of less space for gearing.  The motor also comes with its gearing, which contributes to its high torque.  Given the high stall torque of this motor addition gear reduction is not required.  During grasping, the motor will be exerting high torque at low speeds and therefore, the motor will be operating near the stall torque.  The torque here is more than sufficient even with mechanical efficiency losses accounted for.

For finger actuation before grasping occurs, there is a low load and therefore the motor will be operating closer to the no load speed.  The no load speed with gear reduction is 27.7 rpm (without consideration of mechanical efficiency).  Split among three output shafts, the speed would be 9.21 rpm.  Even with the load of the fingers accounted for, this is still acceptable. based on requirements and evaluation criteria.

While the torque is a lot higher than required, this motor was only more expensive than a motor of one size smaller by less than three dollars.  The electrical characteristics were also identical.  With a higher motor torque, the grasper would be comfortable in lifting objects even heavier than 4 kg, which is another benefit based on the evaluation criteria.

1.2 Finger Sliding Actuation

The motor required here does not require a large torque since motion in this degree of freedom is not expected to handle heavy loads.  This motor only requires enough torque to overcome the friction of the finger on the power screw that it is mounted on.  Therefore, a low-cost motor (relative to the grasping motor) will suffice.  The DC motor of choice is the Cytron MO-SPG-30E-20K at a cost of USD $22.58 from RobotShop.

The specifications are as follows:

The consistency of the stated specifications do not match the previous motor because the information that was provided by the manufacturer was not consistent.

An initial estimate of two 200 g fingers sliding on a 1/2” diameter power screw with a steel-steel sliding interface (friction coefficient of 0.8) shows that only 20 mNm of torque is required.  Therefore, this motor meets the requirement.  The power screw also has 13 threads per inch, and at the rated 185 rpm, the power screw would slide linearly at 6 mm/s.

1.3 Motor Type

DC and servo motors are motors that are suitable for the project.  An investigation between DC and servo motors showed that many manufacturers of motors did not provide the necessary specifications for choosing a servo motor in terms of the values of the no load, stall torque, and stall current.  While servos generate a lot of torque relative to their size when compared to DC motors, it is not feasible to use a servo motor because of the unknowns in the specifications.  It is possible to buy several servos and test them, but this is costly and time consuming.  At this stage in the project, the team is not able to commit the time to investigate further.

Comparison of the cost of the grasping motor relative to motors from Maxon Motor, a supplier of motors for UBC Thunderbots, shows that the price of a motor of the same power output costs approximately the same amount.  However, a fundamental difference is that the motor from Maxon does not include a gearbox, while the chosen motor for this project does.

2.0 Microcontroller

The microcontroller of choice is the Arduino Diecimila.  The primary motivator for using this board is because the UBC Thunderbots team already has this board and is currently unused.  The Thunderbots team has generously provided the board for use on this project.

The MCU will allow the turning the motors on and off, changing motor direction, changing motor speed, and reading encoder feedback.

3.0 Voltage Regulation for Encoders

Since the power supply is likely going to be run at 12 V, the encoders will require voltage regulation down to 5 V (the operating voltage of the encoder for the motors).  The chosen voltage regulator is the MC78L05A at a cost of USD from Digikey.  According to the typical application diagram of the datasheet, two capacitors will also be required (0.33 μF and 0.1 μF).  The cost of these are less than $1.

The voltage regulator will be wired up in this way as the datasheet shows:

The input will be from the 12 V source, and the output will be to the encoders.

4.0 Motor Driver

To control the motors, an H-Bridge is to be used.  However, due to the different current flows for each motor, one motor driver will require a high current capacity while the other one will not.  The high current capacity motor driver consists of a driving circuit using two half-bridges.  The low current capacity motor driver is made up of 1 IC.

4.1 Finger Grasping Motor Driver

To design the H-Bridge for controlling the motor, an L6205 motor driver will be used.  Each of them costs USD $11.36 from Digikey and can withstand a continuous current of 2.8 A and a peak current of 5.8 A and can be interfaced with the microcontroller with PWM inputs.  The driver can also be run in a parallel mode to double the current ratings by using both of its full bridges together.  The datasheet provides an application circuit as follows:

Output pins from the Arduino can turn the motor on and off through the enable pins.  Direction is controlled by adjusting the voltage polarity between IN1 and IN2.

There are also two output pins for current sensing.  By using it to measure the current draw, the microcontroller program can determine what the torque is through the use of the motor curves provided in the motor specifications.

4.2 Finger Sliding Motor Driver

The motor driver of choice is the L293D and each one costs $2.50 from Digikey.  Bidirectional control of a DC motor can be achieved by adapting the application circuit from the datasheet:

The 1A and 2A pins determine the direction of the motor or the motor deceleration.  A truth table is provided in the datasheet.

5.0 Power Supply

To power the grasper, a power supply plugged into the wall will be used.  It is expected that the future robot will have a power source of its own which will power the hand as well.  Therefore, for the purposes of testing the grasper for this project only a wall power supply will be required.

Looking at the maximum electrical power consumption of the two motors, the total comes to ~65 W (12 V * 5 A + 12 V * 0.41 A).  The other components also consume power and so the final power consumption will be higher.  To compensate, a 12 V power supply with a maximum wattage and current of 84 W and 7 A was selected.  The part number is CENB1090 and each costs USD $70.48 from Digikey.

6.0 Power Supply Connector

The power supply chosen has one port that uses a Molex Mini-Fit Jr. Receptacle.  Therefore, a proper receptacle must be used so that proper wire routing can power all the circuitry.  This also means that the future robot will also require a matching plug for this receptacle.

7.0 Fuses

Fuses will also be used as a redundant mechanism to stop the motor in case the current draw is too high.  The primary method of stopping the motor is through the current sense pins on the motor driver.

As one of the largest port cities in Europe, we got a chance to go to Hamburg to see its beauty.  We went there by car and saw much of the historical part of the city as well as took a ferry ride along the coast of the Elbe River and walked along the city’s canals.  The weather was pretty much raining for the whole time we were there.  As my friend put it, “when you go to Hamburg, plan for rain”.

The Drive

We left work at around noon to pick up our rental car.  It took us a bit longer than we expected because we had to go grocery shopping so we could have lunch and dinner in the car on the way there for our 6 hour drive (or so we thought).  The drive ended up taking 8 hours because of a stau (traffic jam).

The car we got from the rental company was a Mercedes-Benz C220.  When we got into the car, it smelled like new and being in such a new car for a road trip was undoubtedly awesome. We only got this car because it was the cheapest car with automatic transmission available.  I guess the Renault that we got last time was booked for today.  I wish that I got the chance to drive it though.

On the way there, we got to see a lot of the German countryside (as anyone typically does when going from one major city to another).  On the grass plains and knolls, we saw countless villages, farms, vineyards, and the like.  We even saw farms of wind turbines and solar panels.

After a few hours of driving, we stopped a few times.  We stopped at a rest area and at this middle-of-nowhere village.  The GPS guided us off the highway and into this village just to avoid the traffic jam.  For the first third of the trip, I sat in the front while three of my friends had to squish together in the back.  When it was my turn to sit in the back, I didn’t really feel the discomfort while I was reading on my friend’s Kindle.  I ended up going through about 90 pages of Band of Brothers.  Maybe the book was so interesting that I just completely zoned out of the real world for a little bit.

We reached our hostel at around 9 at night and parked the car.  After moving our stuff into our room, we began our sightseeing tour of Hamburg.

Reeperbahn

Our first destination was the Reeperbahn street.  Similar to Amsterdam, this area is one of the most famous red light districts in the world.  The whole area was full of sex shops, strip clubs, and brothels.  On the street corner, many women wearing fanny packs kept trying to approach tourists and we figured that these women were all prostitutes (that stuff is legal in Germany).

One of the more peculiar things was that there was a church that stood pretty much in the core of the whole area.  Really convenient for people to go to confess their sins I guess.

We meant to find a bar here for a drink, but pretty much all of the places reeked with pungent cigarette smoke or was way too loud.  Two of my biggest pet peeves in one place.  We ended up just going back to the hostel instead.

In order to keep up my “try-as-much-kinds-of-beer-as-possible mentality”, I tried a type of beer called Astra Urtyp.  It tasted horrible – too much of hops flavour.  Some of the others drank a few more beers and got tequila shots before heading out again.  As usual, I went to sleep.  The next morning, I found that they returned at around 5:30 in the morning.

The Rathaus

At around 11, on a cloudy day with a large and persistent ocean breeze (it was super cold even with my jacket on), we showed up at the meeting point for the walking tour – a Starbucks.  This tour company receives some sort of sponsorship from them.  Our tour guide, didn’t look like a German, and when he spoke, a clear Northern USA accent came about – apparently, he had been living in Germany for some time.  He led us to the first destination of the tour – the Rathaus (city hall).

Located by the Alster River, this rathaus replaced the old one that was destroyed in the fire of 1842.  This building looked quite similar in form to other city halls, like the one in Munich and Vienna, with a clock tower-like structure that extended directly above the main entrance.  Right above the gate of the main entrance, the Hamburgers proudly displayed their coat of arms that depicted the old fortress of Hammaburg (where the city got its name) that used to exist in the area before its destruction by the Vikings.  Once more this coat of arms was displayed on the clock tower of the rathaus, just beneath a large antiquated mechanical clock.  Statues of German Kaisers decorated the side of the building as each one stood in a line just beneath the rooftop.

In front of the building was a giant courtyard and during World War II, a bomb landed here, but didn’t explode.  If it had, the rathaus would have been badly damaged.  The bomb was defused and the timing mechanism removed from the bomb is now on display in the rathaus.  In the courtyard, the Hamburgers held the Stuttgart Wine Festival, which apparently coincided with the Hamburg Fish Market in Stuttgart.  Here, people set up tents selling South German cuisine – the kind of German food that I’m always used to eating. 

Along the Alster River stood a giant stone plaque engraved with a message saying that 40000 sons of the city gave their life for us all.  Everyday, people going to the rathaus are reminded of the tragedy that befell the country.  Beside it, swans, ducks and other birds frolicked about and went on with their day to day lives.

Buildings on the other side of the river formed a canal much like in Amsterdam.  Canals could be seen throughout much of the city and in fact, the city holds the world record for having the most amount of bridges.  At first I thought Amsterdam’s 900 bridges was a lot, but apparently Hamburg has around 2300.

St. Peter’s Church

Although, not so significant as a work of architecture, many believe this place to be the site of where the old Hammaburg fortress once existed.  When we stood at the entrance of this church, the tour guide said, “welcome to the highest point of Hamburg!”  I looked around and just saw a gentle slope and nothing more.  I guess Hamburg must not have any mountains! 

Besides being a church, this building once served as a stables for Napoleon’s forces.  Not long after the Napoleonic Wars, the church was destroyed in the fire of 1842.  Despite the fire, much of the art in the building was saved including the lion shaped door knocker – the oldest artifact in the city.  At the back of the church, vegetation grew along the brick walls over the years and not far beside it, a wooden sign stood with directions to various places for pilgrimages.

Expressionist Architecture

During the height of Hamburg’s power in sea trade, many firms set up offices in the city.  Many of these firms had buildings resembling the architecture style of the expressionists – elements of the building’s exterior would reflect the purpose of the building.  For example, in one of the accounting houses for sea trade, one could see elements of the building protruding from its side in the shape of a caravel or an anchor.

In another building, known as the Chilehaus, held the shape of a ship and above the front entrance, there were various objects representing the country of Chile.  Similarly, in the Afrikahaus, there was a giant statue of a tribesman wielding a spear and behind the statue on the gate, was a sculpture of a plant indigenous to Africa.

We also visited the Patriotische Gesellschaft (no idea what that is in English), but this building too had examples of the expressionist art.  Statues of caravels and Poseidon stood on the roof.

World War II Stuff

While on the tour, the guide pointed out a plaque on the side of a building and on it was information saying that the building was once the location of the firm that manufactured the Zyklon B gas that killed millions of people in the death camps.  This plaque used to be located at the main entrance of the building, but the building owners and people working there did not want a daily reminder of those atrocities.  To counteract this, they used a different entrance as the main one instead.

Another destination, the Church of Saint Nicholas was one of the many buildings destroyed during the instead bombing raids on Hamburg.  The church did not get a complete repair after the war, but instead it now stands as a memorial – another reminder of the devastation of World War II.

Deichstrasse

Located near a large network of canals, this area of the city is the oldest part of Hamburg.  Undoubtedly, this area was filled with old architecture and complete with the cobblestone roads that are so prevalent in Europe.  The building style also resembled a lot of 18th and 19th century architecture. 

There would have been more buildings in this area, but through several fires and bombings, much of it was destroyed.  In fact, one of the buildings here was where the fire of 1842 started.  It must have been reconstructed since then.

Speicherstadt

Literally translated, the title means a “city of warehouses”, which indeed is what the area was for – storing cargo.  Back in the day, this area used to be where the Hamburgers traded without having to deal with customs tariffs.

As the size of cargo ships got larger, these buildings began to be obsoleted as many of these cargo ships could not fit in the narrow city canals.

HafenCity

Probably the most modern part of the city, this district serves as a playground for architects.  Much of the buildings here don’t follow any sort of mainstream design ideas – lots of buildings here looked really bizarre.

One building to note though, is the concert house under construction.  It has the shape of ocean waves to represent the city’s rich history of sea trade.  Originally budgeted for 100 million euros, due to construction delays and other unfortunate events, the cost of the building is now nearing 500 million euros.

Before this area became popular, the city had trouble getting people to move here, so they rented out flats here for as low as 500 euros a month, but now people can’t rent a flat here for anything less than 3000 euros a month.

Shopping and Food

After our tour, some of my friends couldn’t stand the freezing ocean wind anymore and decided they had to go buy a hoodie.  The wind was so strong that the clouds weren’t just floating across anymore.  There was like a wind speed of about 20 km/h.  We walked around the old town and found an H&M.  I looked around inside and to my surprise, I found that the prices at this H&M seemed to be a lot higher than Stuttgart.  Otherwise, I most probably would have bought something there.

Later on, we went back to the old part of Hamburg for traditional Hamburg cuisine.  We entered a restaurant that had a theme of sailing.  The wall had on display some schematics and black and white photos of various types of ships.  The color scheme of the place even coincided with the stereotypical blue and white colour combination of sailors. We went to eat at around 3, so it was kind of empty at the time.

The food I tried here was Labskaus – a dish typically served in Northern Germany and according to Wiki, “the main ingredients are salted meat or corned beef, potatoes, and onion. Some – non-traditional – recipes put beetroot, pickled gherkin, or even herring into it.”  Mine was served with beetroot and pickled herring, which was typical of the Hamburg style.

Hamburg Hafen

After our meal, we went to the harbour for a ferry ride along the Elbe River.  The ferry drove along the coastline and gave us a really good view of the city.  We rode the ferry from HafenCity all the way to the beach near the Elbtunnel.  In addition to the city scape, we even saw a docked submarine and a cruise ship about to begin its journey.  The travellers on the ship happened to be doing their lifeboat safety drill as we passed by so the people on the two ships happily waved to each other.

The ocean wind we felt on the ship was so strong that I probably needed a winter coat to keep warm.  The wind even caused the waves to be strong enough such that water splashed onto the deck of the boat and onto everyone standing on it.

On the other side of the river, miles of cranes lined up the shore, ready to unload any cargo on ships that docked.  What we were seeing was the second largest port in Europe, the largest being the one in Rotterdam.

Bar District

Supposedly, this area is known as the bar district (at least that’s what we called it).  Despite its name though, there was a really tight concentration of bars here, but the cost of beer was even more than Stuttgart.

At the bar/restaurant, I ordered an apple strudel to help combat my hunger from walking around all day instead of going for beer like everyone else did (although I did have a little bit).  The apple strudel I got wasn’t that expensive and it looked and tasted amazing.

Fish Market

The next morning, we went to the fish market – Hamburg is famous for it.  However, we got there a little late, so by the time we got there, a lot of the places were closing down.  As a last ditch attempt to sell more stuff, a lot of shops there started giving people really good deals on food like selling a whole box of fruit for only 1 euro.  I would have bought it if I could eat all of that.  A pile of garbage behind all these people went to show how much food they sold that day.

Although the market by named says “fish”, people sold all sorts of things in addition to fish.  Many sold bread, cheese, and various types of meat.  I wondered if I’d see something similar to the wurst man I saw a while back, but I didn’t.

The market even had an indoor beer garden with a live band playing.  It was quite a nice place.  If only we were there early enough.

Driving Home

As I probably should have known, I could not resist the urge to drive.  I ended up taking the wheel for about half an hour and managed to get the Benz up to 200 km/h.  While driving at that speed though, the steering wheel was really shaky.  I felt that if the car ran over a pebble or something like that, the car would just plunge into the side of the road.  If it wasn’t for that, I would have reached the car’s top speed.

Before I started driving though, we stopped at a rest area.  When we took a good look at the back seat of the car and noticed a giant mess of crumbs from all our snacking during the trip.  I don’t think I had any to do with that since I never considered myself to be a messy eater.  Just as we finished commenting about the messiness of the car, one of my friends had apparently stepped on dog poop and got it in the car.  It smelled horrible.  He even got it onto another friend’s pants.  He cleaned it up right away, but a faint smell of the poop lingered in the car for the rest of the journey.  It’s a shame that the car rental company gave us a car smelling like new just so we’d give it back with a bad smell.

In another rest area near Frankfurt, we stopped for a bite to eat and went up to the observation tower there to look at the Frankfurt skyline.  That was a nice sight except for the giant high voltage line that blocked part of the view.  By then we were already pretty much 3/4 of the way home.  I continued reading Band of Brothers on the Kindle and managed to get through about 65% of the book in total.  We got back into Stuttgart at around 7:30 in the evening, returned the car, and went home.

More photos here

Generally, communication with serial ports involves these steps (in no particular order):

• Searching for serial ports
• Connecting to the serial port
• Starting the input output streams
• Adding an event listener to listen for incoming data
• Disconnecting from the serial port
• Sending Data
• Receiving Data

I wrote an example program that includes all of those steps in it and are each in their own separate method within the class, but first I will go through my hardware set up.

Hardware Setup

My current hardware setup is as follows:

• PC connected to an XBee
• Arduino connected to an XBee

User input is given from the PC through the a Java GUI that contains code for serial communication, which is the code presented here.

The Arduino is responsible for reading this data.  This set up is pretty much using my computer as a remote control for whatever device is on the Arduino end.  It could be a motor control, on-off switch, etc.

Existing Code

The purpose of this post is to discuss serial programming in Java, and not GUI’s.  However, I did create a GUI for testing purposes.  See the Code Downloads section for the actual files.

Above is the picture of the GUI complete with the buttons that I use to interact with the program.  I also added key bindings which I can use to control the throttle.

When the program is first started, none of the GUI elements will work except for the combo box and the connect button.  Once a successful connection is made the controls are enabled.  This is done through the use of the setConnected(true) and the toggleControls() methods shown in the example code that follows.

Imports

The imports i used for this program were as follows:

import gnu.io.*;
import java.awt.Color;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.TooManyListenersException;

Depending on the Java IDE it might already know to tell you to use these imports except for the first one.  That first import is specific to RXTX, and all its library methods/classes are in there.

Class Declaration

The code here reads:

public class Communicator implements SerialPortEventListener

I named my class Communicator, but the name is really up to the programmer.  The name pretty much reflects its intended use.

The class should also implement the SerialPortEventListener class.  This is a class in RXTX and is required in order to receive incoming data.

On some IDE’s this may generate a public void method called serialEvent().  This method will be defined later.

Class Variables and Constants

Below are the variables and constants that I defined in my class.  What the variables are for is in the comments but a more detailed explanation will follow.

    //passed from main GUI
    GUI window = null;

    //for containing the ports that will be found
    private Enumeration ports = null;
    //map the port names to CommPortIdentifiers
    private HashMap portMap = new HashMap();

    //this is the object that contains the opened port
    private CommPortIdentifier selectedPortIdentifier = null;

I could have easily put the variable definitions in the constructor but it wouldn’t change anything.

The GUI object is another class that I wrote separate from this one that contains all the GUI elements.  The GUI class extends javax.swing.JFrame.

The HashMap is for mapping each of the ports’ names to the actual object. What that means is that I can associate (put() method) the name of a serial port, say a string that says COM1, to an object in the code.  Later, I can access the name COM1 from the HashMap by using the get() method and it will return the object that it was associated with previously.

The CommPortIdentifiers object is needed to gather the list of ports that are available for connection. by using its getPortIdentifiers() method.

The SerialPort object is for storing the data for the port once a successful connection is made.

The InputStream and OutputStream is the object that is required for sending and receiving data.

The Boolean variable bConnected is just a flag that I use for enabling and disabling elements on the GUI.

The constant TIMEOUT is a number required when opening the port so that it knows how long to try for before stopping.

The constants for the ASCII values are some values that I use to send through the output stream that act as delimiters for data.

The string logText is basically what the comment says.  When stuff happens in the program, the program stores a string in this variable and it will be appended to a text area in the GUI.

Searching for Available Serial Ports

The method below is for searching for available serial ports on the computer.  Code adapted from Discovering Available Comm Ports from the Reference Material.

    //search for all the serial ports
    //pre style="font-size: 11px;": none
    //post: adds all the found ports to a combo box on the GUI
    void searchForPorts()
    {
        ports = CommPortIdentifier.getPortIdentifiers();

        <span style="color: blue;">while (ports.hasMoreElements())
        {
            CommPortIdentifier curPort = (CommPortIdentifier)ports.nextElement();

            //get only serial ports
            <span style="color: blue;">if (curPort.getPortType() == CommPortIdentifier.PORT_SERIAL)
            {
                window.cboxPorts.addItem(curPort.getName());
                portMap.put(curPort.getName(), curPort);
            }
        }
    }

The method getPortIdentifiers() returns an Enumeration of all the comm ports on the computer.  The code can iterate through each element inside the Enumeration and determine whether or not it is a serial port.  The method getPortType() can identify what kind of port it is.  If it is a serial port, then the code will add its name to a combo box in the GUI (so that users can pick what port to connect to).  The serial port that is found should also be mapped to the HashMap so we can identify the object later.  This is helpful because the names listed in the combo box are the actual names of the object (COM1, COM2, etc), and so we can use these names to identify the actual object they are tied to.

Connecting to the Serial Port

The method below is for connecting to the serial port once they have been found (see previous section).  See How to Open A Serial Port in the Reference Material for more information.

    //connect to the selected port in the combo box
    //ports are already found by using the searchForPorts
    //method
    //post: the connected comm port is stored in commPort, otherwise,
    //an exception is generated
    public void connect()
    {
        String selectedPort = (String)window.cboxPorts.getSelectedItem();
        selectedPortIdentifier = (CommPortIdentifier)portMap.get(selectedPort);

        CommPort commPort = null;

        try
        {
            //the method below returns an object of type CommPort
            commPort = selectedPortIdentifier.open("TigerControlPanel", TIMEOUT);
            //the CommPort object can be casted to a SerialPort object
            serialPort = (SerialPort)commPort;

            //for controlling GUI elements
            setConnected(true);

            //logging
            logText = selectedPort + " opened successfully.";
            window.txtLog.setForeground(Color.black);
            window.txtLog.append(logText + "n");

            //CODE ON SETTING BAUD RATE ETC OMITTED
            //XBEE PAIR ASSUMED TO HAVE SAME SETTINGS ALREADY

            //enables the controls on the GUI if a successful connection is made
            window.keybindingController.toggleControls();
        }
        catch (PortInUseException e)
        {
            logText = selectedPort + " is in use. (" + e.toString() + ")";

            window.txtLog.setForeground(Color.RED);
            window.txtLog.append(logText + "n");
        }
        catch (Exception e)
        {
            logText = "Failed to open " + selectedPort + "(" + e.toString() + ")";
            window.txtLog.append(logText + "n");
            window.txtLog.setForeground(Color.RED);
        }
    }

Using the HashMap we can retrieve the CommPortIdentifier object from the string that was mapped earlier.  This is achieved through the HashMap’s get() method.  The object must also be casted as a CommPortIdentifier because the get() method has a return type of Object.

The setConnected method just changes a boolean flag so that the program can store whether or not it is connected to a serial port or not.

The CommPort must also be initialized because the port object will be stored here once a successful connection is made.

The main method of interest here is the open() method.  This instructs the program to open the port, and this method will return the object for the opened port, which I store in in the previously initialized CommPort object.  I then cast this object as a SerialPort and store it as well.  This is helpful for accessing the methods and variables specific to the SerialPort class.

It should also be noted that the open() method requires the use of a try-catch block.  So applying that, I catch two different exceptions.  The PortInUseException is what the name says.  If the port is in use, then this exception is thrown.  The next catch block is just for the generic exceptions that occur.  I never came across that during testing, nor do I know how to replicate that.

I neglected to include any code for setting the baud rate and other settings on the XBee’s (see Hardware Configuration), because I already set those parameters previously using X-CTU (more on setting up XBee’s here).

Initializing the Input and Output Streams

This method is pretty short and is pretty straightforward to read.

    //open the input and output streams
    //pre style="font-size: 11px;": an open port
    //post: initialized input and output streams for use to communicate data
    public boolean initIOStream()
    {
        //return value for whether opening the streams is successful or not
        boolean successful = false;

        try {
            //
            input = serialPort.getInputStream();
            output = serialPort.getOutputStream();
            writeData(0, 0);

            successful = true;
            return successful;
        }
        catch (IOException e) {
            logText = "I/O Streams failed to open. (" + e.toString() + ")";
            window.txtLog.setForeground(Color.red);
            window.txtLog.append(logText + "n");
            return successful;
        }
    }

The streams are initialized by returning the input and output streams of the open serial port.  In order for the serial port object to not be null, it must store the object for the open serial port.

The getInputStream() and getOutputStream() methods both require a try-catch block.  The important exception to catch here is the IOException to signify whether the streams failed to open or not.  For more information see How to Open A Serial Port in the Reference Material.

I also call a method called writeData(0, 0).  This is the method that encapsulates the code required to write serial data.  More on that later.  Right now it is just used to set variables on the microcontroller side to zero.

Setting Up Event Listeners to Read Data

Once the port is open, the serial port must know whenever there is data to be read.  This approach is event driven rather than by polling.  When the event is hit, a special block of code will run.  This is advantageous to polling because polling requires constantly asking if data is available.  The code for the event driven approach is below.  See Event Based Two Way Communication for more information.

    //starts the event listener that knows whenever data is available to be read
    //pre style="font-size: 11px;": an open serial port
    //post: an event listener for the serial port that knows when data is received
    public void initListener()
    {
        try
        {
            serialPort.addEventListener(this);
            serialPort.notifyOnDataAvailable(true);
        }
        catch (TooManyListenersException e)
        {
            logText = "Too many listeners. (" + e.toString() + ")";
            window.txtLog.setForeground(Color.red);
            window.txtLog.append(logText + "n");
        }
    }

The code here is pretty much the whole reason why this class implements SerialPortEventListener.  The parameter for adding the event listener is just the object itself.  The base class has a method called serialEvent(event) that should be overridden before the event code will work.  Overriding that method defines what happens when the event is hit.

The method addEventListener(this) is the event that is always checking for SerialEvents.  It isn’t really important to know what the events actually are, just that the one we’re interested in is the one that tells us whenever data is received.  Adding the event listener is complemented by the method notifyOnDataAvailable(true), which definitely helps us achieve what I mentioned previously.

This code requires a try-catch box.  The exception here is that there may be too many event listeners.  I only use one in the code, so this exception should never be hit.

Disconnecting from the Serial Port

Once all the communication is completed, the serial port must be disconnected.  In some instances, some ports stay stuck open, which isn’t exactly a good thing.

    //disconnect the serial port
    //pre style="font-size: 11px;": an open serial port
    //post: closed serial port
    public void disconnect()
    {
        //close the serial port
        try
        {
            writeData(0, 0);

            serialPort.removeEventListener();
            serialPort.close();
            input.close();
            output.close();
            setConnected(false);
            window.keybindingController.toggleControls();

            logText = "Disconnected.";
            window.txtLog.setForeground(Color.red);
            window.txtLog.append(logText + "n");
        }
        catch (Exception e)
        {
            logText = "Failed to close " + serialPort.getName()
                              + "(" + e.toString() + ")";
            window.txtLog.setForeground(Color.red);
            window.txtLog.append(logText + "n");
        }
    }

The code here requires a try-catch block so there it is.  The exception to catch here is pretty generic.

Before closing the port, I reset the data on the microcontroller.  That step is optional depending on the application.  For example, if the value sent to the microcontroller is controlling the speed of a motor, I’d want the motor to turn off if I turn off the remote control.

The event listener should be removed as it is no longer needed.

The method to close the port is the close() method.

The input and output streams should also be closed via the same method as above.

See How to Close A Serial Port in the Reference section for more information.

Reading Data – The serialEvent Method

This is a follow-up to the section on preparing to Read Data.  It has information on how to process the data that the program reads.

    //what happens when data is received
    //pre style="font-size: 11px;": serial event is triggered
    //post: processing on the data it reads
    public void serialEvent(SerialPortEvent evt) {
        if (evt.getEventType() == SerialPortEvent.DATA_AVAILABLE)
        {
            try
            {
                byte singleData = (byte)input.read();

                if (singleData != NEW_LINE_ASCII)
                {
                    logText = new String(new byte[] {singleData});
                    window.txtLog.append(logText);
                }
                else
                {
                    window.txtLog.append("n");
                }
            }
            catch (Exception e)
            {
                logText = "Failed to read data. (" + e.toString() + ")";
                window.txtLog.setForeground(Color.red);
                window.txtLog.append(logText + "n");
            }
        }
    }

Since we only want to read data if it exists, we test the condition in the if statement above.  This could be redundant because we wouldn’t be in this method if the event never got triggered.

Reading the data requires a try-catch block.  The read() method returns an integer, but the value in it is actually a byte value so this is casted to a byte, in which I store in a variable called singleData.  When I was testing this code before, I noticed that the data being read would always have random new line characters in it, and I never knew why this happened.  I never wrote any new line characters.  Since I don’t want these, I add an if condition saying that if it encounters that, don’t display that data on the screen.

Java also has a nice way of converting bytes to a string.  A byte array can be used as a parameter when initializing a string, which is what I’ve done when I assign a value to logText.

The exception here is just the usual generic one.

Writing Data

Here is the method for writing data.  In my application, I am writing two integers sequentially to my microcontroller.  Data that is sent to the MCU can be used for such things such as controlling motor speeds, which is what I am trying to do here.  I hope to use the data sent do control the PWM duty cycle of the motor for speed control.

    //method that can be called to send data
    //pre style="font-size: 11px;": open serial port
    //post: data sent to the other device
    public void writeData(int leftThrottle, int rightThrottle)
    {
        try
        {
            output.write(leftThrottle);
            output.flush();
            //this is a delimiter for the data
            output.write(DASH_ASCII);
            output.flush();

            output.write(rightThrottle);
            output.flush();
            //will be read as a byte so it is a space key
            output.write(SPACE_ASCII);
            output.flush();
        }
        catch (Exception e)
        {
            logText = "Failed to write data. (" + e.toString() + ")";
            window.txtLog.setForeground(Color.red);
            window.txtLog.append(logText + "n");
        }
    }

The write() method here requires a try-catch block just like many of the other methods used for serial communication.  Using the output stream, I call that method to write an integer value.  I also write a dash and a space to separate the actual data being read.  See the ASCII Table for the values of what these characters should be.  This helps me differentiate the sets of data that is sent back and forth.  The dash separates the two integers being sent and the space separates the entire set.  On the Arduino end, four called to read() can separate the data without mixing things up.  Example of that later.

Putting All the Java Code Together

Once all these methods are setup, they need to be called somewhere in the program so we can put them to use.  When the program starts, the code for searching for serial ports will run so that it can populate the combo box on the GUI.  The GUI buttons also need to be disabled to reflect the fact they should be disabled when there is no connection to a port.  When the connect button is pressed, the input and output streams are started and the event listener is added.  The code for that is shown below.

        private void btnConnectActionPerformed(java.awt.event.ActionEvent evt) {
            communicator.connect();
            if (communicator.getConnected() == true)
            {
                if (communicator.initIOStream() == true)
                {
                    communicator.initListener();
                }
            }
        }

The if statement is needed such that the code will not run if a successful connection was not made.  This is the precondition for the initIOStream() and the initLIstener() methods.

When the user decides to disconnect from the serial port, the user only needs to call the disconnect() method when the disconnect button is pressed.

The up/down arrows on my GUI are set to write data to the serial port when they are pressed.  When data is written to the Arduino, the MCU will send the data back to the Java program, which will signal the event listener to display that data back to the screen.

Arduino Code

The Arduino code is pretty straight forward.  There are just a few calls to the read() method.

Update 6 May 2012: the syntax for the Arduino code has updated since the writing of this article.  Apparently, the lines

Serial.print(separator, BYTE);
Serial.print(space, BYTE);

are no longer valid and have since been replaced by the following:

Serial.write(byte(separator));
Serial.write(byte(space));

The code below hasn’t been edited with this change, but basically the code required for writing a byte value through serial communication has changed.

// this is where we will put our data
int left = 0;
int right = 0;
byte space = 0;
byte separator = 0;

void setup(){
  // Start up our serial port, we configured our XBEE devices for 38400 bps. 
  Serial.begin(9200);
}

void loop(){
  // handle serial data, if any
  if (Serial.available() >= 4){
    left = Serial.read();
    separator = Serial.read();
    right = Serial.read();
    space = Serial.read();
    Serial.flush();

    Serial.print(left);
    Serial.print(separator, BYTE);
    Serial.print(right);
    Serial.print(space, BYTE);
    Serial.print("n");
  }
}

I first declare four variables to reflect the fact that I’m writing four different variables to the serial port.

In the loop method, I added a condition which will check whether there are four pieces of data available before reading them.  This again reflects the fact I’m writing four values.

The four variables initially declared store the values in the order that they are written, and then are just printed to the screen.

The print() method is able to convert the byte value to an actual character by adding a second parameter called BYTE.  The left and right variables don’t need it because the values written were integers to begin with, however, the dash and space characters were written as ASCII values.

For more information about Arduino and Java, and Arduino’s Serial library, please refer to those in the Reference Section.

Code Downloads

Here are the code downloads for the GUI, key bindings and the serial communication.  WordPress doesn’t allow uploads of zip or java files so I uploaded it all to Megaupload.

Link to download: http://www.mediafire.com/?z2l26ncypmzn20z

Other Examples

There are also other sites I looked at which had example code for serial port communication in Java.  The sites are Programming Serial and Parallel Ports and Serial Port Access Using RXTX in Java, which are both in the Reference section.

Reference Material

Below are a bunch of links to reference sites that I used to find some of the information written here.  I mostly referred to bits and pieces of each article to understand the serial code and to come up with the example I present here.  The list is in the order that I referenced them.

Discovering Available Comm Ports

http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports

The code on this page is pretty specific to the title of this heading, and the code is pretty easy to follow.

How to Open A Serial Port

http://embeddedfreak.wordpress.com/2008/08/08/how-to-open-serial-port-using-rxtx/

This page provides a very concise and detailed explanation on what each line of code does in order to get a serial port open.  Definitely work a look if you’re trying to understand the code.

Event Based Two Way Communication

http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication

This page has example code on how to connect to a serial port and how to interact with it.  The code here uses events, rather than polling, to send data back and forth, which means that whenever data is received, the event code is triggered.

How to Close A Serial Port

http://embeddedfreak.wordpress.com/2008/08/08/how-to-close-serial-port-in-rxtx/

This article is written by the same author who wrote the article on how to open serial ports.  Good example code here.

ASCII Table

http://www.asciitable.com/

Having the ASCII Table is quite handy for serial data because data being sent and written are bytes, so being able to know what byte values correspond to what character really helps.

Arduino and Java

http://www.arduino.cc/playground/Interfacing/Java

This article discusses how to use the serial port communication with Java and Arduino, which is exactly what I am after.  It has example code on pretty much the entire process of serial port communication, but it may be too much to read since there is little explanation about the code.

Arduino Serial Class

http://arduino.cc/en/Reference/Serial

A good reference for Arduino’s Serial class methods.  Also has example code to look at.

Programming Serial and Parallel Ports

This article provides a brief introduction to programming serial ports and has information on the steps required to talk to the serial port.  However, the code examples in there may be hard to follow for someone new to serial programming.

Serial Port Access Using RXTX in Java

http://gomultidomain.blogspot.com/2008/06/serial-port-access-using-rxtx-in-java.html

This page also has complete code for serial communication in Java, but what I was looking for here was how to use the write method to send serial data from Java.