Paul René Jørgensen

Tonight I upgraded one of my Sun Spots to the new beta release of the blue firmware. One of the changes were an important bugfix in the UART code of the daughter board handling the UART buffers.

Anyway, after upgrading I wrote some test code to display the NMEA data from the GPS and guess what.. It worked!

        EDemoBoard edb = EDemoBoard.getInstance();
        edb.initUART(edb.SERIAL_SPEED_4800, edb.SERIAL_DATABITS_8, edb.SERIAL_PARITY_NONE, edb.SERIAL_STOPBITS_1);
        while(true) {
            try {
                System.out.print((char) edb.readUART(1000));
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

And the output (No fix. I was in my livingroom)..

Squawk VM Starting (blue-080718)...
$GPGGA,220058.000,,,,,0,00,50.0,,M,0.0,M,,0000*40
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPRMC,220058.000,V,,,,,,,080808,,*2A
$GPGGA,220059.000,,,,,0,00,50.0,,M,0.0,M,,0000*41
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPRMC,220059.000,V,,,,,,,080808,,*2B
$GPGGA,220100.000,,,,,0,00,50.0,,M,0.0,M,,0000*4C
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPGSV,3,1,12,03,67,195,,06,61,164,21,19,57,270,,18,48,083,17*71
$GPGSV,3,2,12,22,46,145,17,21,26,080,,08,20,318,32,15,20,030,*74
$GPGSV,3,3,12,26,17,013,,27,12,293,,07,11,282,,16,10,185,*71
$GPRMC,220100.000,V,,,,,,,080808,,*26

Sorry for not posting any progress on this for some days, but I’ve started in my new day job and have been pretty tired in the evenings. Hopefully this will change soon, but during some spare time tonight I was able to create the proper cable to be able to interface the GPS with the Sun Spot.

I just wanted you to see that tiny red light on the GPS indicating that it’s properly powered and connected to the Sun Spot. Now that I’ve prototyped all the hardware I’m ready to tackle the the real challenge, to code this bugger! That will be a lot of fun!

Just a reminder at the end. I hope to meet a lot of you guys at JavaZone, 17.-18. September in Oslo. I’ll be at the speakers dinner on the evening the 16, but hopefully we’ll get some time to grab a few beers and talk about old times during the conference..

I just wanted to let you know about todays progress. The GPS module landed in the mailbox this morning, but I forced myself not to rush and wire it up to the Spot right away. I know that this GPS module is compatible with the Spot so there was no reason to rush it.

What I was more concerned with was the enable/disable switch and the rudder pass through signal. I started out wiring up the RC receiver to the spot and wrote some lines of code to get the pulse length of a signal connected to one of the Dx pins of the Spot.

    private int getRCPulse() {
        EDemoBoard edb = EDemoBoard.getInstance();
        IInputPin pin = edb.getIOPins()[EDemoBoard.D3];
        return edb.getPulse(pin, true, 30);
    }

These few lines of code should give me the length of the pulse coming in on the D3 pin every 30 ms measured in microseconds. And guess what happened when I connected the battery? It worked!!

Next up was to prototype the rudder servo pass through. I added some more wires to the Spot connecting the servo signal cable to one of the Hx pins and made sure the servo was powered by the RC receiver.

        Servo s = new Servo(EDemoBoard.getInstance().getOutputPins()[EDemoBoard.H1]);
        while(true) {
            int l = getRCPulse();
            s.setValue(l);
            System.out.println(l);
            Utils.sleep(1);
        }

This code reads the rudder RC channel and passes the value on to the connected servo. Amazing as it sounds, but it actually works!

I now have a spot decoding the RC receiver signal and later outputting it to a connected servo, passing it through the spot as if it was not there! This is what is supposed to happen when the autopilot is disabled. When I hit the gear switch on my transmitter the autopilot logics should kick in. But that is another story..

Crazy me have been thinking about this for some time now. Those who know me know that I’m trying to make a part time business taking photographs from the air using RC model aircrafts. I have a dedicated page for some of the videos I’ve been making at http://paulrene.no/index.php/aerial-photography/. I even set up a page for my business at http://settfraluften.no (Norwegian only).

Anyway; During spring this year I got hold of a Sun Spot development kit and I’ve been playing around with it for a while. When writing a program to control servos using the built in accelerometer the idea struck me that this would be a nice platform for an autopilot. I’ve never worked in this field before so this is all new to me and a bit of a challenge. But if I can pull this of it would be a nice project and maybe something that would inspire others to do the same and improve it.

One of the first things I did was to assemble a list of parts:

• Sun Spot - http://www.sunspotworld.com
• Pressure sensor - MPX5100AP pressure sensor 15-115kPa
• GPS module - GPS-module EM-406a
• Headers - Stiftlist 2×10poler rak Au
• Gyro - MKS 380 Aeroplane Gyro

Along with this I need servos, RC receiver, wires and connectors.

The feature list as I see it just now will include:

• Way point navigation using rudder control
• Altitude hold
• Autopilot enable/disable using separate RC channel (landing gear channel)

I’ll continue to write about this as the project evolves. Stay tuned, this will be fun!

Aerial photography (AP) from radio controlled (RC) airplanes is one of my hobbies and I always seek to increase my toolbox and expand my operating radius. The other day I was browsing the shelfs at my local hardware store when I walked past this UHF antenna.

It immediately catched my eye and my brain started visualizing a how this pile of aluminum pieces could fit together creating a airplane. It was constructed from 2 long square tubed aluminum rods joined by a bracket. It would greatly simplify transportation if I could detach the 2 rods when driving to and from locations.

I did not use all the parts from the antenna as I needed only 2 “cross over” bars to work as a base to put the wing on. I could even remove the metal parts of them and leave only the black plastic pieces, but as I’ve overpowered this plane I ain’t too afraid of a little excess weight.

I removed the electronics from the connection box and fastened a carbon fiber landing gear. I can now easily fasten it to the aluminum rod and move it forward or backward depending on my load. Putting everything together from the antenna and landing gear I get this.

I then started on the elevator and rudder construction. I scaled the template for the Beasts/Solution (by Mike “Power”) to about 70% and dropped the carbon reinforcements on the lower side (I had no space for this).

Remaining work included assembling all the parts together, wire up the electronics and create a engine mount. I also had to add the servos for the elevator and rudder and cut a wing from a piece of EPS foam. If anyone is interested in how to cut their own foam wings please let me know, and I’ll consider doing a tutorial on it.

The finished plane with battery and receiver looks like this..

She had her first flight on 22. May, 2008 and it flew perfectly after some minor adjustments of the ESC and radio antenna mounts.

I’ve been passionate RC-pilot for the last year and started early on to attach my digital camera to the plane. I do a lot of videos from Bærum and I’ve now collected them on a single page to make them easier to find. And I do have a Aerial Photography license from Nasjonal Sikkerhets Myndighet, the Norwegian authority governing all data gathering from aerial sensors. Heavy stuff, but nice to have if someone makes a fuzz about it.

You’ll find all my videos on the Aerial Photography page. The link is located on the right side of the logo or you may click this link: http://paulrene.no/index.php/aerial-photography/

This is a small tutorial describing how to use a RC gear to trigger a Canon Camera loaded with the CHDK add on firmware. Using CHDK enables you to write scripts that can run triggered by a 4 volt current on the USB port of the camera.

List of parts:

• 1x old servo
• USB mini-B cable
• RC-transmitter
• RC-receiver

To make an remote controlled trigger I started by disassembling an old HXT 9g servo.

Be very careful not to destroy any of the wires. I removed all the gears, but kept the pot wires attached so I could adjust the center point.

I then removed the two green wires and used a multimeter to determine the polarity. Then I connected the wires to a spare USB mini-b connector.

There are 4 types of USB connectors. The Canon cameras using the Mini-B type. The pin descriptions according to Wikipedia are described in this table.

Connect the positive servo motor cable to pin 1 (red wire) and the negative motor cable to pin 4 (ground). You should check and double check your wiring using a multimeter. Attach a receiver and battery to your servo and test that giving you’ll get about 4.2 volts on one side of the stick and -4.2 volts on the other. Remember the correct stick movement to generate the positive voltage. If your transmitter is programmable, remove the stick movement that gives your the negative voltage or be very careful when using remote trigger.

Now it’s time to upload a script to your camera and check if it all work.

@title Remote button
:loop
wait_click 1
is_key k "remote"
if k=1 then shoot
goto "loop"
end

Create a file in /chdk/scripts/ folder of your SD card called remotetest.bas and enabled it in the scripting menu of the camera (after enabling the ALT-menu).

Attach the cables and power up the transmitter, receiver and servo. Hit the shutter button on the camera to start the script and then use the stick on the transmitter to trigger the running of the script.

Congratulations! You now have a non-mechanical way to trigger your CHDK enabled Canon camera.

I’ve been putting this off for too long, and I know a lot of people have been requesting this for a while, so here we go. I’ve split the tutorial in 2 parts. Part one cover finding the correct CHDK build and installing it on your camera, the second part is about scripting and building a remote USB trigger. The CHDK project is a firmware add on for Canon’s Digic II and Digic III cameras unleashing the hidden power in your cheap or medium priced camera such as RAW format, live histograms, Zebra mode, battery indicators and my personal favorite, scripting!

Part 1 - Finding the correct build and install it on your camera

First of all, the modifications we are about to do is not permanent. You may at any time disable or uninstall the CHDK firmware. By removing the write protection on your SD card you disable the auto load of CHDK. And by deleting the CHDK files from the SD card, you totally removes any traces of it. After getting used to CHDK, you’ll hardly want to remove it, but now it’s been said

CHDK’s home page is located at http://chdk.wikia.com/wiki/CHDK and this is where our search for the correct CHDK build starts. Every camera model need a different build of CHDK, because they all are a little different internally. Customizing CHDK for a new camera model is a complex and time consuming task, so I encourage you to show your gratitude by writing about it on their thank you page.

As of today (3. May, 2008) these are the supported (See the CHDK page for an updated list) cameras:

• A450, Fw: 1.00d
• A460, Fw: 1.00d
• A530, Fw: 1.00a
• A540, Fw: 1.00b
• A550, Fw: 1.00c
• A560, Fw: 1.00a
• A570, Fw: 1.00e, 1.01a
• A610, Fw: 1.00e, 1.00f, (1.00d with CHDK version for 1.00e)
• A620, Fw: 1.00f ( 1.00e is not compatible. You must upgrade to 1.00f first (see here))
• A630, Fw: 1.00c
• A640, Fw: 1.00b
• A650 IS, Fw: 1.00d
• A700, Fw: 1.00b
• A710 IS, Fw: 1.00a
• A720 IS, Fw: 1.00c
• S2 IS, Fw: 1.00e, 1.00f, 1.00g, (1.00i with CHDK version for 1.00g)
• S3 IS, Fw: 1.00a
• S5 IS, Fw: 1.01a 1.01b
• G7, Fw: 1.00e, 1.00g, 1.00i, 1.00j
• SD450 (IXUS55), Fw: 1.00b, 1.00c, 1.00d
• SD500 (IXUS700), Fw: 1.01a, 1.01b
• SD630 (IXUS65), Fw: 1.01a
• SD700 (IXUS800), Fw: 1.00b, 1.01b, (1.01a with CHDK version for 1.01b)
• SD800 (IXUS850), Fw: 1.00e, (1.00d with CHDK version for 1.00e)
• SD850 (IXUS950), Fw: 1.00c
• SD870 (IXUS860), Fw: 1.00c
• SD1000 (IXUS70), Fw: 1.01b, 1.02a, (1.01a with CHDK version for 1.01b)
• TX-1, Fw: 1.00g, 1.01b

The version number in green refers to the original firmware version of your camera. You need to now this to be able to find the correct CHDK build for your camera.

Locating the original firmware version of your camera

1. Create a file called ver.req in root directory of your SD card using a card reader and your computer. This could be an empty text file, but remember that the file extension must be .req for this to work
2. Put the card back into the camera and turn on the playback mode (Don’t turn it into rec mode first and then play, playback mode must be the first mode after power on)
3. Press and hold the SET button, then press DISPLAY while keeping both buttons pressed

If this is done correctly you’ll see a text string that looks like Firmware Ver GM1.00E. The “1.00E” is the firmware version you need to remember when downloading the CHDK for your camera. Note: Some cameras even support a file called vers.req that will allow you to even view more information about your camera.

Downloading CHDK

Go to http://chdk.wikia.com/wiki/Downloads and search for your camera. Download the version that matches the firmware version that you found in the last step.

Installing CHDK on your camera

1. Extract the PS.fir and Diskboot.bin files into the root directory of your SD card using your card reader and your computer
2. Put the SD card back into the camera

Enabling / Starting CHDK manually

1. Start the camera in playback mode
2. Press the MENU button
3. Go to the new menu entry called “Firm Update” (probably the last item in the menu list)
4. Select that item and confirm you want to update by selecting “OK”
5. The camera will now reboot and you’ll see CHDK’s splash screen when it boots up again

Auto enabling CHDK every time you turn on your camera

1. Enable CHDK manually as described above
2. Enter ALT mode
3. Press the MENU button to bring up the CHDK menu
4. Enter the “Debug Parameters” item
5. Select “Make Card Bootable”
6. Turn off the camera
7. Take out the SD card and write protect it
8. Put the card back and turn on your camera

CHDK will auto load every time you turn on your camera from now on. You may disable CHDK by turning off the write protection of the SD card.

Did you ever want to be the Big Brother of the Java Virtual Machine? Being able to do non intrusive monitoring of method calls without access to the source code, performing this in a production environment without a noticeable performance hit?

Do you want to know who is doing what to whom, that is, who invokes what method in context of which principal? Making certain that memory consumption is dynamically adjusted to avoid out of memory situations? Would you also like to use it in your legacy applications running pre Java 5 as well as utilize the new Java agent interface of the newer JVMs?

You know you have to collect vast amount of data and process it effectively and in real time. Finally you figure out that the amount of data exceeds the capabilities of a traditional data model and you decide that the only solution is a dimensional data model, using MDX for multi dimensional analysis.

There are numerous tools available for profiling and measuring your Java programs. However these tools are either: a) aimed at profiling or measuring your code in a development environment; b) expensive; c) not open source; d) requires a Ph.D. in debugging and profiling e) any combination of the above

