In March I posted a preview of the robot with a picture and promises of more details to come. Its taken me way to long to finally write it up. The robot has been done since May and has made a dozen or so ascents. Making the video is what caused the delay.

Here is what I remember of the process.

I asked Alexandria what the tower should be made of and where is the tallest place in the house. Wood and K’NEX were the candidate tower materials. We had just gotten some K’NEX for Christmas so that seemed like the more interesting choice. We measured a few places in the house and found that the tallest possible place was the stairs that went from the basement to the second floor but in at least one spot it would be too narrow for a robot. The second tallest place has a ceiling fan in the way. That left the play room which has a sloped ceiling just over 11ft at its highest. We have a large Lego collection including the RCX so it was clear that the robot would be made out of Legos.

One weekend morning Alexandria and I set out to build the tower. We were both new to K’NEX so we started by just playing around with different ways of connecting them. We each came up with a tower design. Alexandria’s was stronger (and looked cooler) but used more pieces. We decided to go with her design after removing some parts to conserve materials without reducing the strength. In the end we ran out of some parts so we switched to a simpler design that used parts that we still had plenty of for the top of the tower. The total height of the tower is 10ft 9in (3.28 meters). The tower has a ladder built into one of its faces for the future robot to climb.

Later, my other daughter, Isabella, helped build the tower base out of wood. She cut strips of wood and screwed them to a piece of scrap plywood to hold the tower steady as the robot climbed. There are no guy wires or anything else holding the tower steady.

With the tower complete it was time to work on the robot. I knew that this would be much more challenging than the tower but I still wanted to involve the kids as much as possible. We talked about how design ideas can come from watching other things work including nature. We acted out how people climb ladders and modeled the motion of a simple arm with Legos. I played a little with a motorized elbow and shoulder but quickly realized that it would end up being too heavy, not strong enough and use more motors than the Lego RCX can control (it has a maximum of three outputs).

I switched to a design that used rack gears to move an arm up and down. A quick test showed that driving the rack gear directly from the motor would not have enough power to lift the robot. Gear reduction would be needed. This was a good opportunity to demonstrate to the kids how you can trade speed for power with different size gears.

The robot has two climbing arms. The left and right sides are mirror images so Alexandria and I built one side each in parallel. At this point we had a good motorized climbing mechanism with switches so that the robot controller would know when the arms were at their farthest extent either up or down. It used two motors and two switches. The arms had enough reach for the ladder rung spacing but how it would grab and release was still an unsolved problem and turned out to be one of the hardest.

I used a section of the tower ladder for testing out various designs for how the robot arms would grab and release. The general principals were fairly simple. It needed a pivot and a curved or angled piece to move the hook out of the way as the arm moved up past the next rung. It would then need to snap back into place so the hook could engage the rung as the arm moved down. Selecting just the right combination of pieces that would work with the K’NEX ladder design was very challenging. I worked on this many nights without finding a solution that I thought would be robust enough.

I stopped working on it for a while and it might have become another uncompleted project if Alexandria hadn’t reminded us to get back to work on it. I finally came up with a design for the grabbing hook. The blue curved part and the pivot point near the rack gear allows the hook to move out of the way as it slides past the ladder rungs. Then a rubber band snaps the hook back into place. The black piece sticking up contacts a switch on the down stroke.

Deciding where to place the RCX programmable brick was a challenge. Putting it on top of the motors would move the center of mass too far way from the ladder, which would make it difficult for the hooks to grab on. This lead to the hinged design that allowed the robot to drive up to the tower then fold flat and hang down as the robot climbed.

Here is the first version of the climbing robot:

With the mechanics working it was time to start programming. I like to use the text based NQC language for programming the RCX rather than the Lego Mindstorms picture based language. It is also easier to setup and use on Linux.

To get the kids involved we did the exercise described in the Lego Engineering video. We built a simple car and measured how far it went when the motor was turned on for one second. Then we placed a Lego minifig 4 feet from the starting line. The challenge was to figure out how long to run the motor so that the car would come as close as possible to the minifig without running it over. We had a lot of fun doing this. However, I bet it wasn’t so fun for the minfigs that got run over.

