The instructions were developed for 32- and 64-bit versions of Ubuntu 9.10, but should be fairly protable to other versions and distributions. The library versions are current as of 18-Dec-2009, but are likely to change over time. You will need to update the commands below if a newer version is released.

Step 1 – Pre-Req’s

First we need to install all the programs and libraries that are required below. The following command will install all the required packages:

The brltty package is “Access software for a blind person using a braille display”. Unfortunatly this package conflicts with a driver below, so we need to remove it.

Step 2 – FTD driver

Here we install the driver for the FDT chip that the Segway uses to communicate. In this step (and the remaining steps) we use a working directory “~/work/” to hold all the files that we are using. You should check the FTDI website to confirm that the latest version is “0.4.16″.

Step 3 – CAN driver install

The installation of the CAN driver is much more straightforward.

Unfortunately, you must fill out a form before downloading the driver distribution, so this step can’t be completely automated. To get the distribution, visit the KVASER website. It can be found by following this path:

1. Support

2. Download
3. Beta Releases
4. All Beta Releases
5. Linux driver and SDKv4.75 BETA

Using a browser, download linuxcan_beta.tar.gz to ~/Downloads/

The instructions below assume that the distribution is still on version 4.75. You will need to make the appropriate updates if the version has changed.

This is the one “hack” of the install. For some reason, the typedefs in the canlib.h header conflict with those in the FTD headers. Really this is a conflict in the packages that ought to be resolved by one of the two authors, but for now we have to resolve the problem ourselves.

Edit /usr/include/canlib.h and comment out the definitions for DWORD, HANDLE, BOOL. Use the “//” comment style and leave yourself a comment in the source code describing why you’ve done this.

At this point, there is no way to test that this installation has gone correctly.

Step 4 – Try Player for Roomba

This might be a bit of a reach, but I will assume that if you’re working with a Segway RMP, you probably already have access to one of the other robots supported by the Player project. In this step, we want to confirm that the player server is working correctly without the influence of the RMP code or libraries.

For the purposes of the example here, I will further assume that you have access to a Roomba Create. If not, update the “–enable-roomba” bit with the name of your robot’s driver.

In the following script, I am using player version 2.1.3, but this script has also been used with version 2.1.2. Just update the version numbers in the script to use the other version.

Start the player server in one console…

… and start the joystick controller in another console.

Step 5 – Try the Segway

Assuming that you’ve gotten this far and everything is working, it’s time to try the Segway

First, connect your USB based Segway RMP and turn it on (green button). Then turn it on (yellow button).

If my patch has not yet been included in the player distribution (these instructions are not in /server/drivers/mixed/rmp/README), then you need to download and apply my patch. Use the following script to do so:

Now it’s time to build the driver. We need to let the build know that the ftd and canbus driver libraries should be included, so we set the LIBS environment variable. Other then that, it’s a standard build.

(It seems that sometimes I need to enclose the value for LIBS in quotes: export LIBS="-lftd2xx -lcanbus". I don’t know why or when this needs to be done.)

Now the moment of truth. I’ve tried to augment the driver to print some useful information when it starts up. If the player server doesn’t start, take a look at the output for debugging hints.

Start the player server in one console…

… and start the joystick controller in another console.

Step 6 – Extra Credit

If you have an actual joystick, this is the time to pull it out. Once you connect the joystick, you’ll need to calibrate it like this:

Then you can fire up a player client to use the joystick rather then the keyboard:

Monday was a big day for the Pharos project. We took 10 robots out to the Dell Diamond’s back parking lot and collected the first real, useful data. There were two main focuses for the mission: (1) how accuratly can we move along a predetermined path using GPS coordinates, and (2) how does distance effect the connectivity of the standard ad-hoc wireless network.

To answer the first question, take a look at the following picture. Here the red line is the track that we wanted the robot to follow. The purple line is the path that it actually took (according to the on-board GPS). The node started in the bottom left and drove to it’s first waypoint in the upper right. Then it visited each waypoint in turn, ending in the upper left. (It seems that maybe it started wandering around on it’s own for a while after it was supposed to stop)

Given that this is very preliminary data, it seems that this bot did a darn fine job of going where it was supposed to go.