Usemon attempts to alleviate this by providing an open source tool which is easy to use, collects data from environments based upon Java 1.4 through 6, has a flexible dimensional data model stored in a SQL database and attempts to be non-intrusive.

Usemon hooks into the Java virtual machine through a modified class loader on older JVMs or via the Java Agent Interface from version 5 and up. It automatically monitors Java EE components (EJBs, Servlets, MDBs, Queues, SQL Statements, etc), but can be configured to inspect any class in your JVM. Data is multicasted from agents to one or more collectors and stored in the DBMS of your choice. Usemon comes with a complete configuration for MySQL.

The overhead of running Usemon is negligible and thus you may collect run-time statistics around the clock all year, which is rather fascinating, given that you have enough disk space.

Usemon was developed for large Java EE environments at Telenor, which is one of the worlds largest telco to fulfill these requirements. You may utilize it in any environment in which you have control over the Java Virtual Machine start up parameters. For example Java EE applications, Spring based Web applications or simply your own home grown web application packaged in a .war file.

You may download or check out the source code at http://usemon.org

Prologue

Recently we experienced a problem regarding the RMI-compability between IBM WebSphere (WAS) version 5.1 and BEA WebLogic (WLS) version 8.3 both running a version 1.4.2 JVM. The WLS is a client of the WAS server and this worked fine since both the IBM and BEA RMI-implementation is based upon Sun’s RMI-ORB. Then an application came along that needed a custom login module and we had to enable security attribute propagation in WAS. All of a sudden hell broke loose, and the WLS was not able to speak with the WAS anymore. The problem was soon identified to be the wire format of the RMI-implementation. When you enable security attribute propagation, the wire format changes and WLS didn’t understand the WAS RMI response anymore.