The program moves each climbing arm independently. There are two switches for the arms: one detects when either of the arms is all the way down and the other detects when either arm is all the way up. Because the switches are shared by both arms the program must keep track of which direction the arms are moving. If both arms are ever both up or both down there will be problems. The program counts each arm stroke and displays the count on the RCX display. It also makes a beep sound on each stroke. This beep turned out to be helpful during video editing. At start up it goes through a test cycle to make sure each arm can move all the way up and down. If something goes wrong during the startup tests it will play an alert sound and end — better to find a problem before it starts to climb.

While testing it became clear that more gear reduction was needed. As soon as the batteries lost more than one tenth of a volt the robot would start having trouble climbing. I added a battery voltage test at startup so it won’t climb if the battery is low.

Using what was learned I redesigned the robot. The gear ratio was 8 to 40 before and I added another 8 to 40. This gave a great deal of torque (and also means the robot climbs much slower). I found that if the switch or program was even a little delayed at turning off the motor it would rip the robot apart. So I did more redesign to make the switch contacts more robust and the overall structure stronger.

The original challenge had nothing to say about how the robot would get down or if it even would. There were plenty of details to work out just to get it to climb up but the getting down problem was in the back of my mind the whole time. While working on the hooks the general idea came to me that rubber bands would be used to pull the hooks away from the rungs while the arm moved down. The tricky part is that the same rubber bands would have to be slack on the way up. I came up with a passive mechanical design where a bar across the top of the tower would trip a lever as the robot climbed past it. This would tension the rubber bands. The lever is designed with another rubber band so that it snaps into either the up or down position and won’t stay in between. This mechanism was in the first version of the robot but it was never tested (since the robot had trouble getting to the top). This too was improved in the second version.

Here is what the second version of the robot looks like:

The climbing direction lever can be seen in the climb-up position. You can also tell that the motor was reversed and the extra gears added to the outside. This allowed for the extra gears to fit in a very small space. Climbing down requires a different algorithm than climbing up. A switch is used to detect when the lever is in the down position. Even with the switch I consider it a passive design because no motor is used to change the mechanical configuration. When the robot reaches the bottom the folding action causes the lever to move part way up (releasing the switch). This is how the program detects when it is all the way down. When testing the robot would sometimes stop halfway down. The reason was that any small movement of the lever could release pressure on the switch. Given the sensitivity of the switch and the delicate balance of the rubber bands the problem was best solved in software. The program requires that the switch be off for two full cycles before ending. This is why it keeps climbing for a moment when it is at the bottom.

This project marks the first time that I used Lego modeling software. While redesigning between the first and second versions I wanted to remember the way it was in case I needed to go back. I had wanted to try modeling software for a while. On my previous Lego video I got some requests for how it was made. This time I have a model to share (see below for the link). The software I used is MLCAD (under Wine), and LDView. This site is required reading for getting this stuff running on Linux. I installed LeoCAD also but in the end preferred MLCAD. I even installed Lego Digital Designer (again using Wine) but this official program does not have very many parts and is not as powerful as the others (it looks and feels like a toy). Note: I had to turn off Compiz for LDView to work (Ubuntu 8.04).

Isabella and I built the cockpit together and Isabella made the minifig pilots.

The robot had one more problem. At the very end when the wheels would first touch the ground the robot would fall over backwards. The reason was that the car wouldn’t fold back up. I tried adjusting the car so that it stayed partially folded (like a hockey stick rather than a straight line) but this moved the center of mass so that the hooks wouldn’t grab reliably. It took me a long time to figure out a solution. After considering all kinds of ideas that would require an extra motor the simple solution can be seen in the last picture. To wheels sticking out the back of the cockpit would hit the ground first and start the car folding.

So now its May and the robot is done. It’s final weight is 900 grams (32 ounces). It climbs up and down flawlessly. A number of visitors get to see it but the project was always intended to include a video to share on YouTube. Here again the project stalls until November.

