You will need:

• WSL2 setup with Firefox installed (mine uses Ubuntu 20.04)
• VcXsrv
• geckodriver

How it works

VcXsrv starts up an X server on the Windows host machine, and what WSL will do is connect to this server to pass on the details of what programs need to be displayed (in this case, the browser window). Geckodriver is there purely as a middle layer for Selenium to be able to interact with Firefox.

VcXsrv setup

This setups the X server so that Windows can display graphical data coming from the Ubuntu instance.

1. Download and install
2. Start it up with the the command line parameter “-ac”. This flag removes access control restrictions for connecting clients (which is okay as long as this server isn’t exposed on the open Internet and that the only client connecting is the Ubuntu instance)
3. Allow connections to VcXsrv on Windows Firewall

The “-ac” flag and allowing the program through Windows Firewall is pretty important. When I didn’t do this, Ubuntu would give me cryptic error messages like “Broadway display type not supported”, but once I set up these access controls, everything was fine.

Bash setup

Install firefox

sudo apt install firefox

Export DISPLAY variable in .bashrc (or for whatever terminal you use, maybe .zshrc, etc.)

export DISPLAY=$(ip route | awk '{print $3; exit}'):0

This will configure your DISPLAY variable to use the IP address listed in the resolv.conf file. The IP address listed there is the IP address of the X server that will be used for displaying the browser window.

Start up VcXsrv as described in the above and then try to open Firefox. The Firefox window should open.

Geckodriver setup

This acts purely as the API interface that allows Selenium to interact with Firefox. Selenium looks for this executable when controlling the web browser.

1. Download geckodriver (make sure to get the Linux one and not the Windows one)
2. Put it in /usr/bin (or alternatively some other folder in your PATH)

Selenium sample on Python

I tend to use Python when running Selenium code, and I haven’t tried it on another language (I imagine the principles are similar). Here is a piece of sample code for starting up the browser and opening up a website, but really any Selenium code can be used.

import time

from selenium import webdriver
from selenium.webdriver import DesiredCapabilities

def execute_with_retry(method, max_attempts):
    e = None
    for i in range(0, max_attempts):
        try:
            return method()
        except Exception as e:
            print(e)
            time.sleep(1)
    if e is not None:
        raise e

capabilities = DesiredCapabilities.FIREFOX
capabilities["marionette"] = True
firefox_bin = "/usr/bin/firefox"
browser = execute_with_retry(lambda: webdriver.Firefox(
    firefox_binary=firefox_bin, capabilities=capabilities), 10)

browser.get("https://www.google.com")

time.sleep(10)

browser.close()

Heidelberg

Heidelberg probably has the most picturesque old town in the entire Germany. Out of all the views I’ve seen in Germany, this is one of the best.

The view is from the ruins of a castle that was destroyed during the Thirty Years War (17th century). I believe the old town is mostly in the Baroque style.

For breakfast, we had a very traditional German pastry, known as a Berliner. It’s similar to a doughnut, but without the hole, and it has a jam filling on the inside and powdered sugar on top. They’re super delicious and not insanely sweet like a lot of American doughnuts.

For lunch, we had more traditional German street foods. The top of the bottom image is currywurst, cut up sausage with curry ketchup on top. The flavour is a very savoury sausage with a slight sweet and spicy zing of curry. The bottom of the image is a bratwurst in a breadroll with mustard. Everything about this is better than the American hot dog. Better sausage to bun ratio, better bread, better sausage, and better mustard. And of course, fries are seasoned with mayonnaise instead of ketchup.

After lunch, we drove up the hill across the river from the old town and visited an old ampitheatre. Why is this amptitheatre interesting, you might ask? It’s actually a relic of the Nazi period for holding propaganda performances.

The main allure of Heidelberg itself is its picturesque views both in the old town and up on Heidelberg castle. Visitors can easily enjoy this by strolling through the old town and making their way up to the castle (there is also a tram), which are main attractions of the city.

Zweibrücken