To answer the second question, we had one robot sit still, and another drive past it several times. We measured the acheaviable throughput over the wireless network to find out just how far you have to go to disconnect. Well, it seems that you have to go about 80m. I wish I had the graph to show you, but it’s still under construction… in the mean time, here’s the mobility trace from this experiment:

As murphy’s law dictates, the sexiest part of the demo (the Roomba) failed to work on demo day. I’ll be diagnosing this issue when I get home, but I now believe the servos make a better demonstation tool anyway.

For more information about the SEAP system, here is a list of other resources:

• A more detailed explanation of SEAP currently under review for a conference.
• The first SEAP (short) paper with a brief explanation of the technique
• Original Demo Proposal for Middlware 2008

I’m excited to give this demo for a couple reasons. First, I think it’s going to be a really interesting demo to interact with. The devices and code are all going to be right out on the table to play with. Second, Middleware has two dedicated slots for demos, so there’s a good chance to meet people.

If you’re going to Middleware also, be sure to check out our lab’s paper on Adaptive Milddleware to Support Delay Tolerant Networking in the ARM ‘08 Workshop.

Thus, I spent the time to figure out how to run JUnit tests on my desktop for SunSPOT applications. I put together a strip-down template using JUnit tests for Spots on the desktop for anyone who would like to build on it. I was also able to get my IDE (IDEA) to use the Spot JVM and libraries, so I’m back in the groove with test-driven development!

Challenges in Automotive Software Engineering (Keynote)

Authors: Manfred Broy
It figures that I’d start with a presentation that has no matching paper, eh? The whole presentation was rather interesting, but here are a couple key points that are relevant to my research:

• Integrating all the control units found in a car is complicate by the combinatorial explosion resulting from the combination of optional features.
• There is heavy use of automatic code generation based on models in this arena. While I didn’t completely grasp the extent and the ramifications of this, it’s something to keep in mind when targeting these types of applications.
• A while back I was told that the automobile industry would love to use radios to communicate information between control units. This was routed in the desire to reduce the weight associated with the all the wiring involved with standard techniques. Well, it seems that even with wired networks on the car, there’s a more compelling problem: non-determinism. The old protocol “CAN” is being replaced by new technologies that using (some variation of) time division to guarantee a certain amount of bandwidth to each control unit. If we want to replace wired networks, we’re going to have to consider this problem which is very much non-trivial in wireless networks.

40 Years of Middleware

Presenter: Wolfgang Emmerich
Overall, this was a fun presentation. It’s hard to report exactly what was said since it was mostly a detailed historical retrospective of the evolution of middleware. Wolfgagng Emmerich did an excellent job of researching and presenting this information, and referred to a paper recently published (in TSE?) that contains much of the information presented. This paper ought to be an interesting read.
As a side note, many people in my lab have discussed “what is middleware” with varring degrees of success. The definition used for this presentation included two aspects: (1) multiple hosts (physical or logical), (2) heterogeneity, and (3) distribution. It’s probably worth looking up this paper to at least look at and consider the definition of Middleware presented there.

Asking and Answering Why and Why Not Questions about Program Behavior

Authors: Andrew Ko, Brad Myers
Paper: PDF, Tool Homepage
ICSE08 Distinguished paper award
This was cool, and defiantly worth a read. I’ll likely force this paper on my lab when I get back, even though it’s outside our research area.
The biggest open question in my mind at the end of the presentation was weather the tool can be (easily) applied to unit/integration testing implementations. The presentation clearly focused on the ability to integrate ith GUI-based applications, so it’s hopefully just a less glamorous version of the same underlying engine.

TODO or To Bug: Exploring How Task Annotations Play a Role in the Work Practices of Software Engineers

Authors: Margaret-Anne Storey, Jody Ryall, Ian Bull, Del Myers, Janice Singer
Paper: PDF will be available here some day
This research focused on the in-line comments that developers leave to themselves (and others) in the form of “TODO”, “FixMe”, and similar tags. I didn’t find the results particularly suprizing, but that might be due to wonderful presentation of the material. Again, this is outside my research area, but probably a paper that I’ll be reading to solidiy my pre-existing notions.

Below I’ve listed some of the paper presentations that I found interesting. Note that I say interesting not good/great. Before I say that any of these items are really great, I’ll read the paper first. So let’s just say that these papers are candidates to be good papers…

Time will Tell: Fault Localization using Time Spectra