The last time I edited a video was back when I was running Windows 2000. I used Adobe Premiere 6 and After Effects. Linux doesn’t have as many video editing options as Windows. One program that I saw mentioned a number of times is Cinelerra. Unfortunately it consistently crashed after a few seconds of playing any video I loaded from my Camera. (The camera is a SANYO xacti.) I also found the Cinelerra documentation to be very poor. While looking for another program I found a forum where people were voting for their favorite Linux video editor program. Someone asked why Blender wasn’t on the list. The response: its a 3D modeling program. There were a number of follow ups explaining that while it is a 3D modeling program it also includes a very good video editor. There was something about the responses that made me want to try it. Blender is open source and cross platform, which is great. The documentation is good and the community seems very active. There are many tutorials. The down side is that it has a steep learning curve. When you first start it up it is difficult to even find the video editor. Because of the quality documentation and tutorials I kept at it. It took several hours to get used to the program but the whole time I had the feeling that the effort was worth it – that knowing this software would be useful. I’m very happy with Blender. I found that it can do all the things that I had previously done with the Adobe products.

I shot a bunch of views of the robot and the tower. Then two complete runs up and down the tower. Each run was a continuous shot. I did two runs so that I could cut between them to get views from different angles. The beep the robot makes at the end of each stroke, while not intended for this purpose, helped me to sync cuts between the two shots.

The music for the video is from the Nine Inch Nails album Ghosts I-IV, which has a Creative Commons license. (How cool is that?)

The model is available as a zipped LDraw format (.mpd) file here. The model isn’t 100% identical to the final robot. In some cases the part library didn’t have the exact part I used. Some details such as the rubber band connectors were left off. You can compare with the video and pictures above. The model is organized into sub models and includes some steps. It is provided as-is with no warranty. It was never tested by building the robot from scratch. The NQC program source is also provided as-is with no warranty. Here is a direct link to the YouTube video “Lego Robot Climbs K’NEX Tower”

We hope you enjoy the video.

• Performance. One of the performance recommendations made by Yahoo’s performance team is to reduce HTTP requests. One way to do this is using the CSS Sprite technique — combining many images into a single background image.
• Skin-ability. With the img tag the image URL is in HTML markup where it is hard to change. With CSS Sprites the image URL is in a CSS file making it more convenient to change. Sure you can change the contents of the original file but there are reasons for changing the URL. It is not as easy to move the images to a different server or group them in different image files when the URL is not in CSS.

However there are drawbacks. The biggest is accessibility, specifically high contrast mode. In high contrast mode all background images and colors are ignored — replaced with high contrast colors such as white on black or black on white. The other issue is that background images are not always printed.

The prevailing accessibility advice is to not use background images for functional images. The underlying problem is that there is no way in HTML/CSS to identify a background image as being functional. They are all considered decorative. It is also true that not all img tag images are functional but again there is no way to distinguish them for the purpose of high contrast mode. So high contrast mode makes a reasonable assumption that background images are decoration to be removed and img images are functional and must be shown. From here on I’ll call functional images icons. They either convey important information or are interactive (like a toolbar button for example).

I have seen recommendations that functional background images should be replaced with text when high contrast mode is detected. This does not seem right to me at all. A desktop app does not change its toolbar button icons to text in high contrast mode. The assumption is that icons are already designed to have reasonable contrast.

It also just feels right to me that the icon URLs should come from CSS.

Since I care about performance and accessibility I’m not happy with this conflict. I want a solution that puts the icon URL in CSS, works in high contrast mode and allows me to combine icons into a single image file. Here is what I came up with.

My typical markup for an icon is something like this:

    <button><span class="icon edit"></span></button>
    <button><span class="icon delete"></span></button>

The basic style is:

span.icon {
    display: -moz-inline-box;
    display: inline-block;
    width: 16px;
    height: 16px;
}
button span.icon.edit {
    background: transparent url(images/toolbar.png) no-repeat 0px -32px;
}
button span.icon.delete {
    background: transparent url(images/toolbar.png) no-repeat 0px -16px;
}

This creates a button with an edit icon assuming that toolbar.png is a sprite image with the edit icon at offset 0, 32 etc. I left out extras like a title tooltip and hover and active states for the button icon to keep things simple. This works nicely until high contrast mode is turned on.

You can use the same sprite image in an img element and position it relative to a fixed size parent that has overflow:hidden to achieve similar functionality to a background image.