From Heidelberg, we drove to Zweibrücken. It was a slight detour from Luxembourg, where we were actually trying to go, but we had read about a cool observatory decorated like R2D2, so we thought we’d check it out! It would have been cool to look through the telescope – after all the sky was completely clear of any clouds.

Driving to the place was super scenic! Nice rolling countryside hills with towering wind turbines.

From there we continued our drive to Luxembourg.

Luxembourg

We crossed the border into Luxembourg at dusk and stopped by the town of Schengen. This is the place where the Schengen Agreement was signed – the agreement that removed the hard borders between its European member states.

Normally, it’s possible to walk across to the island to see the small exhibit that discusses the Schengen Agreement, but we were super surprised to see the river at such a high tide (it did rain a lot the past couple of days). On the right of the picture, there’s a little shrub, street signs and flagpoles poking out of the water.

By the time we reach Luxembourg City, it was nighttime. To our surprise, the city looked deserted even though it was only 19:00. People walking on the street appeared drunk. There was even a guy taking a leak in the street without even trying to do it in an alley!

We walked around a bit to check out the town, but otherwise, there wasn’t much to do at that hour on a weekday.

We didn’t stay too long in Luxembourg, and we continued our drive to Bastogne, where we’d stay the night.

Photos:

• Heidelberg
• Zweibrücken
• Luxembourg

Strasbourg

Strasbourg is in the historic region of Alsace-Lorraine. The unique thing about Alsace-Lorraine is that in the span of 100 years it has flipped back and forth multiple times between France and Germany as a result of three wars (the Franco-Prussian War, World War I, and World War II). As a result, the city shares cultures from both countries. This is super evident in a part of town called Petite France, most notably the timber framing around each building. The local dialect Alsatian, also has Germanic origins.

It’s also the home of the European Parliament. This is where over 700 democratically elected Members of European Parliament pass legislation.

Thus far, in France, I had been speaking my very limited French here and there whenever I needed it. As we waited for the tour, a Middle Eastern fellow struck up a conversation with me in French, kind of just asking us where we were from etc. It was kind of weird, but we went along with it anyway – it didn’t seem like he was a pickpocket or anything. I managed to get pretty far in the conversation in French actually, which surprised me quite a bit. He told me that he had moved to France from Afghanistan after working there as part of the local security forces, and even showed me his old Afghan ID, and a bomb scar he had.

The conversation got super weird when he started asking about our yearly salary, and it seemed like he was asking us for money (but it’s possible some of that was lost in translation). At that point, we totally understood why he started the conversation in the first place. We basically told him that we’re not that well off either and he tried to give ME money, and I still don’t understand what was going on there. When the tour started, it seemed like he was still staying within our general vicinity, which made it even weirder. Eventually he picked up on that and left us alone. We even checked if he followed us back to our car (just in case).

Strasbourg appears pretty proud of their cuisine – even their postcards have pictures of recipes of different Alsatian dishes. One that we had was called Flammekueche (in German it’s Flammkuchen, so it’s easy to see the German influence in the language here, at least in this word). I think the closest analogue that English speakers would know would be a flatbread pizza, but with more French style ingredients like fromage blanc, and uses crème fraîche as a base as opposed to tomatoes.

From Strasbourg, we began our journey to Switzerland. At the border, we bought our vignette (it’s a required sticker on the car for driving in the country). I spoke to the lady in German and I got a nice feeling speaking and listening to a language that I understood again.

Habsburg Castle

Our first destination in Switzerland was the Habsburg Castle. This is where the House of Habsburg began. This is THE Habsburgs that wielded enourmous power in Europe for centuries, most notably the Holy Roman Empire, and the Austro-Hungarian Empire.

The castle looks quite modest compared to other European castles like Neuschwanstein, but this is because it was originally constructed almost 1000 years ago.

Zürich

As we drove through Switzerland, we expected mountain passes full of snow, but there were actually very few mountains along that route! We probaly would have seen some in Zürich itself, but too bad it was nighttime.

