1. Install Docker on your machine
2. Get a Docker image for a CS 1.6 server (I created this one, which is based off of an existing one. Mine has:
   • A lot of maps
   • Metamod
   • AMXModX (with high ping kicker, podbot control menu, round money, rock the vote, and admin all in one)
   • Podbot
3. Customise the server (e.g. editing the server.cfg, amxx.cfg, and other config files, etc.)
4. Start it up! (the README.md in the above linked Git repos has more info on this)

As far as ports go, I only needed to forward 27015 on my machine, but your mileage may vary. Others have reported that some more ports must also be forwarded on some machines.

Then optionally, if you’re running Ubuntu and you want this server to start up like a service via systemd, you’ll need this:

1. An executable script with path /usr/local/bin/hlds with contents (make sure the DIR variable matches your installation directory):

#!/bin/sh

# Do not change this path
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin

# The path to the game you want to host. example = /home/newuser/dod
DIR=/opt/cs-16-server/bin
DAEMON=./server

start()
{
    echo  -n "Starting HLDS"
    if [ -e $DIR ]; then
        cd $DIR
        $DAEMON start
    else
        echo "No such directory: $DIR!"
    fi
}

stop()
{
    echo -n "Stopping HLDS"
    if [ -e $DIR ]; then
        cd $DIR
        $DAEMON stop
    else
        echo "No such directory: $DIR!"
    fi
}

reload()
{
    echo -n "Restarting HLDS"
    stop
    sleep 1
    start
}

case "$1" in
    start|stop|reload)
        "$1"
        ;;
    *)
        echo  "Usage: $ 0 {start | stop | reload | status}"
        exit  1
        ;;
esac

exit  0

2. A script with path /etc/systemd/system/hlds.service with contents:

[Unit]
Description=HLDS

[Service]
Type=oneshot
ExecStart=/usr/local/bin/hlds start
ExecStop=/usr/local/bin/hlds stop
ExecReload=/usr/local/bin/hlds reload
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

3. Then execute:

systemctl daemon-reload
systemctl enable hlds
service hlds start

Feel free to check out my server that’s running right now with the same Docker image! Here’s the command to connect via the console.

connect henrypoon.com:27015

The museum focussed on German tank developments since the beginning: World War I. Definitely an awesome museum. I’d recommend it for anyone interested in the subject.

During the interwar period and World War II, the Germans took the tank concept and built it into a very effective war machine. This museum is paradise for tank nerds like me.

This museum is also paradise for mechanical engineers too. Here is an interactive exhibit on the tank’s transmission. Yanking on the lever let you shift gears and one can see how the gears move around through the clear covering. Definitely real cool for people who are into that sort of stuff.

There are lots of tanks here. This is only one of the many rooms.

There’s also an exhibit showing how kids learn how to play war at a young age and it questions the morality whether or not this is okay. Ironically, when we were there, a group of children were going through the whole museum screaming about how the stuff in the museum was the coolest stuff ever.

Right behind that, was an exhibit of guns and how humans engineered death.

The exhibit on how armour piercing rounds work was especially cool.

And also the cool cross-sections.

What’s a tank musum if you can’t actually go inside one?

And of course, one can’t look at tanks without thinking of margaritas and Katy Perry…

After visiting the museum, we stopped in Hamburg to grab a bite to eat. We ate at this restaurant with a mysterious set menu where we knew neither the price nor what we would be served. We ended up eating different kinds of seafood over a few courses (swordfish, among them!), and it was ~40 euros!

Link to photo album: here

I already have Ubuntu as my main OS, so copying the disk was easy using dd, which allows copying all the contents of one disk to another. This works well when the new hard drive is greater than or the same size as the current hard drive (I upgraded from a 80GB HDD to a 128GB SSD).

First I run this to see which disk I am copying from and to

fdisk -l

Then I run dd. If I am copying from /dev/sda to /dev/sda, then it’s:

dd if=/dev/sda of=/dev/sdb

But sometimes the disks don’t have the same size, so I used gparted to move/resize the partitions to make use of the extra space on the new disk. gparted complained that it might make my disk no bootable, but the disk was still bootable for me nonetheless. I didn’t even have to mess with any grub bootloader settings either. I simply unplugged the old disk, and left the new disk plugged in and booted into the new disk no problem.

