nxtcommand-developers

[Nxtcommand-developers] icommand.nxtcomm.bluez

[Peter J. <ptg...@ch...>]

Hi all,

I have been working lately on a java jni binding to BlueZ, the Linux
bluetooth stack.
Reason for this experiment, has been my experience with RXTX: when I run
into an error
situation its hard to get out of that situation and setup a new connection.

The jni binding has been tested with some sample Java programs running
the DIRECT commands 0x00 until including 0x04. It's remarkably stable.

You may start a Java program, notice your brick is not turned on, correct
the situation,
and as long as there is no timeout, your program starts after making a
connection. This
once happened accidentally, and has been tested more times for the fun of it
:-) I also
didn't have any trouble so far setting up a new connection after abortion
willingly or not
of a program. Ok, so far the selling the story.

Proposal:

I like to setup an area in subversion icommand-sandbox at the same level as
icommand-projects. icommand-sandbox is a playing ground for things that may
be integrated
in a future release. icommand-projects is for development, working on a new
release.

There will be 2 projects in the sandbox:
icommand-bluez (eclipse, java)
==============================
- java sources in package icommand.nxtcomm.bluez
   - class icommand.nxtcomm.bluez.NXTCOMM
   this is an alternative to icommand.nxtcomm.NXTCOMM
   so an end user, switching from RXTX to BlueZ (and back) only has to
change
   1 import statement in his code.

   There is 1 issue however. The NXTCOMM.open() is run from a static
initalizer block
   in the NXTCommand class. This makes it "impossible" to not use RXTX. My
proposal is
   to remove the static initalizer block, and make NXTCOMM.open() part of
the api.
   This means end users have to explicitly use NXTCOMM.open(). They already
have to use
   NXTCOMM.close(), introducing NXTCOMM.open() will only lead to a more
logically
   program structure (my personal opinion). Note: for the time being ALL
changes
   will only be happening in icommand-sandbox, also this api change.

icommand-bluez-native (eclipse CDT, c)
======================================
How about the name of the native library?
Proposal: libicmdbluez.so

If some C programmer will have a look at my C code, that I would really
appreciate.
Memory leaks, programming standards, ...
I have never done some serious C/C++ programming (before)
Brian, maybe someone of the lejos project can have a look?

Please let me know what you think about it. Shall I commit things to
icommand-sandbox,
when I am ready, then you all can have a look. I do not know if
icommand-sandbox and
icommand-projects will have separate revision numbers. There is 1 way to
find out.
Is this an issue ? (What's the alternative)

===

Now some other topic. For some time I want to setup a project making an
explorer like
NXT robot communicating with its base. That's how I run into ICommand and
got involved.
I like to setup a website to document the project and distribute the
software (Open Source).
The only common denominator (?) with icommand will be this java bluez
interface.
(I hope my english is correct).

I like to make the java bluez interface a part of lejos, but also want to
distribute it
as part of a software product from my website. I do not hope that
contributing the code
to icommand, implies loosing my rights to do so. Any comments ? What if my C
code is
significantly improved by some other Icommand developer? I am always willing
to give
credit to who it belongs. Now I know, why I never did have any aspirations
to become a layer.

I want to be honest, so telling this beforehand, seems the rigth thing to
do.

Peter Joosten.

Re: [Nxtcommand-developers] icommand.nxtcomm.bluez

[Brian B. <bba...@mt...>]

Hi Peter,

> Proposal:
>
> I like to setup an area in subversion icommand-sandbox at the same level 
> as
> icommand-projects. icommand-sandbox is a playing ground for things that 
> may
> be integrated
> in a future release. icommand-projects is for development, working on a 
> new
> release.

You don't have to be timid about making changes to the iCommand code. If you 
have something that is working just throw it in subversion. Consider your 
own PC as the sandbox to play around with code, and then commit changes to 
subversion when they are working or somewhat working.

> There will be 2 projects in the sandbox:
> icommand-bluez (eclipse, java)
> ==============================
> - java sources in package icommand.nxtcomm.bluez
>   - class icommand.nxtcomm.bluez.NXTCOMM
>   this is an alternative to icommand.nxtcomm.NXTCOMM
>   so an end user, switching from RXTX to BlueZ (and back) only has to
> change
>   1 import statement in his code.

I had an email from someone who changed the code to use the Java comm API so 
he could run it on his handheld with Windows Mobile. That got me thinking 
that we should add another optional variable to the property file to choose 
which serial package you want to use. We could have RXTX, Java 
Communications API, Bluez, and even possibly the Lego Fantom driver. This 
would let us test and compare to see which works best.

So rather than a package for each, we could just make an interface called 
NXTComm with the relevant read and write methods, then have BluezNXTComm, 
RXTXNXTComm, etc... The code could default to the best/most common one but 
if the variable exists then use the appropriate object.

>   There is 1 issue however. The NXTCOMM.open() is run from a static
> initalizer block
>   in the NXTCommand class. This makes it "impossible" to not use RXTX. My
> proposal is
>   to remove the static initalizer block, and make NXTCOMM.open() part of
> the api.
>   This means end users have to explicitly use NXTCOMM.open(). They already
> have to use
>   NXTCOMM.close(), introducing NXTCOMM.open() will only lead to a more
> logically
>   program structure (my personal opinion). Note: for the time being ALL
> changes
>   will only be happening in icommand-sandbox, also this api change.

open() and close(0 sound good. It would also let the programmer control when 
they want that 5 second handshaking delay to occur.

A user named Rojit from the leJOS mailing list says he got more than one NXT 
brick working with iCommand but then I changed it to singleton static method 
calls to match leJOS (i.e. Motor.A.forward() instead of 
nxt.motorA.forward() ). Not many people have multiple NXT bricks but if it's 
possible to control more than one through Bluetooth we should implement it 
somehow. If we do use multiple instantiations, we could do away with open() 
and close() althogether. People seem to favor the commands that match leJOS 
though. I'm not really sure what to do.

> icommand-bluez-native (eclipse CDT, c)
> ======================================
> How about the name of the native library?
> Proposal: libicmdbluez.so
>
> If some C programmer will have a look at my C code, that I would really
> appreciate.
> Memory leaks, programming standards, ...
> I have never done some serious C/C++ programming (before)
> Brian, maybe someone of the lejos project can have a look?

You could ask Lawrie Griffiths if no one on this project can do it. He's 
pretty busy with leJOS NXT though.

> Now some other topic. For some time I want to setup a project making an
> explorer like
> NXT robot communicating with its base. That's how I run into ICommand and
> got involved.
> I like to setup a website to document the project and distribute the
> software (Open Source).
> The only common denominator (?) with icommand will be this java bluez
> interface.
> (I hope my english is correct).
>
> I like to make the java bluez interface a part of lejos, but also want to
> distribute it
> as part of a software product from my website. I do not hope that
> contributing the code
> to icommand, implies loosing my rights to do so. Any comments ? What if my 
> C
> code is
> significantly improved by some other Icommand developer?

iCommand is under the GNU GPL so anyone can take the open source code, 
modify it and redistribute it. I think the major limitation is that you 
aren't allowed to sell it or something like that, and it has to remain open 
source so everyone can see the code. I'm not an expert on GPL but that's 
what I got out of it.

- Brian