Figure out when NXT has disconnected

[clintonb]

Hi Andy.

Hi,
We are currently discussing this via email. The problem with doing anything like this using libUSBX or kexts or whatever is who is going to get it working and maintain it. Very few of the leJOS developers have a Mac, and I'm not sure if those that do want to work at this low level. It took a very long time to get the fantom driver support working on the Mac and to be honest with you that is not an experience I'm keen to repeat...

I understand.

Whatever happens I suspect it is going to take some time., so in the short term it may be best to try and get things back to the state they were in the earlier release. It would seem that some sort of change in the leJOS code has broken things...

I was thinking along those lines, too.

Thank you very much for the reply -- I hope you and the other developers are able to see a good solution!

Cheers,
Clinton

[skoehler]

So on Windows, I did the following: I let your PC-side program run, then power on the NXT, and then power it off.
And here's what's happening after I power the NXT off: for me, the PC-side is actually tries forever to send the LCP command to the NXT. However, the fantom driver returns that zero bytes have been written, and this goes on forever.

Unfortunately, this might be due to a "bug" in the JNI wrapper library for the fantom driver. The fantom API return the number of bytes written, but also a status byte. This status byte is ignored right now. I have not been able to verify, that the status byte actually contains anything meaningful when the NXT has disconnected, however I will try that and then let you know whether it helped or not.

However, nothing in that area changed between 0.9.0 and 0.9.1. I still have to try with 0.9.0 though.

Update: I have modified the JNI wrapper so that the status byte is also considered. And in fact, a disconnect is now detected - well, if the disconnect happen before or during a write operation. Not sure what happens in case of a read operation. This has been tested on Windows only so far.

[skoehler]

I have uploaded a new snapshot to our SVN:
https://sourceforge.net/p/lejos/code/68 ... /snapshot/

Unfortunately, I can't rebuild the fantom JNI wrapper on OSX. Can you try this, Clinton?
https://sourceforge.net/p/lejos/code/68 ... k/jfantom/

P.S.: reading messages seems to be broken right now. Until I fixed it, simply query the NXTs version number of something like that.

[skoehler]

I managed to recompile the fantom JNI wrapper for OS X. When I had the chance to test it, I will update the snapshot with it.
Presuming, it works as nicely as under Windows, it should fix your problems, Clinton.

[skoehler]

Can you try the snapshot at http://svn.code.sf.net/p/lejos/code/trunk ? I have just committed revision 6886 which has a rebuilt libfantom.jnilib. The following program detected disconnects without a hassle when compiled and run with the snapshot:

Code: Select all

import java.io.IOException;

import lejos.nxt.remote.NXTCommand;
import lejos.pc.comm.NXTCommFactory;
import lejos.pc.comm.NXTConnector;

// The purpose of this application is to test when the NXT is connected or disconnected

public class ConnectionTest {

   private String nxtname = "";
   private String address = "";
   private int protocols = NXTCommFactory.USB; // | NXTCommFactory.BLUETOOTH;
   // / private NXTCommand nxtcommand = new NXTCommand(); /// use in leJOS
   // 0.9.0
   private NXTCommand nxtcommand; // / use in leJOS 0.9.1
   private NXTConnector nxtconnector = new NXTConnector();

   public void delay(int ms) {
      try {
         Thread.sleep(500);
      } catch (InterruptedException e) {
         // we are unlikely to be interrupted
         throw new RuntimeException(e);
      }
   }

   ConnectionTest() {
      boolean go_on = true;
      while (go_on) {

         // Connect to an NXT
         boolean connected = false;
         System.out.print("Connecting");
         while (!connected) {
            delay(500);
            System.out.print(".");

            try {
               connected = nxtconnector.connectTo(nxtname, address, protocols);
            } catch (java.lang.RuntimeException e) {
               System.out.println();
               System.out.println("RuntimeException occurred while trying to connect to NXT: ");
               e.printStackTrace(System.out);
            }
         }
         System.out.println(" Connected.");
         // nxtcommand.setNXTComm(nxtconnector.getNXTComm()); // use in leJOS 0.9.0
         nxtcommand = new NXTCommand(nxtconnector.getNXTComm()); // use in leJOS 0.9.1

         // Communicate with the NXT until we are disconnected
         try {
            System.out.println("Reading data: ");
            while (true) {
//               byte[] message = nxtcommand.messageRead((byte) 0, (byte) 0, true);
//               System.out.println("  message: "+message);
               String version = nxtcommand.getNXJFirmwareVersion();
               System.out.println("  version: "+version);
               delay(500);
//               byte[] b = nxtconnector.getNXTComm().read();
//               System.out.println(" len2: "+ b.length);
            }
         } catch (IOException e) {
            System.out.println("IOException occurred while reading messages:");
            e.printStackTrace(System.out);
         }
         try {
            nxtconnector.close();
         } catch (IOException e) {
            System.out.println("IOException during close:");
            e.printStackTrace(System.out);
         }
         System.out.println("Disconnected.");
         //goon=false;
      }
   }