In a computer, there are various methods of storing information.  Information can be stored in the processor cache, RAM, hard disk, etc.  It can be faster to request information from a storage medium that is smaller.  However, this smaller storage medium cannot fit all the possible information that can be requested.  So the idea is to insert a portion of the data into the faster, smaller medium (the cache) and the rest into the slower, larger medium (main memory).

If a request is made and the data is not available in the faster, smaller medium first, then the data will be read from the slower, larger medium – this is what is known as a cache miss.

Given that all the data cannot possibly live in the cache, there must be a way to minimize the amount of times that the data must be read from the main memory.

Optimal Caching – Farthest-in-Future

The Algorithm

The idea is that there is an algorithm that minimizes the amount of cache misses that occur for a set of requests.  The Farthest-in-Future Algorithm evicts the item in the cache that is not requested until the farthest in the future.  For example, given the following cache with items “a” through “f”.

It is clear that “g” does not exist in the set of cache items and so when “g” is requested, a cache miss will result. An item will be evicted because “g” is not in the cache.  According to the Farthest-in-Future Algorithm, element “f” will be evicted since it is the one that will be used furthest in the future.

Definitions

Cache Miss – Occurs when it is necessary to bring in an item from the main memory into the cache

Schedule – A list that contains, for each, request, which item is brought into the cache, and which item is evicted

Reduced Schedule – a schedule that only brings in an item when there is a request for that item – so a non-reduced schedule would bring an item into the cache outside of a request for that item

Theorem

To be shown:

Farthest-in-Future is the optimal algorithm that minimizes the number of cache misses.

To prove this, let’s say there is a schedule SFF that follows the Farthest-in-Future Algorithm and that there is a schedule optimal S that has a minimum number of cache misses. It can be shown that it is possible to transform S into SFF by performing a series of evictions without increasing the number of cache misses.  Since S^* is already optimal, and the number of cache misses did not increase, then SFF must be optimal.

To perform one transformation, the statement below can be used.  Right now, it isn’t all that clear why this is necessary, but it should become clearer further on.

Let S be a reduced schedule that is the same as SFF for the first j requests, then there is a reduced schedule S’ that is the same as SFF for the first j+1 requests, and incurs no more misses than S

Proof

Let’s say the cache at the start looks like this.  S and SFF have the exact same contents (this is what was defined in the previous section).

Given a schedule S, it can be shown that any request can be made, and the resulting schedule would be equal to the ideal algorithm and does not increase the number of cache misses.  Essentially, we want S = S’ = SFF after a request is made and that the number of cache misses have not increased.  If this can be shown for all different scenarios that items are requested, then Farthest-in-Future is the ideal algorithm.

Case 1: Item Is Already in the Cache

Now let’s say the next item to be requested is item “d”.  It is clear that this item exists in both caches and no evictions are necessary.  Since no evictions are necessary, SFF does not change.  It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S.

Here, S = S’ because no changes had to be made to the cache and there were no cache misses.  After the request for item “d”, S = S’, each with zero cache misses, which is a valid outcome.

Case 2: Item Is Not in the Cache, S and SFF Evict the Same Item

Let’s say the next item to be requested is item “e”.  Neither cache has this item, so an eviction will have to be made.  Let’s also say SFF and S both choose to evict item “a” to make room for “e”.  It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S.

Here S = S’ because S and SFF both evicted the same item.  Both S and S’ each have one cache miss (no increase relative to one another), which is a valid outcome.

Case 3: Item Is Not in the Cache, S and SFF Each Evict A Different Item

This is where the proof can become more confusing (as if it isn’t already).  Let’s say the next item to be requested is “e”.  Let’s also say that the ideal algorithm, SFF, evicts “a” and S evicts “b”. It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S. This means that in order to get S’ = SFF, S’ should evict “a” in order to match with SFF.

Here, S does not agree with S’ = SFF.  Essentially, these two schedules behave the same, so long as future requests do not request items “a” or “b”.  This shows that there is a schedule S’ that equals SFF, but it is not known whether or not S’ has no more cache misses than S, since “a” or “b” can be requested in the future, which can determine whether S or S’ has more cache misses.  From this point onward, S and S’ behave the same until one of the following happens:

Case 3a: Item Is in SFF, But Not S; S Evicts “a”

Let’s say eventually item “b” gets requested.  In this case, S’ and SFF do not need to change.  All S has to do is evict “a” to make room for “b”.  In this case, S has two total cache misses (from request “e” and “b”), while SFF and S’ each have only one cache miss, thus fulfilling the cache miss requirement.

Case 3b: Item Is Neither in SFF Nor S

Let’s say eventually item “f” gets requested.  S’, SFF, and S all need to make an eviction. S’ and SFF can evict “b” to make room for “f”, and S can evict “a” to make room for “f”.  In this case, each schedule as two cache misses, thus fulfilling the cache miss requirement.

Case 3c: Item Is in SFF, But Not S; S Evicts Item Not Equal to “a”

Let’s say eventually item “b” gets requested and S evicts an item that isn’t “a”, say “c”.  Now, SFF and S’ both already have “b” in the cache.  In order to synchronize S and S’ to make them comparable to see how many cache misses each have, S’ and SFF will evict “c” to make room for “a”.

Since “a” is being brought into the cache without a request for “a”, this makes S’ and SFF no longer a reduced schedule.  However, the proof calls for S’ and SFF being a reduced schedule.  Fortunately, it is possible to transform an unreduced schedule into a reduced one.  In this case, each schedule has two cache misses, thus fulfilling the cache miss requirement.

Case 3d: Item Is Not in SFF, But in S

The only item that is in S and not SFF is item “a”.  SFF had evicted it initially at the beginning of Case 3.  Since SFF had evicted it, it must have been the item that would be requested furthest into the future.  Therefore, it is not possible for item “a” to be requested before other items.

After going through all possible eviction decisions that the schedules can do, it was shown that for each scenario, there was indeed a schedule S’ = SFF, where the cache misses incurred in S’ no more than S.

We had spent a whole year upgrading everything.  I designed a new ball kicking system that was more durable, more maintenance free, and more powerful than the year before.  The other mechanical systems were more robust as well.  The electrical system also had a huge upgrade.  Burning and smoking electrical boards were a thing of the past!  We have never had a design this robust – ever!

What is RoboCup?

For those who don’t know what RoboCup is, RoboCup is an international robotics competition aimed to further robotics research.  Their long-term goal is to have robots beat the World Cup Soccer team winners by 2050. There are various leagues within RoboCup, such as in robotic soccer (where we participate), home care, rescue, simulation, etc.  Our team, the UBC Thunderbots, compete in the small-size soccer league, which is probably has the fastest game play of all the different leagues.  The robots are generally cylinders with a diameter of about 18 cm and a height of 15 cm.  They can move at around 4 m/s and kick a golf ball at 8 m/s.

One of the other leagues, the Standard Platform League competes with standardized robots for all teams and the key difference between each is the software that is written for the robots.

Another league, the mid-size league in RoboCup Soccer competes with robots that are about a 1/3 of the size of a person. The game isn’t as quick as the small-size league game and they play with a real soccer ball instead of a golf ball. During the competition, it gathered quite the crowd too.

Preparing for the Games

Most teams arrived at the venue when it opened to get to work right away. Everybody wanted their robots in tip-top shape. Our team did the same. Even though our robots were ready mechanically and electrically, the key game changer was seeing which team had better artificial intelligence for their robots. Whenever got time to test on the field, we took advantage of it to make sure our AI was working well too.

Round Robin

In the round robin stage, each team gets four games against other teams in their bracket. Each bracket is made up of five teams and the skill level is spread out based on the rankings of the previous year.

We lost our first two games against a team called KIKS from the Toyota National College of Technology in Japan, and a team called STOx’s from the Universidad Santo Tomás in Colombia. In both of those games, we were simply outplayed because the other team had better software than we did. At the end of the game against the Japanese team, I spoke a bit of my horrible Japanese to them and they were super surprised and impressed that I knew a bit of Japanese!

Because our robots were finished not long before the competition began, the software team did not get a chance to test the code that was written, and so we found out the problems during the competition. Our robots were never able to drive up to a ball and take possession of it. The robots somehow always missed the ball. When the robot had the ball, it didn’t know what to do with it. It sat there holding onto the ball doing nothing. This was so frustrating for our team and even more so for the software team who wished they had more time to test.