Authors: Cemal Yilmaz, Amit Paradkar, Clay Williams (IBM T.J. Watson Labs)

This idea and the presentation were both rather interesting. The presenter claimed that method execution time could be used to localize defects in source code. The technique operated in two phases: 1) Using passing test cases, execution times are correlated with the execution times of other methods, then 2) a failing test case is run and then look for a execution time that is outside the coloration model.

When the time for questions came around, I think some people forgot that the technique was only for localizing errors that were known to exist rather than detecting errors outright. This lead to questioning how the technique compared to stack traces (complementary, esp. once the trace doesn’t immediately work) and questions about the specific technique for correlation (anything will work at first to prove the concept, better techniques can be used later).

Precise Memory Leak Detection for Java Software Using Container Profiling

Authors: Guoqing Xu, Atanas Rountev

At first, I found most of this presentation rather obvious. The idea that Java leaks memory (via objects) is well known. In order to leak them, they have to still be referenced, but not directly. The reference has to be somewhat anonymous, otherwise the object is “owned” by someone which (when applied recursively) means that it’s either active or a candidate for GC. The primary way to keep an object around without “owning” it is via some sort of container. (In my practice, the biggest memory leak in Java is actually String.subString()’s implementation detail, but that’s another topic)

Ok, so once we assume that most memory leaks are due to objects loosing their identity and ownership by being placed in a container, then this paper proposes a technique for figuring out which container in the application is holding the leaking objects. Basically, containers are ranked based on how much memory they (and their contents) consume through a deep traversal of the object graph. They are also ranked based on a staleness metric (see the paper for exact details) which measures how long an object hangs out in a container after it retrieved (via get).

On the surface it seems like a reasonable idea, but in practice I would expect many cases where containers are working as designed when they cache large objects for long periods of time. If (and how) the authors account for this will be interesting to find out.

Since it’s likely that I’ll be doing some development on my windows machine and some on Ubuntu boxes, I’m opting for an Eclipse-based development environment. Unfortunately, it’s not so trivial to get everything working together, so here I am with yet another guide to what I’ve done to get my setup working. I hope it helps someone else out there…

Eclipse and CDT

Downloading and installing Eclipse, and getting a couple “Hello World” apps up and going is the first step. Go do this and come back

OMNet Install

The OMNet install should be pretty straight forward. It’s likely that you’ll need to use the setup tool (cygwin:setup.exe, ubuntu:apt-get) again to install some missing packages, but the configure script it pretty good about telling you what you’re missing.

./configure
make

Omnet dependency: BLT

I never did get the developer extensions for BLT installed, but I did find an executable for BLT on the sourceforge site. This was close enough for me. I just dropped the (renamed) blt.exe into my bin directory that was already in my path.

Omnet dependency: giftrans

Again, I never did get this installed ‘correctly’, but I did find an executable version somewhere on the web and dropped it into my bin directory.

Omnet Verification

Ok, so now OMNet should be working, but we need to verify that first. Go to the tictoc sample and run it. This should work no problem.

cd samples/tictoc/
./tictock.exe or ./tictoc

Update OMNet to include debug information

Before going too much further, take a second now to edit the configure.user file. Uncomment this line:
CFLAGS='-g -Wall'" and
and comment out the others. Then recompile Omnet again to include these options.

./configure
make clean
make

Create the Eclipse Project

First, create a new project:

1. From the workbench, File -> New -> C++ Project
2. Project Name: tictoc
3. Project Type: Makefile project
4. Toolchain: — Other Toolchain –
5. Finish

Then we need to get the code in there… Copy the contents of the tictoc sample directory into the new tictoc directory under your eclipse workspace directory. Then clean it, just to be sure…