   public static void main(String[] args) {
      new ConnectionTest();
   }
}

[clintonb]

Can you try the snapshot at http://svn.code.sf.net/p/lejos/code/trunk ? I have just committed revision 6886 which has a rebuilt libfantom.jnilib. ...

.

Sven,

this is fabulous. Thank you. It works great in my testing!

I'm so sorry that I didn't notice the additional replies to this thread. I had gone to some extra work for a work-around, but this is the proper solution and much better. I really appreciate it.

Oh, and by the way, I didn't realize how easy it was to check the firmware version. Thanks for showing me that -- now Enchanting checks and offers to flash your NXT if it isn't running the right firmware.

Cheers,
Clinton

[skoehler]

Oh, and by the way, I didn't realize how easy it was to check the firmware version. Thanks for showing me that -- now Enchanting checks and offers to flash your NXT if it isn't running the right firmware.

There's some possible trouble ahead:
The function getNXJFirmwareVersion only works when the NXT is running the original Lego firmware. We defined our own set of LCP commands, one is for getting a leJOS-specific firmware version. One of the problems is, that the Lego firmware doesn't report an error when we send an LCP command that it doesn't understand (e.g. the one for returning the leJOS firmware version) and the second problem is, that the leJOS LCP code pretty much doesn't check for errors returned by the NXT.
There is a non-leJOS specific method which is called getFirmwareVersion I believe (without NXJ), but it simply returns some dummy version so that an NXT running leJOS could potentially work with programs that expect the Lego firmware. Summing up, there is no easy way to detect whether the NXT is running leJOS or not.

I know about these problems, but simply haven't had the time to fix them yet. In particular, I plan on detecting whether the NXT runs leJOS or not upon connecting to it.

[clintonb]

This worked in my testing:

Code: Select all

      // Check for the right firmware version
      try {
         String version = nxtcommand.getNXJFirmwareVersion();
         System.out.println("Firmware version: " + version);
         if (!version.startsWith("0.9.1")) {
            narrowcastMsg(FIRMWARE_IS_WRONG_LEJOS);
         }
      } catch (IOException e) {
         lostConnection(true, "IOException occurred in while checking firmware version: " + e.getMessage());
      } catch (ArrayIndexOutOfBoundsException e) {
         System.out.println("NXT is not running leJOS.");
         narrowcastMsg(FIRMWARE_IS_NOT_LEJOS);
      }

('narrowcastMsg' is a function to send a message from the leJOS backend to the GUI front-end written in Squeak Smalltalk.)

I only tried it with:

LEGO's firmware, version 1.28
leJOS 0.9.0
and leJOS 0.9.1

but it works like a charm. A robot running LEGO's firmware doesn't understand the NXJ firmware message and I get an ArrayOutOfBoundsException.

(There is always a chance that some third-party firmware will cause this problems, but it works in the use cases I'm most concerned about).

Cheers,
Clinton

[skoehler]

A robot running LEGO's firmware doesn't understand the NXJ firmware message and I get an ArrayOutOfBoundsException.

That is basically a side effect of a broken code. In this case, the ArrayIndexOutOfBoundException basically indicates a programming error inside leJOS code. I don't remember the details what happens. But basically the LEGO firmware replies to the "get NXJ firmware version" command with some reply, that belongs to some other valid command. It does not return an error code like "I don't understand that command". That you get an ArrayIndexOutOfBoundsException is because we don't check that the LCP reply has proper length. If we would, we would certainly do a throw new LCPEXception("protocol error") or something like that, which is the more appropriate thing to do.

I believe that in the current API, there is no documented way (and thus no intended way) of identifying an NXT that is running the LEGO firmware. I'm saying this to avoid that you expect that this continues to work forever. For the moment, this might however work reliably. But from a programmer's point of view, you should NOT be happy about the current situation.

[clintonb]

I believe that in the current API, there is no documented way (and thus no intended way) of identifying an NXT that is running the LEGO firmware. I'm saying this to avoid that you expect that this continues to work forever. For the moment, this might however work reliably. But from a programmer's point of view, you should NOT be happy about the current situation.

Ouch. I hadn't realized my code was that brittle.

I'm going to go with this for now, realizing that it may bite me in the future, and when things change, I'll revisit it.

Thanks for the head's up!
Clinton