We won our next two games against two lower tier teams. One is called RoboFEI, from the Centro Universitário da FEI in Brazil, and a team called RFC Cambridge from Harvard and MIT. It’s nice to be able to say that we beat a team from these two ivy league schools. Looks good when we look for sponsors too!

Lucky Loser Round

Because we had a 2-2 record during the group stage, we played a fifth game, the so-called Lucky Loser Round, to see if we could qualify for the quarter finals. Our match up was against a team called ODENS from the Osaka Electro-Communication University in Japan.  The game was so close that there was a dispute about the rules and whether what our team did was legitimate. Because our robots were not able to move up to a ball and shoot it at the net during the shootout, the referee introduced a workaround that the other team disputed.

Our referee’s native tongue was Portuguese, we spoke English, and the other team spoke Japanese. I didn’t know enough Japanese to translate. Eventually, members from other teams like the Thai and Chinese team came to help with the dispute. During the discussion that took about an hour, I heard people speak English, Japanese, Portuguese, Thai, Japanese, and Mandarin all at the same time. It seemed like nobody had the full picture of what was happening and how to resolve it.

The dispute was resolved when both teams agreed to a specific workaround that made it possible for our robots to do shootouts.  The game ended with a shootout and we lost on the very last shot of the shootout unfortunately. We almost made it to 8th place.  Still, achieving 9th place out of 22 teams was the best that the team has ever done before.

The Competition Ends

Skuba, from Kasetsart University in Thailand, had won the competition for four years in a row since 2009, but this year they had a surprising finish that was not even the top 4.  The second place team, ZJUNlict from Zhejiang University in China had beat them early in the quarterfinals.  ZJUNlict’s strongest opponent this year was CMDragons, from Carnegie Mellon University in USA.  In the final round, they were tied for the entire game and the game went to shootouts where CMDragons lost by one goal.  ZJUNlict had made first place in the RoboCup 2013 in the Small Size League.

As the competition came to a close, we said goodbye to the people on other teams that we met and as a parting gift from the German team ER-Force, they gave us a German flag with the names of all their team members signed onto it, with the message, “for our amazing friends, the Thunderbots, from team ER-Force”.

I realized now that the competition is over, I probably wouldn’t be going to competitions in the future because I’ve graduated from university. It made me feel a little bit sad that I couldn’t compete anymore, but at least I can still help out the team wherever they need it.

Link to photo album here

This gave us a lot of opportunities to find out what was wrong with our robots before the real competition began. We found out that are mechanical and electrical systems were quite robust, while our software system was the weakest link of the three.

In the downtime, we were taken on a tour of the nearby Eichbaum Brewery. The tour was quite difficult to follow because it was pretty much all in German. Even though I had learned some German, it was still quite difficult for me to follow.

I had been to Mannheim before and both times I went to Mannheim before this time, I had a very negative experience. The first time, I got food poisoning (I still remember which restaurant it was), and the second time, my friends and I waited at the Mannheim train station for 4 hours for a train to Berlin with a scheduled departure time of 12am.

Having had lived in Germany before meant I recognized a lot of brands like food chains, department stores, cell phone companies, etc. Because of that, my teammates often asked me different things about Germany such as how German phone plans worked and how to sign up for a plan. I explained it to them and even asked the cashier at the supermarket who didn’t speak English about phone plans.

On another day, we were also taken on a tour to the nearby city of Heidelberg. I had also been here before and vaguely knew my way around. We hiked up to the castle again, but we were there in the evening so the inside of the castle was closed by the time we arrived, so we just went as high as we could.

After spending a few days in Mannheim, all three of the teams organized transportation together to Eindhoven, where the real competition would begin. The workshop allowed us to see what our robots were capable of and what we could improve on early, so that we would be better prepared for the real thing.

Link to photo album 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

This guide presents how to mimic the system used in professional karaoke establishments at home.  The software this system uses revolves around a Taiwanese program called JetKTV.  Much of the content from this guide was drawn from Chinese language websites discussing the usage of this program (scroll all the way down for References).    There is little literature on this subject in English and so this guide presents basically an English version of the reference sites plus a few added notes.