cd /c/dev/eclipse-workspace/tictoc
cp /c/bin/omnetpp-3.3/samples/tictoc/* .
make clean

If you try to build, eclipse will complain that there’s no rule to make target `all'. This is because eclipse by default tries to run “make all” rather then just “make”. Fix this:

1. From the workbench, Project -> Properties
2. On left: C/C++ Build
3. On Right: “Behaviour” tab
4. Clear the text field next to “build (incremental build)”
5. Ok

Now you should be able to build. Clicking the little hammer icon should cause the console to start scolling with make output, or report that `tictoc is up to date’.

Try debugging!

Before we start, throw a break-point on the send(msg, "out"); line of txc1.cc. When the debugger stops on this line, you’ll know you’re done.

Now, we need to set the binary parser option so that eclipse recognizes the executable that we are producing:

1. From the workbench, Project -> Properties
2. On left: C/C++ Build -> Settings
3. On Right: “Binary parsers” tab
4. Check the “Cygwin PE Parser” option
5. Ok

Now create the debug configuration:

1. From the workbench, Run -> Open Debug Dialog
2. On left: C/C++ Local Application
3. At the top: The ‘new’ icon
4. On Right: Project “tictoc”
5. On Right: C/C++ Application: “tictoc.exe” (hopefully this is filled in for you already)
6. Debug!

If you’re using Cygwin, you’ll likely run into the problem below. Otherwise, you should be done. Congrats!

Can’t launch debugger: …No symbol table is loaded…

(I think this only applies to Cygwin users)
This was the most aggravating bug to fix, mostly because the message boards all looked like this:

Newbie: I'm getting this error: ....
"Expert": Try gdb.
"Expert": Try the -g option
"Expert": Try google first, n00b!

Gee... you think I should google stuff before posting a question? Come on people. Turns out that the -s option to the linker is hard-coded into the opp_makemake script. The -s does the following:

Remove all symbol table and relocation information from the executable.

So, golly, it's OMNet's make files that are to blame... not the newbie... go figure.

So to fix this, you can either remove the option from Omnet's configure script (permanent), or you can always remember to remove it from the generated Makefile (not permanent). I opted for the later since (a) it'll be obvious when I forget and (b) my omnet install will be as standard as possible.

1. Open the generated Makefile in the tictoc directory
2. Find the line that defines "LDFLAGS"
3. Remove the option "-s"
4. Save
5. From the workbench, Project -> Clean...
6. From the workbench, Project -> Build Project
7. From the workbench, Click the debug button

First off, make sure that you have java installed and that you have your JAVA_HOME environment variable set. To check for java, just run java and see what happens. If there’s no program by that name, go install java…

You also want to make sure that your JAVA_HOME environment variable is set, and to make sure that there is no trailing “/” on the value. To check it: echo $JAVA_HOME

Download/Extract JSimpleModule

You can use these commands to download and extract JSimpleModule:

wget http://www.omnetpp.org/filemgmt/visit.php?lid=126
tar xzvf jsimplemodule-3.3-1.tgz


Attempt to build JSimpleModule

Nominally, the following is what you should have to do in order to compile the base JSimpleModule code. However, you will probably run into one of the two problems below. Repeat the last two steps until you can successfully compile these files.


cd jsimplemodule-3.3-1
cp makefrag.SAMPLE makefrag
opp_makemake -f
make


Script Error: Can’t open opp_makedep

if you get an error like this:

/bin/sh: Can't open opp_makedep
Error: command 'opp_makedep -Y --objdirtree -fMakefile -- *.cc' returned nonzero exit code

You’re probably using Ubuntu 6.10+. There’s a mailing list post that describes the problem (ubuntu changed the default shell). The easiest fix is like this:

cd /bin
sudo mv sh sh.orig
sudo ln -s bash sh

Compile Error: …SetBooleanField…

At this point, I started getting compile errors that looked something like this:

JUtil.cc: In member function â??void JObjectAccess::setBooleanJavaField(const char*, jboolean):
JUtil.cc:153: error: JUtil::jenv->JNIEnv_::SetBooleanField(((JObjectAccess*)this)->JObjectAccess::javaPeer, fieldID, ((int)value)) has type void and is not a throw-expression

I have yet to see any “official response”, but the fix seems to be to turning some of the in-line conditionals into full conditionals. Please see Nuno Alexandre Carvalho’s mailing list post for details on fixing this problem.

Get the example java simulations working

First thing to do is to get this working using the files that are provided. After that, we can start renaming and moving things around to make more sense. For now, just bare with me, ‘k.

The shell script “run” has the wrong line delimiters in it (it was created by a windows/dos machine). To fix this:

dos2unix run

This script calls a program “./yoursimulation”. This doesn’t exist in the directory, so we need to find it. Turns out that all we need is the executable that we compiled in the previous section. Since I don’t like extra copies of stuff hanging around and getting out-of-date, let’s just make a link:

ln -s ../jsimplemodule-3.3-1 yoursimulation

That should be all we need. Let’s try running it:

./run

And viola… the Omnet simulation windows open up (hopefully).

Can’t run: Core dump

This is another problem that Nuno Alexandre Carvalho’s mailing list post addresses. Go back to the jsimplemodule-3.3-1 directory and edit the file Makefile manually. Find the line that looks like this:

CFLAGS=-O2 ...

and make it look like this (by removing the “2” after “-O”

CFLAGS=-O ...

Then, from the command line, rebuild:

make clean; make

Can’t run: libjvm.so: cannot open shared object file…

This is an indication that your LD_LIBRARY_PATH environment variable isn’t setup quite right. In my LD_LIBRARY_PATH, I need to include /usr/lib/jvm/java-6-sun-1.6…/jre/lib/i386/client/. You may notice that this is smore eomewhat similar to the PATH variable set up in the run script, so I would actually recommend adding the following line to your run script:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$JAVA_HOME/jre/lib/i386/client

Make it pretty

At this point, you've got something that works, so it's time to make a backup copy!

Once you've done that, copy the example directory out of the jsimplemodule directory, and update the reference to "../simkernel.jar" in the run script. (I use another soft link in the same directory, but an environment variable or absolute path will work fine too) Then update the link "yoursimulation" to "jsimplemodule-3.3-1" or something similar, and update the last line in the run script to match.

Generally, the point of using RESTful patterns is to make the information easier to consume. For IBM (and a lot of programmers), "easy to consume" immediately spawns images of XML and automatically generated parsers or XStream or whatever. For me (and a lot of programmers), this same idea spawns ideas of .properties, JSON, flat text, and even HTML…

If you’re writing a web service to expose data to a customer, then shouldn’t you build in support for providing data in their format? After all, "easy to consume" is a valuable trait for data to support. In the interest of supporting the wide variety of people that will eventually be clambering at our door for data, let’s allow them to select their data format. So instead of using these URI’s:

http://luggagetracking.airlinecompany.com/bags/{id} http://luggagetracking.airlinecompany.com/flights/{id} http://luggagetracking.airlinecompany.com/travellers/{id}

RESTful SOA using XML

Add the little bit of extra code to expose these URI’s:

http://luggagetracking.airlinecompany.com/bags/{id}.xml http://luggagetracking.airlinecompany.com/flights/{id}.xml http://luggagetracking.airlinecompany.com/travellers/{id}.xml

http://luggagetracking.airlinecompany.com/bags/{id}.properties http://luggagetracking.airlinecompany.com/flights/{id}.properties http://luggagetracking.airlinecompany.com/travellers/{id}.properties

http://luggagetracking.airlinecompany.com/bags/{id}.html http://luggagetracking.airlinecompany.com/flights/{id}.html http://luggagetracking.airlinecompany.com/travellers/{id}.html

In the article above, we’re already shown how to use regular expressions to parse the interesting bits from the requested url, so switching to a different view based on a file name extension is fairly straight forward. For those of you who are more advanced, this file extension could be cross-referenced with the HTTP Accept header to provide even more complex format selection.

Now I know that some of you are likely responding with doubts. The most likely of these is that exposing the same data in different formats probably isn’t will be worth the investment… and it may not be. It’s unlikely that your web service will greatly benefit from exposing multiple data formats right out of the blocks. However, by building in the assumption that you will do so later, you (a) help guarantee that your view layer will indeed be separated from your model and controllers, and (b) lower the cost of future integration or migration projects.

That brings me to the motivating scenario that I have in my head… For the application my friend is developing, we need to be able to show lay-people what the service “looks like” to remote devices. Showing a machine-readable version of the service’s data to these people is silly. Even if XML was human readable (it’s not), the verbose overhead associated with it makes it relatively unattractive to look at. But HTML… now that (can) look good to people. By using an XML-based template when a .xml URL is requested, and a HTML-based template with a .html URL is requested, we can be friendly to the casual on-looker.

Down the line, we can also use this technique to help integrate test harnesses, debug views, and data documentation. For example, if the data provided by the service seems to be wrong, we take the request (http://foo.com/bar/baz.xml) and swap in .html for .xml and a host of documentation is included along with the data values. Request http://foo.com/bar/baz.debug-html and you get a host of debugging information as well. Whoa, cool.