The solution

In one way or the other I needed the RMI-implementation from WAS to work inside WLS. This is not an easy thing to do because a RMI-implementation register itself inside the JVM in several ways. I also wanted to hide the IBM classes from WLS to make sure I didn’t get any unexpected class ambiguities.

First I needed to just be able to call a EJB on a WAS server from a remote JVM. This was pretty easy and well documented from IBM. Since I didn’t need the support for DataSources or JMS resources I opted for the WebSphere pluggable client that only support EJB invocations. The following list includes the relevant WAS libraries needed to run the pluggable client.

"ibmext.jar", "ibmorb.jar", "iwsorbutil.jar", "naming.jar", "namingclient.jar", "properties.jar", "txClientPrivate.jar", "ras.jar", "wsexception.jar", "bootstrap.jar", "ecutils.jar", "iwsorb.jar", "ffdc.jar", "idl.jar", "txClient.jar"

The solution involved emulating the environment to let the IBM RMI-implementation believe it was running in a standard client JVM without knowing about BEA RMI and vica versa. I therefore created an IsolatingClassLoader that knew how to load the IBM client jars from the filesystem and not from the classpath. The same ClassLoader also knew what packages and classes it was supposed to isolate and to do the loading itself instead of delegating it to the parent ClassLoader.

  public class IsolatingClassLoader extends URLClassLoader {
    ...
    ...
    protected synchronized Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
      boolean isolated = isolatedClassNames.contains(name);
      if (!isolated) {
        for (int i = 0; i < isolatedPackagePrefixes.length; i++) {
          if (name.startsWith(isolatedPackagePrefixes[i])) {
            isolated = true;
            break;
          }
        }
      }
      if (isolated) {
        Class c = findLoadedClass(name);
        if (c == null) c = findClass(name);
        if (resolve) resolveClass(c);
        return c;
      }
    return super.loadClass(name, resolve);
  }
}