We arrived in Zürich just in time for a fondue and raclette dinner, because that’s what the stereotypes say. Of all places we found though, we found the most touristy one. I’m pretty sure everybody in there was a tourist.

As we were chatting while eating, I was trolling my friend, saying he comes from China even though he’s actually from Taiwan, since Taiwanese people stereotypically like to assert that Taiwan is not the same as China. A lady at our neighbouring table heard us and actually confronted us about it. She seemed so pissed off! She seemed fine once we told her we were just messing around, and that I’m from Hong Kong (people from there generally side with Taiwan). But imagine travelling all the way to Switzerland and hearing someone trashtalking your country!

This concludes our fourth day. Stay tuned for day five!

• Strasbourg
• Habsburg Castle
• Zürich

This was the weather on the night I got there… Very pleasant…

The next morning we went on a nice scenic drive through the mountains to chill at the sulphur hot springs.

We spent a good couple hours just sitting in the outdoor hot springs. The water temperature was like hot tub temperature while it was lightly snowing outside.

We stayed overnight in a nearby town.

The next day we ate at a very hilariously named restaurant…

Went on a scenic drive and a light hike around some frozen lakes.

Then at night, because I like South Park so much, we went to Casa Bonita. South Park’s depiction of Casa Bonita was quite accurate.

The cliff divers are real!!

We even ate at the so-called “South Park table”, the same table that Cartman eats at when he is dreaming about going to Casa Bonita.

Classic American breakfast. 16 oz Steak and eggs.

Our last day in Denver is when we actually spent time IN Denver. Strolling down 16th street mall.

Then we wandered into the state capitol. One of the hallways had photos of every president of the United States. All but one. Since each portrait is funded by donation, it might be a while before the current asshat president will get his picture put up.

Managed to get a peek at an actual discussion between politicians. I saw a guy defending a climate bill while nobody listened. And then I wondered if that’s what it was like at the federal level too…

In the afternoon, we rented a GTR and zoomed around the mountains. My friend and I took turns driving this supercar.

I had trouble keeping the camera still in the turn. At one point, the car readout showed that we were pulling 0.5G’s of acceleration!

The rental company has a guy that drives a lead car while guests renting different super cars follow them on their route. Their route was quite well planned and took us on a nice windy mountain road that led up to a lake. Along with us for the ride was a Lamborghini.

The rental company’s garage has even more amazing cars.

Denver was quite a relaxing trip, which is quite different from my usual trips where I’m walking for the entire day. In a blink of an eye I was back on the plane headed back home.

Link to photos: here

The nice thing about all of this is that I can push a code change to git, and Jenkins can build it, run through all the tests and then deploy to production automatically.

Layout of a pipeline script

Pipeline scripts are written in Groovy, which is a variant of Java. In general, a pipeline script is laid out like this:

node {
    def SOME_CONSTANT = "whatever"
    ...

    stage('some stage name like Build') {
        // Stuff to do as a part of this stage
    }

    stage('another stage') {
        // More stuff
    }

    ...
}

Each stage represents a stage in the pipeline (e.g. building, beta deployment, prod deployment etc.)

Defining some constants

First, a list of constants can be defined that can be used throughout the pipeline so that if the pipeline script gets reused somewhere, only these constants have to be changed. I’m not aware of anything that lets me reuse a pipeline in Jenkins without copying and pasting the code somewhere else so for now I’ll have to live with copying and pasting.

My project uses Maven so I got Jenkins to download its own copy of Maven that it can use to execute builds and have defined it as a constant. The name I’ve given it in the Jenkins Global Tool Configuration is “Maven 3.3.9” exactly. My project also uses Tomcat so there are some Tomcat specific things in there that may or may not be relevant to your use case.