The program used is in Chinese, so people who are not fluent in Chinese may have a hard time navigating through the software.  Those who are brave enough to continue or have a basic knowledge of Chinese with better English fluency may find it helpful to see English instructions.  The Chinese sites on this subject are also written for older versions, and the setup procedure for those older versions are slightly different.

Contents

• Proposed Setup
• Setting Up JetKTV2010
• Inserting A New Song
• Inserting A New Artist
• Testing
• References

Proposed Setup

The proposed setup of all the hardware (TV’s, amps, computer, etc.) is in the diagram below.

The computer will play the chosen Karaoke videos and transmit the video signal to the TV (via extended display like in a dual monitor set up).  The computer’s audio will go to an amplifier or a mixer, which is then transmitted to a set of speakers.  Microphones are plugged into the amplifier/mixer is well so that the speakers can also play the sound picked up by the microphones.  Depending on the hardware, the cables could be different (some TV’s may not have HD output etc.)The  computer is the source of all the signals transmitted to the other devices and must be set up with the Karaoke software.

Setting up JetKTV2010

The PC will use the following software:

• JetKTV2010 (link)
• SongMgr (optional – not helpful on English language PC’s – more on that topic later)

It is helpful to set up the software using a dual monitor setup.  That way, it is easier to test without having to go and plug the computer to the TV each time.

Unzip the contents of the JetKTV2010 program in a folder and open JetKTV2010.exe.  The GUI buttons are for searching through the database (by looking for the artist, song name, etc.) to find the wanted song. Once a song is selected, it will be added to the list of songs to play just like the software at actual Karaoke establishments. The video will play in full screen on one monitor and the song picker GUI will say on another monitor.  To close the program, click on the top left corner of the GUI (hidden button).

Some of the software features in addition to searching and adding songs:

• Skipping songs
• Fast forwarding, pausing, etc.
• Switching from one audio channel to both audio channels (alternating between vocal on/off)

This program reads from a database that contains the song names, artists, language, etc.   Therefore, it does not come with songs.  Songs must be downloaded separately and added on.  These can come from existing DVD’s or YouTube.  The next section will explain how to populate the database.

Populating the Database

The SongMgr program mentioned above can add/remove contents from the database, but there are problems with it when using it on English language PC’s due to problems in encoding some of the Chinese characters.  Even Microsoft AppLocale fails to rectify the problems.  The solution is to use Microsoft Access to open up the database file directly and make changes.

Adding one song can seem like a lengthy process at the first try, but it will get easier as one becomes more familiar with the system.

Inserting A New Song

To insert a new song, one must navigate to the table where the songs are stored and then add an entry to it.

1. Open Song.mdbin the JetKTV program directory
2. When prompted for a password, input “tmwcmgumbonqd” without quotes
3. Navigate to the table Tbl_Song.  This is the table that records all the song entries.

Below is an explanation of each column:

• Song_ID: numerical identifier for each song (the program lists them as 5 digit numbers starting at 10000)
• Song_Title: song title
• Song_Singer: each singer has a unique number associated with them (see next section)
• Song_Singer (2nd one): the name of the artist in text
• Song_Word: number of characters in the song name
• Song_Type: a number representing a language (Mandarin,Taiwanese,Cantonese,Hakka Chinese,English,Japanese,Movies,Cartoons,Other  in that order starting from 1)
• Song_Volume: song volume, but not sure what units they are in.  Default value is 70.
• Song_Channel: the audio channel that does not have the vocal track. (1-Left, 2-Right, 3-Both)
• Song_FileName: filename of the video without the directory
• Song_Path: the directory to the file (could use absolute pathing only, but unsure of whether relative paths work)
• Song_Create: the time that the song was added in
• Song_Count: the play count of a song
• Song_Juyin: the Zhuyin characters representing the song title
• Song_Stroke: number of strokes in the first character of the song name

Some of the columns can be left out, but that means that it will not be possible to find a particular song using the omitted information.  For example, Song_Juyin can be left out for those who dont use the Zhuyin system, and that feature won’t be used for song searching anyway.

To add a song, fill out the following information at the minimum on one row:

• Song_ID (must be a unique number and should have five digits)
• Song_Title
• Song_Singer
• Song_Volume (70 is the default)
• Song_Channel
• Song_FileName
• Song_Path