By doing this I isolated all com.ibm. packages and classes. Before doing the lookups I had to substitute the context ClassLoader of the current thread to ensure that classes was loaded with the IsolatingClassLoader and register the thread to ensure the correct UtilDelegate is used (More on that below). This was restored and unregistered in a finally clause right after doing the lookup and narrowing.

ClassLoader oldClassLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(isolatingClassLoader);
ThreadRegistry.getInstance().register();
try {
  InitialContext ctx = new InitialContext(jndiConfig);
  Object o = ctx.lookup(”iiop://wasserverhostname:2809/cell/clusters/mycluster/ejb/com/path/to/ejb/SomeEJBHome”);
  SomeEJBHome home = (SomeEJBHome) PortableRemoteObject.narrow(o, SomeEJBHome.class);
  return (SomeEJBRemoteHome) Proxy.newProxyInstance(getClass().getClassLoader(), new Class[] \\
     { SomeEJBRemoteHome.class }, new IBMIvocationHandler(home.create(), isolatingClassLoader));
} finally {
  ThreadRegistry.getInstance().unregister();
  Thread.currentThread().setContextClassLoader(oldClassLoader);
}

The java.naming configuration also needed modification to use IBM’s implementation and using the constructor of the InitialContext class I supplied my own naming configuration.

As you can see from the lookup code I was forced to not return the actual RemoteHome object but actually a proxied version. Inside the IBMInvocationHandler I had to do the ContextClassLoader manipulation and thread registering again to ensure that IBM classes was available during the remote EJB invocation.

public class IBMIvocationHandler implements InvocationHandler {
  private ClassLoader isolatingClassLoader;
  private Object remoteStub;

  public MetroIvocationHandler(Object remoteStub, ClassLoader isolatingClassLoader) {
    this.remoteStub = remoteStub;
    this.isolatingClassLoader= isolatingClassLoader;
  }

  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    ClassLoader oldClassLoader = Thread.currentThread().getContextClassLoader();
    Thread.currentThread().setContextClassLoader(isolatingClassLoader);
    ThreadRegistry.getInstance().register();
    try {
      return method.invoke(remoteStub, args);
    } finally {
      ThreadRegistry.getInstance().unregister();
      Thread.currentThread().setContextClassLoader(oldClassLoader);
    }
  }
}