def MAVEN_HOME = tool 'Maven 3.3.9'
    def WORKSPACE = pwd()

    def PROJECT_NAME = "name-of-project"
    def WAR_PATH_RELATIVE = "App/target/${PROJECT_NAME}.war"
    def WAR_PATH_FULL = "${WORKSPACE}/${WAR_PATH_RELATIVE}"
    def TOMCAT_CTX_PATH_BETA = "Tomcat-context-path-for-the-beta-stage"
    def TOMCAT_CTX_PATH_PROD = "Tomcat-context-path-for-the-prod-stage"
    def GIT_REPO_URL = "URL-to-git-repo-ending-in-.git"

Preparation Stage

First, the code has to be retrieved from the repository before it gets built. Jenkins allows storing username/password pairs so that they can be referenced without having to write out the password in plaintext. Jenkins uses a “credential ID” for this.

    stage('Preparation') {
        git branch: "master",
        credentialsId: "credentials-ID-stored-in-Jenkins-that-can-access-the-git-repo",
        url: "${GIT_REPO_URL}"
    }

Build Stage

Next, the code must be built and unit tested. “mvn clean install” will do just that (depending on what you want, you can always put in a different maven goal). The junit command is just there to take the resulting XML that gets generated during the build process and posts a graph of how many tests were run for each build.

    stage('Build') {
        sh "'${MAVEN_HOME}/bin/mvn' clean install"
        junit '**/target/surefire-reports/TEST-*.xml'
    }

Beta Stage

Once the build succeeds, you’ll want to deploy it to a beta environment, so integration tests can happen. The following happens at this stage:

1. Get the right credentials to get permissions to Tomcat
2. Call the deploy method to deploy the war file in Tomcat (more on that later)
3. If the deployment fails for whatever reason, print out the deployment log for debugging and fail the build
4. If the deployment succeeds, run the integration tests (the command to do this may differ based on use case)

    stage('Beta') {
        withCredentials([[$class: 'UsernamePasswordMultiBinding',
            credentialsId: 'credential-id-for-tomcat',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
                // Password is available as an env variable, but will be masked 
                // if you try to print it out any which way
                def output = deploy(WAR_PATH_FULL, TOMCAT_CTX_PATH_BETA,
                        env.USERNAME, env.PASSWORD)
                if (output.contains("FAIL - Deployed application at context path " + 
                        "/${TOMCAT_CTX_PATH_BETA} but context failed to start")) {
                    echo "----- Beta deployment log -----"
                    echo output
                    echo "-------------------------------"
                    currentBuild.result = 'FAILURE'
                    error "Beta stage deployment failure"
                }
            }

        echo "Running integration tests"
        sh "'${MAVEN_HOME}/bin/mvn' -Dtest=*IT test"
        junit '**/target/surefire-reports/TEST-*.xml'
    }

The deploy method is what takes care of the actual deployment to Tomcat, which is how the Jenkins build tells Tomcat about the newly built war file. The deploy method is below (be sure to change the server IP and port). Alternatively, I could have built my project as an embedded jar file, but that has a different challenge in figuring out how to get Jenkins to tell the OS to execute the newly built jar file as a particular user.

1. Based on the Tomcat context path, decide whether a beta or production deployment is happening
2. Make a copy of the build war file and add .prod or .beta to the end of it so as to keep the original
3. Set the Spring profile to use on the newly copied war file (more on that later)
4. Call the curl command to do the actual deployment to Tomcat (more on that later)

def deploy(warPathFull, tomcatCtxPath, username, password) {
    def envSuffix = ""
    def isBeta = tomcatCtxPath.contains("beta")
    if (isBeta) {
        envSuffix = "beta"
    } else {
        envSuffix = "prod"
    }
    sh script: "cp ${warPathFull} ${warPathFull}.${envSuffix}" 
    setSpringProfile(warPathFull, isBeta)
    def output = sh script: "curl --upload-file '${warPathFull}.${envSuffix}' " +
            "'http://${username}:${password}@localhost:8081/manager/text/deploy" + 
            "?path=/${tomcatCtxPath}&update=true'", returnStdout: true
    return output
}

In the case of my project, I’m building a single war file that does not have a Spring profile (beta/prod) defined. This means that I have to manually define this before I deploy the app to Tomcat since there are some things that differ between beta and prod like database URL’s. To do this, I wrote a method that opens the war file like a zip (jar/war files are zip files) and adds a line to my application.properties to define a Spring profile.

Admittedly, doing this zip file manipulation seems kind of hacky. Alternatively, I could have defined my build such that I had a separate beta build and a prod build to avoid modifying the zip file, but the drawback is that I’d then have to build my code twice.

def setSpringProfile(warPathFull, isBeta) {
    def zipFileFullPath = warPathFull + "." + (isBeta ? "beta" : "prod")
    def zipIn = new File(zipFileFullPath)
    def zip = new ZipFile(zipIn)
    def zipTemp = File.createTempFile("temp_${System.nanoTime()}", 'zip')
    zipTemp.deleteOnExit()
    def zos = new ZipOutputStream(new FileOutputStream(zipTemp))
    def toModify = "WEB-INF/classes/application.properties"

    for(e in zip.entries()) {
        if(!e.name.equalsIgnoreCase(toModify)) {
            zos.putNextEntry(e)
            zos << zip.getInputStream(e).bytes
        } else {
            zos.putNextEntry(new ZipEntry(toModify))
            zos << zip.getInputStream(e).bytes
            zos << ("\nspring.profiles.active=" + (isBeta ? "beta" : "prod")).bytes
        }
        zos.closeEntry()
    }

    zos.close()
    zipIn.delete()
    zipTemp.renameTo(zipIn)
}

A curl command to Tomcat is what actually does the deployment. To deploy a file to Tomcat, do the following below. This will deploy the war file to Tomcat and instantly run it, thus it will be accessible at the given context path.

curl --upload-file 'path-to-war-file' http://username:password@server-address:port/manager/text/deploy?path=/tomcat-context-path&update=true

Prod Stage

The same kind of stuff happens in the prod stage as in the beta stage with a few exceptions. The following happens at this stage:

1. Get the right credentials to get permissions to Tomcat
2. Call the deploy method to deploy the war file in Tomcat (except this time it is prod)
3. If the deployment fails for whatever reason, print out the deployment log for debugging and roll back the deployment
4. If the deployment succeeds, save the build files, and then the pipeline is finished. Alternatively, smoke tests can be run at this point, but I did not implement this in my project

Rollback is important because if the deployment fails, you don’t want to be stuck with a broken environment. Since build artifacts are saved on successful deployments, these same artifacts can be brought back if future deployments fail. This means they can be redeployed so that the code can be fixed before another deployment happens.

    stage('Prod') {
        withCredentials([[$class: 'UsernamePasswordMultiBinding',
            credentialsId: 'credential-id-for-tomcat',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
                // Password is available as an env variable, but will be masked 
                // if you try to print it out any which way
                def output = deploy(WAR_PATH_FULL, TOMCAT_CTX_PATH_PROD, env.USERNAME, env.PASSWORD)
                if (output.contains("FAIL - Deployed application at context path " + 
                        "/${TOMCAT_CTX_PATH_PROD} but context failed to start")) {
                    echo "Prod stage deployment failure, rolling back deployment"
                    echo "----- Prod deployment log -----"
                    echo output
                    echo "-------------------------------"
                    step([$class: 'CopyArtifact',
                            filter: "${WAR_PATH_RELATIVE}",
                            fingerprintArtifacts: true,
                            projectName: "${PROJECT_NAME}",
                            target: "${WAR_PATH_RELATIVE}.rollback"])
                    deploy(WAR_PATH_FULL + ".rollback/" + WAR_PATH_RELATIVE,
                            TOMCAT_CTX_PATH_PROD, env.USERNAME, env.PASSWORD)
                    currentBuild.result = 'FAILURE'
                    error "Prod deployment rolled back"
                } else {
                    archiveArtifacts artifacts: "${WAR_PATH_RELATIVE}*", fingerprint: true
                }
            }
    }

At the end you get to have something like this:

That pretty much sums up the whole Jenkins pipeline that I’ve been using lately for Spring projects!

There is a Uniqlo here! I wish I got paid to say this, but it’s the greatest clothing chain in existence.

Gotta love these Bierbikes rolling down the street.

Our main reason to come here was join in on the party that is the Eurocup. A giant screen was set up at the Brandenburg Gate just to show the games. We stuck around to watch Poland play against Portugal!

The weirdest part, that before the game started, they did Kiss Cams, which was fine, but they did this with straight men too… shudder

These people know how to chill.

We met some of my friend’s German friends and they took us to a warehouse that was converted into a bar with a giant screen just to watch Germany VS Italy. According to them, going to that place to watch the game has brought them “good luck” when they went to see Germany VS Brazil in 2014. Definitely one of the greatest games of Football I’ve seen – what a close game between Germany and Italy with a 6-5 Germany win after a penalty shootout.

And of course, when in Germany…

Link to photo album: here

We departed from Boundary Bay Airport, where they had a bunch of small two-seater aircraft.  We sat in the cockpit for a bit doing the standard pre-flight check before we were able to get going.  Once we were in the air, we headed towards Pitt Lake.

From the photo above, those familiar with Vancouver may recognize a few places, such as the Fraser River, the Alex Fraser Bridge, New Westminster, etc.

While we were in the air, Matt gave me a chance to fly the plane for a bit.  By flying, I mean control only the joystick (and looking at none of the dials on the dashboard) and by controlling, I mean struggling to keep the plane flying straight.  It was definitely quite intimidating.

The above is a photo of Port Coquitlam and Pitt Meadows with the Pitt River in between.

It didn’t take long to get to Pitt Lake and from there we flew back to Boundary Bay Airport through  Surrey/Langley.  Here, I gave flying the plane another shot.  This time I was a bit better.  It wasn’t as scary and I worked up the courage to get the plane to turn left and right.

Further on the flight, it just so happened that there were rain clouds nearby.  It was pretty cool to see rain from far away. I had no idea it looked like that. And while there’s rain combined with sunshine, there’s a rainbow.  We briefly flew in some rain before we made it back to the airport.

We flew around for about 35 minutes, but it definitely was a really really cool experience! All thanks to Matt for making it possible.

The outside patio seating on cobblestone roads has a nice “European feel” and the architecture of the buildings surrounding it definitely add to the atmosphere.  Store and restaurant labels being in French also makes the atmosphere feel a lot more foreign (but luckily most people in Montreal speak English).

As I have learned throughout my travels, there is always a nice church in the historical part of town, at least in this case, a basilica.  This one is called the Notre-Dame Basilica or in French, Basilique Notre-Dame de Montréal.

The inside is also quite different.  I remember a lot of churches like to use ambient light to keep the interior illuminated but the main congregation hall seems to be closed to natural light except for the two windows in the ceiling.  There is a lot of “blueness” in this basilica, which I don’t think is very common.  As usual, the altar is filled with statues of religious figures.

After that, the next destination was Mount Royal, which is one of Montreal’s largest greenspaces.  There is a large artificial lake where people like to go for runs or just casual strolling.  There is also an observation area that looks down the mountain toward downtown Montreal.

A raccoon even tried to join us at the observation area.  Poor raccoon…was probably hungry too.

That night we had a nice dinner that was a partial family reunion.  I think about 15 people from my father’s side of the family came.  That was probably the first time we’ve ever all got together for a meal in a long time.  The meal was also made better by the presence of my cousin’s 15-month old daughter (first cousin once removed?).  I think the last time where everyone got together (at least partially – I wasn’t present for that one) was in the summer of 2009 when one of my cousins got married.  We all asked about one another and how everyone was doing since we hadn’t caught up in a while.  We ate for about an hour and talked probably for another 2 or 3 hours.  It was a nice get-together that doesn’t happen very often.

More photos here

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.