For example:

    <button><span class="icon edit"><img alt="" src="images/toolbar.png"></span></button>
    ...

The style to make this work is:

span.icon {
    display: -moz-inline-box;
    display: inline-block;
    width: 16px;
    height: 16px;
    overflow: hidden;
    position: relative;
}
button span.icon.edit img {
    position: relative;
    left: 0px;
    top: -32px;
}
...

This works in high contrast mode (as well as normal mode) and has multiple icons in a single image but the image URL is in the markup not in the stylesheet. What I want to do is use JavaScript to take the image URL from CSS and dynamically add the img element as a child of the icon span. The html mark up and stylesheet will be the same as the first example above except that the stylesheet will have these additional styles:

span.icon.edit img {
    top: -32px;
    left: 0px;
}
span.icon.delete img {
    top: -16px;
    left: 0px;
}

These additional rules are not too much extra work considering you will usually have additional rules to adjust the position on hover and active states anyway.

My first attempt tried to get the URL from the current styles using jQuery like so: $(…).css(“background-image”). The trouble is that in high contrast mode the effective current background image is “none” even though the CSS file does have a background image. This makes sense — the program should “see” what the user sees. The solution is to get the actual background image directly from the CSS rules. This takes a little fiddling to get it to work cross browser. Some browsers return the full URL and some return exactly what is in the CSS file. Some times its wrapped in quotes.

This test page shows an example of the traditional CSS Sprite technique as well as my jQuery enhanced high contrast mode compatible version. All the styles and JavaScript are in the html file to make it easy to see how it works. It also contains code to detect high contrast mode. One option is to only make the dynamic change if high contrast mode is detected but that is not the approach I took in the test page.

View the page with high contrast mode turned on and off to see the difference. Note: not all browsers or operating systems support high contrast mode. Firefox and IE on Windows do. It is also important that the dynamic changes work even in browsers that don’t support it (by work I mean that the icons look right and are functional, not that high contrast mode magically starts working in browsers that don’t support it). I tested on Windows with IE8, FF3.5, Safari 3.2 and 4.0, Opera 10 and Chrome and found that they all worked. I also tested on Linux with FF3 and found no problems. I don’t have a Mac to test with. I tested with IE6 and found that it did not work. More investigation is needed but IE6 is not a high priority for me right now. I need to test with IE7 but don’t have it handy right now.

Feedback on how it works in other browsers and operating systems would be very helpful.

I did not do any performance testing. The assumption is that moving the image from the background to an img tag will not cause the image to be requested from the server. The Firebug Net tab indicates that it is fetched just once. The page seems to render fast enough with no flashing. More testing is needed but I think the principal is sound. The script could use some improvement to be more robust especially for much older browsers so they at least fall back to using the CSS sprites as is. I bet there are other cases of relative URLs to test for as well.

Keep in mind that the test page is meant to demonstrate just this technique. It has a bunch of other accessibility no-nos such as the disclose icons are not focusable, keyboard accessible, and have no screen reader accessible label text.

When you use the focus method to set focus to a focusable element the expectation is that, in the absence of css rules to the contrary, the browser will show a focus outline around the element using its default style. This is what happens in Firefox, Chrome, and Safari. (Opera has its own set of focus problems which I didn’t investigate fully.)

There are a number of elements that are naturally focusable, such as inputs and anchors. In addition any element with a tabindex attribute equal to -1 is focusable. If the tabindex is non-negative then it is focusable and in the tab order. My test case uses list elements with tabindex of -1 or 0. I suspect that the same is true of other elements using tabindex.

Older versions of IE (I tested IE6 and I believe IE7 works the same in this regard) had some strange additional requirements beyond just calling focus. The outline would not be shown if the focus method was used to give focus to an element with a tabindex of -1. So before setting focus you would have to set the tabIndex to zero (or a positive number).

elem.tabIndex = 0;
elem.focus();


Also if you click on an element with tabindex of -1 no outline is shown unless the className is updated (even if the value doesn’t change). Perhaps other style changes would work as well.