We have soon reached our goal, but one nasty obstacle is standing between ourselves and a solution. That is the javax.rmi.CORBA.Util class that holds a private reference to a singleton implementing the javax.rmi.CORBA.UtilDelegate inteface providing utility methods that can be used by stubs and ties to perform common operations. The implementation is defined by a system property (javax.rmi.CORBA.UtilClass) and is initialized during VM startup. We could simply have replaced the private field containting the UtilDelegate with IBM’s implementation (com.ibm.ws.orb.WSUtilDelegateImpl), but then BEA’s RMI-implementation would get into trouble and we would see some really unbelievable exceptions ;-). Instead I created a proxy version of the UtilDelegate that chooses between the original and IBM’s implementation depending on which RMI-implementation that was using it. The ThreadRegistry uses a WeakHashMap to store the current Thread to identify which Thread is coming through IBM code or BEA RMI code.

public class UtilDelegateInvocationHandler implements InvocationHandler {
  private UtilDelegate original;
  private UtilDelegate ibm;

  public UtilDelegateInvocationHandler(UtilDelegate original, UtilDelegate ibm) {
    this.original = original;
    this.ibm = ibm;
  }

  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    iif(ThreadRegistry.getInstance().isRegistered()) {
        return method.invoke(ibm, args);
      else
       return method.invoke(original, args);
  }

}