For the Song_Singer information, refer to the next section.

Inserting A New Artist

Artist information is stored on a different table called Tbl_Singer

1. Open the table called Tbl_Singer
2. Fill out an entire row to add a new singer (see below for the reference for each information column)

Below is an explanation of each column:

• Singer_ID: unique identifier for each singer (this is the unique ID that is to put inserted in the Song_Singer column in Tbl_Song)
• Singer_Sex: singer gender (0-Female, 1-Male, 2-Group/Band)
• Singer_Name: artist name in text
• Singer_Juyin: the Zhuyin characters representing the artist name
• Singer_Stroke: number of strokes in the first character of the artist’s name

Testing

One a song or two has been entered into the database, one can test it by opening up the JetKTV program and trying to pick a song.  It is working when one screen shows the video playing and another screen showing the JetKTV GUI.

One can also try clicking the button labeled “導唱” to test if the audio channels are set up properly (toggling it turns on and off the vocals).

The next step would be to plug in the computer with all the television components and then trying it again.  Once everything works, the system is ready.

References

All reference sites are in Chinese

[1] 動手打造窮人 KTV <http://www.jetktv.ktvdiy.com/> [Update 2022 October: JetKTV seems to be defunct]

[2] [影音相關] JetKTV 輕鬆打造免費 KTV 點唱機 (進階設定篇) <http://www.soft4fun.net/video-related/%E5%BD%B1%E9%9F%B3%E7%9B%B8%E9%97%9C-jetktv-%E8%BC%95%E9%AC%86%E6%89%93%E9%80%A0%E5%85%8D%E8%B2%BB-ktv-%E9%BB%9E%E5%94%B1%E6%A9%9F-%E9%80%B2%E9%9A%8E%E8%A8%AD%E5%AE%9A%E7%AF%87.htm#doublescr>

[3] 峰網誌 JetKTV-DIY電腦點歌機..軟體篇 <http://www.wretch.cc/blog/Linpy/4853370>

The past two months of weather in Stuttgart saw a majority if days that were partly cloudy without a lot of sunshine and a lot of random rain.  Since the beginning of last week, the temperature in Stuttgart rose from a comfortable 20 degrees Celsius to a phenomenal 30 degrees Celsius over the course of a day.  Also part of this dramatic change was the sudden disappearance of all the clouds.  This weather persisted for a few days and I was beginning to think that summer in Stuttgart finally arrived.

Last Wednesday, I noticed on the weather report that Stuttgart would get more rain today and when I saw that I thought it was kind of strange.  As usual though, the forecast here was generally pretty accurate.  As predicted, it started raining as I got to work.  The rain was so light that it may as well not be considered rain.  Not long after, the weather reverted to the 30 degree sunshine.  That was disappointing.  I wanted more rain.

Later that day, as I was leaving work, the bright summer sky was overrun by a large gathering of storm clouds.  A large rainstorm started pretty much around the same time I decided to leave work. I walked from the research building to the main building, which usually takes about a minute, and during that time, it rained so hard that everywhere that my umbrella didn’t cover was soaking wet, namely my jeans from the knees down.  I could squeeze the pant leg and water would gush out like a wet towel.

Like everyone else, I waited for the bus by the guard booth at the gate under shelter.  Looking out, everyone could see the rain turn into hail.  Hail the size of loonies rained down.  The sound of the hail hitting cars just made a loud and persistent rattling noise.

When the bus came, everyone opened their umbrellas and ran to the bus.  While inside, we could still hear the loud rattling from the impact of the hail and we were all thankful that we didn’t have to be outside anymore.

As the bus passed under an overpass, we could see the drain on the overpass disposing the drainage water onto the side of the road beneath it and because of that, it ended up flooding the road.

About halfway down the mountain, the rain stopped and almost immediately, a rainbow appeared.  After getting off the bus, I started feeling the intense summer heat again.  The wet ground now just reflected the intense summer like a giant mirror.

I don’t think I’ve ever encountered that large of a rainstorm in recent memory and definitely not one where it started hailing in 30 degree weather.  Haven’t been that soaked from rain before either.  It was really like movie rain – it comes out of nowhere all of a sudden and gets everyone soaked, but it stops really quickly.