IE8 adds some new bizarre behavior. First if css is used to set an explicit outline style on the elements (either directly or inherited) then the old IE quirks mentioned above go away as well as the new IE8 problem described below. Setting your own outline style for focus isn’t a good idea unless you are giving your whole web app a focus style makeover. I think it is best to stick with the default styles since it is what the user is probably used to. There is also the problem of old browser like IE6 not supporting the outline style.

If the className of the element receiving focus is updated in the onfocus handler while the tabIndex is -1 then no focus outline is shown. Assuming that the tabIndex is -1 and addClass is a function that adds a class to the className, one would expect the following two lines of code could be executed in either order.

addClass(elem, "myfocus");
elem.tabIndex = 0;


In IE8 setting the tabIndex to zero must be done first or the outline is not shown. This is exactly what tripped me up. If I just happened to write the statements in the opposite order I would never have discovered these oddities.

Note that in all cases focus is actually set correctly it is just the visual indication of focus that is wrong – but thats the important part of focus.

I created a test page that allows playing around with these rules. It is also an example of how focus can be managed with a roving tabindex. If you play with this page in different browsers you will notice that in Firefox (versions 2 – 3.5) , Chrome, and Safari 4 (I tested on Windows) it doesn’t matter what options are checked, the behavior is correct. In IE you can play with the options to see which combinations work.

I wonder if this is intentional in IE8 or is something that will get fixed in a point release.

One nice thing about working at Oracle is that they take accessibility seriously. I have worked on web apps before that were supposed to be accessible but this is the first company I have worked for where I could actually get my hands on a (non-demo-mode) JAWS screen reader to do my own testing. You can try to follow all the best practices but you really do need to test with a screen reader to know how well you have done.

I have found that keyboard accessibility and screen reader accessibility are somewhat at odds.

If you do the right thing for keyboard accessibility (i.e. managing focus) and don’t use WAI-ARIA at all then you have a chance of being accidentally partially accessible in JAWS and probably other screen readers. This is assuming that you follow best practices for being accessible to screen readers (use label correctly, use native form controls – links, checkboxes etc. in semantically appropriate ways).

The problem is that all your keyboard/focus management logic is in vain since you are probably going to use arrow keys and JAWS is not going to give them to you (JAWS uses many keys for itself). The reason you have any chance of success is because the normal screen reading behavior of the arrow keys may be close enough and using native form controls will allow JAWS to access them in a reasonable way. How well it works will depend on the details of your rich control. The best you can do is to try to find the right balance between normal use and screen reader use. This should work OK with older browsers and screen readers depending on the various bugs and odd interactions between various browser and screen readers.

The other option is to go the full WIA-ARIA route. By using the appropriate ARIA roles and states and properties you can get JAWS version 10 (and presumably other new ARIA aware readers) to give you the keyboard keys you need. For this to work you need very recent versions of browser and JAWS. I have had some initial success with JAWS 10 and FF3.5. It looks like this approach will provide the very best functionality for all users. I have not yet tried the combination of JAWS 10 and IE8. The trouble is that the combination of JAWS 10 and IE7 works quite badly when you use ARIA. JAWS seems to get some of the ARIA information like roles but doesn’t get enough to work correctly. It gives up the keyboard keys but then doesn’t handle the ARIA based changes and therefore the normal JAWS arrow key functionality doesn’t work either. This is the worst possible behavior. Presumably older versions of JAWS that don’t know anything about ARIA will work fine with IE7 even if the rich control uses ARIA provided the ARIA support is on top of non-ARIA techniques mentioned previously. I have not yet tested this combination.

To me this means that if you are adding on to an existing app that must support older browsers or screen readers then using ARIA probably isn’t worth it yet. But if you are starting a new app that wont be released for a while then using ARIA is the way to go. You can still support older browsers but you would have to require that for screen reader accessibility an ARIA aware browser and reader must be used.

Another possible solution is to have an option to turn WAI-ARIA support on or off. I don’t like this because of the added complexity of implementation and testing.

Here are some resources that I found very useful in my recent accessibility work: Improving Accessibility Through Focus Management, WAI-ARIA Best Practices, and Delegating the focus and blur events.

I recommend reading “Language Oriented Programming” by M. P. Ward. It also claims programmer productivity as a benefit of what it calls the “middle-out” development style.