The proxied UtilDelegate was installed using the reflection API and required that Java2 Security allowed my class to modify the accessible flags.

UtilDelegate ibmUD = (UtilDelegate) \\
      isolatingClassLoader.loadClass("com.ibm.ws.orb.WSUtilDelegateImpl").newInstance();
Class c = Class.forName("javax.rmi.CORBA.Util");
Field ff = c.getDeclaredField("utilDelegate");
ff.setAccessible(true);
UtilDelegate originalUD = (UtilDelegate) ff.get(null);
UtilDelegate proxyUtilDelegate = (UtilDelegate) Proxy.newProxyInstance(getClass().getClassLoader(), \\
      new Class[] { UtilDelegate.class }, new UtilDelegateInvocationHandler(originalUD, ibmUD));
ff.set(null, proxyUtilDelegate);

Conclusion

After doing this we could successfully use both RMI-implementations interchangably inside the WLS server and finally invoke EJBs running inside a WAS cluster with the security attribute propagation enabled.

Source Code

You may download the complete source code: was-client-inside-wls-updated-src

Update: 2. May, 2008

After beeing challange by Asgeir Nilsen I came up with a much improved way of determining which UtilDelegate implementation to use. In the old version I parsed the stack trace, but in this new and improved version I register the Thread in a singleton instead. The source archive has been updated to reflect this change.