nxtcommand-developers — Forum for developers to discuss changes and improvements to iCommand.

[Nxtcommand-developers] test (sorry)

[Stefano S. <ger...@ti...>]

sorry, it seems every message I send to the mailing list comes back to 
me... :-(

-- 
Stefano Sanna - ger...@ti...
Personal web site: http://www.gerdavax.it
AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE

Best of Banana

Fratelli D'Etails

Gerda: "Mi hanno contattato per avere idee nuove..."
Dada:  "... e le vanno a chiedere proprio a te???"

Re: [Nxtcommand-developers] CLDC

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

>I have just installed netbeans with icommand, and it would be running, if
>I didn't get the infamous "gnu.io.PortInUseException" :-( at the moment.

I really start to dislike rxtx :-(

Netbeans is just an IDE.
You only have to make icommand a library of your project within Netbeans.
The program starts, but fails because of rxtx.

I have put rxtx in the java extension library. You can put icommand also
there, instead of configuring it as a library within you netbeans project.

Peter Joosten.

By the way: I am more an Eclipse user than Netbeans. My Netbeans experience
is
level "rookie". I do like however the Mobility pack. Build some simple
program
for my phone http://developer.motorola.com/ My phone doesn't support JSR-82
:-(

Peter.



>
> I don't know much about Netbeans, but do we need to create
> seperate classes
> to work with Netbeans? If anyone knows, please speak up. Or does he just
> want tech support to allow regular iCommand code to work within an IDE? I
> was thinking Netbeans was a whole new thing, like JavaBeans.
>
> - Brian
>

Re: [Nxtcommand-developers] iCommand/NetBeans

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

>From this message of Vic I understand he only wants to be make his own
programs using the icommand library and run them from within netbeans.

Peter Joosten.

> -----Original Message-----
> From: nxt...@li...
> [mailto:nxt...@li...]On Behalf Of
> Vic Wintriss
> Sent: Wednesday, November 08, 2006 5:56 PM
> To: nxt...@li...
> Subject: [Nxtcommand-developers] iCommand/NetBeans
>
>
> Brian:
>
> I don't think that I want anything done to NetBeans.  AllI want is to
> be able to launch programs that use  iCommand via NetBeans.
>
> Since NetBeans uses a different environment than the shell, I think
> it just a matter of knowing how to set up the environment variables
> for NetBeans to properly handle iCommand.
>
> I am able to write and run programs using iCommand from my Mac Pro
> from bash, but cannot run the same program from bash on my MacBook or
> iMac (all Intel Macs)...nor can I run the same program from NetBeans
> in any computer.
>
> Vic Wintriss
> vi...@wi...
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxt...@li...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

Re: [Nxtcommand-developers] Samples and Resources

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

This also does not work because if you run the sample from within
eclipse the file is looked for in the root directory of the
icommand-samples project. But, ...

I think I have found a / the solution:

Run the sample as java program. This will fail, because the file is not
found. But what we have achieved: a run configuration is created.

Now edit the run configuration:
- Right click sample
- popup menu:Run As - Run ...
- In the run configuration window:
  - select the run configuration of the sample,
  - choose tab Arguments 
  - set radio button of working directory to: Other
  - click button workspace
  - select the direcory: src/main/resources
  - click button run

(It takes more time to describe, than to perform this actions)

Now the sample runs correct. the run configuration is saved.
the next time you can choose the run the sample from the run menu on the
toolbar. 

If you do not see the sample in the run menu, edit the runtime
configuration again. In the run configuration window, select tab Common,
Option 'display in favourites menu', click options 'run' and 'debug'

Peter Joosten.


On Fri, 2006-11-24 at 18:35 -0600, Brian Bagnall wrote: 
> What do you think about putting each sample project in its own subdirectory? 
> Most will have only one file, the source file.
> 

Re: [Nxtcommand-developers] iCommand Netbeans

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

Hi Vic,

Sorry for the delay. I've had a busy and maddening week.

> Any word on getting iCommand working with NetBeans?  My offer for the 
> sensors is still good.

We're still coming to grips with NetBeans. At first we thought you wanted 
some special classes to work with NetBeans that were like JavaBeans, but I'm 
starting to think you just want iCommand to work in an IDE called NetBeans?

> Awhile back you said that you were coming out with a new release  soon. 
> Status?

That was version 0.5, released October 30:
www.lejos.org

> To do some of my own testing, I'd like to write a simple program that 
> calls on a method in NXTComm.  I don't think I even get past open().
>
> With this simple program:
>
> package nxtbttest;
>
> import icommand.nxtcomm.*;
> import icommand.platform.nxt.*;
>
> public class Main
> {
>         public static void main(String[] args)
>         {
>             UltrasonicSensor us = new UltrasonicSensor(Sensor.S1);
>         }
> }
>
> I get the following when I try to run it:
>
> init:
> deps-jar:
> Compiling 1 source file to /Users/vwpro/NxtBtTest/build/classes
> compile:
> run:
> java.lang.Exception: NXTCOMM is not defined as a system Environment 
> Variable
> NXTCOMM = null
>         at icommand.nxtcomm.NXTComm.open(NXTComm.java:46)
> Error while connecting NXTCommand() constructor
>         at icommand.nxtcomm.NXTCommand.<clinit>(NXTCommand.java:16)
>         at icommand.platform.nxt.Sensor.setTypeAndMode(Sensor.java:32)
>         at icommand.platform.nxt.I2CSensor.<init>(I2CSensor.java:20)
>         at icommand.platform.nxt.UltrasonicSensor.<init> 
> (UltrasonicSensor.java:13)
>         at nxtbttest.Main.main(Main.java:10)
> Exception in thread "main" java.lang.NullPointerException
>         at icommand.nxtcomm.NXTComm.sendData(NXTComm.java:105)
>         at icommand.nxtcomm.NXTCommand.sendRequest(NXTCommand.java:617)
>         at icommand.nxtcomm.NXTCommand.setInputMode(NXTCommand.java: 401)
>         at icommand.platform.nxt.Sensor.setTypeAndMode(Sensor.java:32)
>         at icommand.platform.nxt.I2CSensor.<init>(I2CSensor.java:20)
>         at icommand.platform.nxt.UltrasonicSensor.<init> 
> (UltrasonicSensor.java:13)
>         at nxtbttest.Main.main(Main.java:10)
> Java Result: 1
> BUILD SUCCESSFUL (total time: 0 seconds)

It's best to use the code samples in the samples directory rather than 
trying to interact with the low-level NXTComm class. The sample code shows 
the common ways to use iCommand.

That aside, I can see from the output that the environment variable NXTCOMM 
is not set to the COM port your Macintosh is using for serial Bluetooth. The 
readme file has some important information on this in section 2.2.2. I'm not 
very happy with the organization of the readme but it's all we have at the 
moment.

- Brian

> I paid Sun to trouble shoot it for me, but they gave up because there  was 
> too much code behind the problem.  Perhaps if I made it real  simple for 
> them, they might be able to fix it.
>
> Vic
>
>
> On Nov 12, 2006, at 8:03 PM, Brian Bagnall wrote:
>
>> Hi Vic,
>>
>> Your message (and all other messages you send) was posted to the 
>> developer list. Stefano Sanna said he would be interested in  developing 
>> the NetBeans but I don't think he's going to do anything  until next 
>> week. We'll let you know when we have something to test  out.
>>
>> - Brian
>>
>> ----- Original Message ----- From: "Vic Wintriss" <gv...@sa...>
>> To: "Brian Bagnall" <bba...@mt...>
>> Sent: Sunday, November 12, 2006 8:59 PM
>> Subject: Re: iCommand Netbeans
>>
>>
>>> Brian:
>>>
>>> Any progress?
>>>
>>> I sent the info to the address below.
>>>
>>> Vic
>>>
>>> On Nov 8, 2006, at 8:22 AM, Brian Bagnall wrote:
>>>
>>>> Hi Mr. Wintriss,
>>>>
>>>> One of our developers Stefano Sanna is interested in adding  Netbean 
>>>> functionality to iCommand. Can you please give us some  more details 
>>>> about what you want done with Netbeans?
>>>>
>>>> BTW: Please reply to nxt...@li...  so 
>>>> all the developers are in the loop.
>>>>
>>>> - Brian
> 

Re: [Nxtcommand-developers] CLDC

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

> From one of the previous mails I understand that Vic only wants to be
> able to write and run icommand programs from within Netbeans. He does
> not any new Netbeans mode to be written. My 1st tought is "easy money",
> but I may be wrong. I can have a look into this, but I do not want to
> get into a race with Stefano for the sensor "trofee".

I don't know much about Netbeans, but do we need to create seperate classes 
to work with Netbeans? If anyone knows, please speak up. Or does he just 
want tech support to allow regular iCommand code to work within an IDE? I 
was thinking Netbeans was a whole new thing, like JavaBeans.

- Brian 

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

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

Hi Stefano,

I'm a little confused about what our goal is for CLDC integration. Are you 
basically uploading iCommand code directly to Windows Mobile devices and 
running it from there, without the PC taking any action once the cell phone 
device takes command of the NXT?

If that is the case, maybe the best thing to do would be to use the NXTComm 
interface, creating NXTCommCLDC. The user can choose to use CLDC via the 
icommand.properties file setting. So far we have NXTCommRXTX, NXTCommBluez, 
and NXTCommSun (using the Java Communications API). It looks like your 
changes to the code are exclusively in the NXTComm class.

BTW Do you develop and compile the code on a PC and then upload it to your 
cell phone? How does the code get uploaded to your cell phone?

- Brian

----- Original Message ----- 
From: "Stefano Sanna" <ger...@ti...>
To: <ptg...@ch...>
Cc: "iCommand Developers" <nxt...@li...>
Sent: Friday, November 24, 2006 1:13 PM
Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2


> Hi Peter, hi all.
>
> Peter Joosten wrote:
>> We could icommand CLDC into a seperate project in subversion.
>> But how about the next idea ?
>>
>> We could use a java preprocessor, and integrate the code into the
>> "standard" icommand project. This works just like C/C++ #define,
>>  #ifdef #end-if, ...
>>
>> 1. Benefits:
>>    Prevents duplicate code. So we only have to maintain 1 source tree.
>> 2. Possible draw back:
>>    You have to generate the source code for a specific platform by the
>>    preprocessor, before it can be run. (But thats the way C programmers
>>    work all the time)
>>
>> Preprocessing can be done by an Ant target of de build.xml
>
> [...]
>
> From my point of view, porting from JSE to JME is not an automatic
> task, it a creative work. The developer has to substitute classes of
> standard edition with the (more or less) equivalent of micro edition,
> how event he/she has to optimize code if necessary. Moreover, JME
> version will be split into specialized versions for different kind of
> devices. For instance, current version of JNXT works on Windows Mobile
> devices and has a pen-based input; upcoming version for Symbian OS will
> be joypad based: the two versions will be managed through the
> configuration manager of Netbeans, which has been design to handle this
> kind of specific issues of JME development.
>
> I suggest to keep the two separate projects: iCommand and iCommand_CLDC.
> The more iCommand gets enhanced, the more we will have to carefully port
> it to CLDC.
>
> Best regards,
> Stefano.
>
> -- 
> Stefano Sanna - ger...@ti...
> Personal web site: http://www.gerdavax.it
> AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE
>
> Best of Banana
>
> Fratelli D'Etails
>
> Gerda: "Mi hanno contattato per avere idee nuove..."
> Dada:  "... e le vanno a chiedere proprio a te???"
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxt...@li...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers
> 

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

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

> > 
> > Preprocessing can be done by an Ant target of de build.xml
> 
> [...]
> 
>  From my point of view, porting from JSE to JME is not an automatic 
> task, it a creative work. The developer has to substitute classes of 

I agree it can not be automated. That was not the argument. My goal
was to prevent duplicate code. The suggestion was to use 1 "master"
source tree with preprocessor macros, from which the several platform
dependend source code can be generated. This is an automated process.
You still wil have to program ALL the code between the macros yourself. 

#define CLDC

#ifdef CLDC
// CLDC
int lastPos = name.toString().indexOf(".") + 4;
//CLDC
#else
// CLDC UNSUPPORTED
// int lastPos = name.indexOf(".") + 4;
// CLDC UNSUPPORTED
#endif

Generated source:
// CLDC
int lastPos = name.toString().indexOf(".") + 4;
//CLDC

> standard edition with the (more or less) equivalent of micro edition, 
> how event he/she has to optimize code if necessary. Moreover, JME 
> version will be split into specialized versions for different kind of 
> devices. For instance, current version of JNXT works on Windows Mobile

You are the better judge of how much code can be reused, and if this is
a usefull suggestion, or not. The more platforms that will be supported,
the greater the risk of cluttering the source code with macro statements.

> I suggest to keep the two separate projects: iCommand and iCommand_CLDC. 

I have no objections.

> The more iCommand gets enhanced, the more we will have to carefully port 
> it to CLDC.

That's why I suggest to keep as much code as possible platform independend.
If this is feasible ? For the GUI layer and bluetooth interface it is not.

Peter Joosten.

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Stefano S. <ger...@ti...>]

Hi Peter, hi all.

Peter Joosten wrote:
> We could icommand CLDC into a seperate project in subversion.
> But how about the next idea ?
> 
> We could use a java preprocessor, and integrate the code into the
> "standard" icommand project. This works just like C/C++ #define,
>  #ifdef #end-if, ...
> 
> 1. Benefits:
>    Prevents duplicate code. So we only have to maintain 1 source tree.
> 2. Possible draw back:
>    You have to generate the source code for a specific platform by the
>    preprocessor, before it can be run. (But thats the way C programmers
>    work all the time)
> 
> Preprocessing can be done by an Ant target of de build.xml

[...]

 From my point of view, porting from JSE to JME is not an automatic 
task, it a creative work. The developer has to substitute classes of 
standard edition with the (more or less) equivalent of micro edition, 
how event he/she has to optimize code if necessary. Moreover, JME 
version will be split into specialized versions for different kind of 
devices. For instance, current version of JNXT works on Windows Mobile 
devices and has a pen-based input; upcoming version for Symbian OS will 
be joypad based: the two versions will be managed through the 
configuration manager of Netbeans, which has been design to handle this 
kind of specific issues of JME development.

I suggest to keep the two separate projects: iCommand and iCommand_CLDC. 
The more iCommand gets enhanced, the more we will have to carefully port 
it to CLDC.

Best regards,
Stefano.

-- 
Stefano Sanna - ger...@ti...
Personal web site: http://www.gerdavax.it
AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE

Best of Banana

Fratelli D'Etails

Gerda: "Mi hanno contattato per avere idee nuove..."
Dada:  "... e le vanno a chiedere proprio a te???"

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

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

Message was bounced. Try again.
See previous message

> -----Original Message-----
> From: Peter Joosten [mailto:ptg...@ch...]
> Sent: Friday, November 24, 2006 6:27 PM
> To: Stefano Sanna; iCommand Developers
> Subject: RE: [Nxtcommand-developers] iCommand 0.5 CLDC pre2
>
>
> We could icommand CLDC into a seperate project in subversion.
> But how about the next idea ?
>
> We could use a java preprocessor, and integrate the code into the
> "standard" icommand project. This works just like C/C++ #define,
>  #ifdef #end-if, ...
>
> 1. Benefits:
>    Prevents duplicate code. So we only have to maintain 1 source tree.
> 2. Possible draw back:
>    You have to generate the source code for a specific platform by the
>    preprocessor, before it can be run. (But thats the way C programmers
>    work all the time)
>
> Preprocessing can be done by an Ant target of de build.xml
>
> I do not now if there will be an issue with the IDE (Eclipse) not
> recognizing the preprocessor macros, resulting in Java error codes,
> or maybe there is a plugin that fixes this. Also not sure of the
> drawback, because this is dependend on the preprocessor product
> where going to use.
>
> ========================================================================
> I am willing to look into this, if you agree with the gerenal idea using
> a preprocessor and integrating icommmand cldc into the existing project.
> ========================================================================
>
> I can make a diff between "standard" and cldc icommand to decide where
> to put the preprocessor commands. Generate the code for both platforms,
> and diff generated sources with supplied sources  for both plaforms to
> verify correctness.
>
> Peter Joosten.
>
>
>
>
>
>
> > -----Original Message-----
> > From: nxt...@li...
> > [mailto:nxt...@li...]On Behalf Of
> > Stefano Sanna
> > Sent: Friday, November 24, 2006 7:21 AM
> > To: iCommand Developers
> > Subject: [Nxtcommand-developers] iCommand 0.5 CLDC pre2
> >
> >
> > Hi all.
> >
> > I've just uploaded the pre2 version of iCommand 0.5 for CLDC. It solves
> > some issues with properties initialization.
> >
> > You can find it at:
> >
> > http://www.esnips.com/doc/ae3ba49a-e1a7-4da5-8568-b7580bdde921
> >
> > Brian, once iCommand for CLDC is stable we may put it into sourceforge
> > repository. Is it ok?
> >
> > Best regards,
> > Stefano.
> >
> > --
> > Stefano Sanna - ger...@ti...
> > Personal web site: http://www.gerdavax.it
> > AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE
> >
> > *** Solo chi non fa niente non sbaglia ***
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxt...@li...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

[Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Stefano S. <ger...@ti...>]

Hi all.

I've just uploaded the pre2 version of iCommand 0.5 for CLDC. It solves 
some issues with properties initialization.

You can find it at:

http://www.esnips.com/doc/ae3ba49a-e1a7-4da5-8568-b7580bdde921

Brian, once iCommand for CLDC is stable we may put it into sourceforge 
repository. Is it ok?

Best regards,
Stefano.

-- 
Stefano Sanna - ger...@ti...
Personal web site: http://www.gerdavax.it
AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE

*** Solo chi non fa niente non sbaglia ***

Re: [Nxtcommand-developers] CLDC

[Stefano S. <ger...@ti...>]

Hi Brian,

hi all! :-)

Brian Bagnall wrote:
> Hi Stefano,
> 
> Just wondering how you are coming along with the CLDC code?

CLDC porting of iCommand 0.5... is here!

I'm very sorry for this (very) late reply, but moving from Sardinia
island to Rome had some drawbacks (some of them still to be solved...).

Please, find a preliminary version of iCommand at:

http://www.esnips.com/doc/58c447a6-b0bc-4eda-9a73-29d3c0bc0768/icommand-0.5_CLDCpre1.zip

I've tried to send it to the mailing list but the message was refused. 
The version is called icommand-0.5_CLDCpre1 since it has been partially 
ported to CLDC

Details:

1) JNXT (the gesture-based controller) has not been updated to iCommand
0.5; therefore I was not able to test it extensively;

2) vision package has been removed

3) ServoNavigator has been removed: I'm looking for a *easy* math
library fof j2me (let me say, a mix between pure-java MIDP 1.0 approach
and MIDP 2.0 float-enabled).

Item (1) means that icommand-0.5_CLDCpre1 compiles for CLDC but I still
have to complete tests. Tomorrow I'll send you the JNXT updated version
(for Windows Mobile) and a fully tested version of iCommand_CLDC.

Note about porting:

a) portions of code not compatible with CLDC have been commented and
marked as follows:

// CLDC UNSUPPORTED
/*
Here is the JSE code! :-)
*/
// CLDC UNSUPPORTED

b) code that substitutes or integrates JSE code has been commented and
marked as follows:

// CLDC
// Here is the code for CLDC! :-)
// CLDC

For instance, in NXTCommand you will find:

// CLDC UNSUPPORTED
// int lastPos = name.indexOf(".") + 4;
// CLDC UNSUPPORTED

// CLDC
int lastPos = name.toString().indexOf(".") + 4;
//CLDC

> Also, Vic 
> Wintriss wrote Sunday and was wondering what the timeline with the NetBeans 
> is.

Did he write just to you or to the mailing list? I did not received his
message.

Best regards,
Stefano.

-- 
Stefano Sanna - ger...@ti...
Personal web site: http://www.gerdavax.it
AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE

*** Solo chi non fa niente non sbaglia ***

Re: [Nxtcommand-developers] CLDC

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

I am talking nonsense, NXTCommand.open() will (probably) be
introduced in v0.6. So forget about the NXTCommand.open()
command. In v0.5 the following change was introduced.

In v0.4 the NXTCOMM environment variable was used to set the serial
port to use for bluetooth. In v0.5 this no longer works.

In v0.5 we introduced a file "icommand.properties". In this file
the property nxtcomm should be set to the serial port for bluetooth.

In the distribution is included a file IMPORTANT.txt where this is
explained. See also the instructions in README.txt, and have a look
at the icommand.properties file in the distribution.

Peter Joosten.

> 
> Please add the 2 lines NXTCommand.open() and NXTCommand.close()
> in your code program. NXTCommand.close() is part of icommand for as
> long as i know icommand, NXTCommand.open() was introduced in the last
> release 0.5
> 
> 
> package nxtbttest;
> > 
> > import icommand.nxtcomm.*;
> > import icommand.platform.nxt.*;
> > 
> > public class Main
> > {
> >          public static void main(String[] args)
> >          {
> 		NXTCommand.open(); // at the start of the program execution.
> 
> >              UltrasonicSensor us = new UltrasonicSensor(Sensor.S1);
> 
> 		NXTCommand.close(); // at the end of the program execution
> >          }
> > }
> > 
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to 
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxt...@li...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

Re: [Nxtcommand-developers] CLDC

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

I just saw the last part of the message. Please save your money.

Every "average" Java programmer should be able to solve this problem,
if he is willing to have a look at the code. Communicating and solving
the problem over the phone is another thing.  

> I paid Sun to trouble shoot it for me, but they gave up because there
> was too much code behind the problem.  Perhaps if I made it real
> simple for them, they might be able to fix it.
> 
> Vic

Re: [Nxtcommand-developers] CLDC

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

On Wed, 2006-11-22 at 11:50 -0600, Brian Bagnall wrote:
> Hi Stefano,
> 
> Just wondering how you are coming along with the CLDC code? Also, Vic 
> Wintriss wrote Sunday and was wondering what the timeline with the NetBeans 
> is.

>From one of the previous mails I understand that Vic only wants to be
able to write and run icommand programs from within Netbeans. He does
not any new Netbeans mode to be written. My 1st tought is "easy money",
but I may be wrong. I can have a look into this, but I do not want to
get into a race with Stefano for the sensor "trofee". 

I shall have a look. If I come up with a solution, I shall contact
Stefano first. I am not in for the price, give it to person who is
(voluntary) involved in teaching kids Robotics.

Please add the 2 lines NXTCommand.open() and NXTCommand.close()
in your code program. NXTCommand.close() is part of icommand for as
long as i know icommand, NXTCommand.open() was introduced in the last
release 0.5


package nxtbttest;
> 
> import icommand.nxtcomm.*;
> import icommand.platform.nxt.*;
> 
> public class Main
> {
>          public static void main(String[] args)
>          {
		NXTCommand.open(); // at the start of the program execution.

>              UltrasonicSensor us = new UltrasonicSensor(Sensor.S1);

		NXTCommand.close(); // at the end of the program execution
>          }
> }
> 

[Nxtcommand-developers] CLDC

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

Hi Stefano,

Just wondering how you are coming along with the CLDC code? Also, Vic 
Wintriss wrote Sunday and was wondering what the timeline with the NetBeans 
is.

- Brian

===

Brian:

Any word on getting iCommand working with NetBeans?  My offer for the
sensors is still good.

Awhile back you said that you were coming out with a new release
soon.  Status?

To do some of my own testing, I'd like to write a simple program that
calls on a method in NXTComm.  I don't think I even get past open().

With this simple program:

package nxtbttest;

import icommand.nxtcomm.*;
import icommand.platform.nxt.*;

public class Main
{
         public static void main(String[] args)
         {
             UltrasonicSensor us = new UltrasonicSensor(Sensor.S1);
         }
}

I get the following when I try to run it:

init:
deps-jar:
Compiling 1 source file to /Users/vwpro/NxtBtTest/build/classes
compile:
run:
java.lang.Exception: NXTCOMM is not defined as a system Environment
Variable
NXTCOMM = null
         at icommand.nxtcomm.NXTComm.open(NXTComm.java:46)
Error while connecting NXTCommand() constructor
         at icommand.nxtcomm.NXTCommand.<clinit>(NXTCommand.java:16)
         at icommand.platform.nxt.Sensor.setTypeAndMode(Sensor.java:32)
         at icommand.platform.nxt.I2CSensor.<init>(I2CSensor.java:20)
         at icommand.platform.nxt.UltrasonicSensor.<init>
(UltrasonicSensor.java:13)
         at nxtbttest.Main.main(Main.java:10)
Exception in thread "main" java.lang.NullPointerException
         at icommand.nxtcomm.NXTComm.sendData(NXTComm.java:105)
         at icommand.nxtcomm.NXTCommand.sendRequest(NXTCommand.java:617)
         at icommand.nxtcomm.NXTCommand.setInputMode(NXTCommand.java:
401)
         at icommand.platform.nxt.Sensor.setTypeAndMode(Sensor.java:32)
         at icommand.platform.nxt.I2CSensor.<init>(I2CSensor.java:20)
         at icommand.platform.nxt.UltrasonicSensor.<init>
(UltrasonicSensor.java:13)
         at nxtbttest.Main.main(Main.java:10)
Java Result: 1
BUILD SUCCESSFUL (total time: 0 seconds)

I paid Sun to trouble shoot it for me, but they gave up because there
was too much code behind the problem.  Perhaps if I made it real
simple for them, they might be able to fix it.

Vic

Re: [Nxtcommand-developers] NXT vs. NXTCommand

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

Hi Peter,

> 2. First, think about and specify what options we want to support. Then 
> come
> up with an
>   API that reflects our decisions. There are a lot of options:
>   A PC with multiple BT dongles and USB cables. Controlling multiple NXT's
> with 1 BT dongle.
>   Controlling 1 NXT from multiple USB dongles. Controlling 1 NXT with 1 
> USB
> cable connection.
>   Combinations of those options.

Controlling multiple NXT's with 1 Bluetooth dongle would be the ideal 
target, if that's possible. Rojit from the leJOS discussion list is the only 
one who seems to have had some success here, but it wasn't 100% from what he 
said. I'll contact him and see if he can tell us more since no one here has 
multiple NXT bricks.

> Maybe we should stick with option 1 for v0.6 and think about option 2 for
> v0.7 (or later) ?

I'm fine with that. Motor tacho accuracy and working SyncMotors should be 
high priorities for the 0.6 release, since they are pretty flaky right now. 
Also, I need to get the Ultrasonic class working, which I thought I had 
nailed for 0.5. If we get somewhere with it we could release it as 
preliminary support (i.e. it's not tested but they can play with it).

> Forgot 1 thing. We should also get rid of NXTCommand.setVerify(boolean).
>
> How about (Sorry for reopening the discussion).
>
> 2 new classes in icommand.platform.nxt: PC an Connection.
>
> Connection con = PC.connect()
> con.setverify(true);
> con.close();
>
> This is more true to the fact that the connection is initated by the PC
> and not the NXT. It also has a good opening for supporting more options.
>
> Connection con1 = PC.connect(USB, NXT1); //connect to the 1st NXT with USB
> cable
> con1.setVerify(false);
> Connection con2 = PC.connect(BT, NXT2) //connect to the 2nd NXT over BT
> con2.setverify(true);
>
> con1.select()  //select the connection to the 1st NXT
> Battery.getVoltage() // 1st NXT is selected, so we do not need to specify
> the NXT as method parameter.
>
> con2.select()
> Battery.getVoltage()
>
> con1.close();
> con2.close();

I like that architecture for handling the singleton situation. It's probably 
the best we can do, considering our goal is to stick to the leJOS 
architecture, which puts some limits on us. The obvious downside is that 
user code will have to keep calling con2.select() to switch back and forth, 
which is messy but necessary. But it's better to cater to single NXT owners, 
who make up the majority of people out there.

It would be nice to add a seperate package tailored to the multiple NXT 
brick people. One I idea I have is to be very port-centric, since the NXT 
will have adapters from HiTechnic and Mindsensors.com for expansion. Plus 
there is a NXT-RCX Link to control the RCX, which essentially adds more 
ports to the mix. So with multiple NXT's the option could be there for 
things like:

Motor motor1 = new Motor(nxt1.getPort("A"));
...
Motor motor5 = new Motor(nxt2.getPort("A"));
...
PortExpander ports = new PortExpander(nxt1.getPort("C"));
Motor motor7 = new Motor(ports.getPort("D"));

Also, when leJOS NXT comes out we will want to mirror that interface so code 
running on the PC is almost identical (other than import statements). We'll 
have to wait and see how leJOS NXT develops.

- Brian 

[Nxtcommand-developers] Samples and Resources

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

Hi Peter,

The way the samples are set up now the resources are in a seperate 
directory. So when I try to run a sample in Eclipse such as Melody it 
doesn't see the Monkey Island.rso file. Is there a way we can fix this so 
developers can easily run and change the sample code?

- Brian 

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

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

Brian, other developers,

My mails of yesterday were written a little late.
As a result I was not that clear in my mind.

At this moment I have changed the sources in my eclipse workspace.
I have come up with the following proposal.
If you agree, than I will continue testing, and then commit my changes.

in package icommand.nxt:

I have an interface NXTComm, and 2 implementation classes NXTCommRXTX
and NXTCommBluez. I had to remove the 'static' modifier of the methods
in NXTCommRXTX in order to use the interface NXTComm.

I have added NXTComm.open() to the API. So at start of the program
NXTCommand.open() should be called, and at the end NXTCommand.close();

When I started programming I did think that I needed NXTCommand.open()
to be in the API for technical reasons. But there is no technical
reason. I you prefer I can remove this API change. Personally I prefer
to put it in the API, because to me it looks "strange" to see a close()
statement, without a preceding open() statement. Make your choice! 
 
I still want to make icommand.nxt a non-API package someday, but for the
moment I want to leave it as is.

My 2nd goal was to remove static methods where they where not really
needed. Personally I think the static modifier is OK for defining
constants (public static final String GREET = "Hello") an so-called
utility classes (e.g. java.lang.Math). I have also removed the 'static'
modifier in the methods from NXTCommand as much as possible.

The methods open() close() and setVerify(...) I did leave static,
because they are part of the "static Lejos API".

I did make the NXTCommand class a singleton, so that it can easily
be accessed by the static Lejos API. When I say singleton, I mean
the singleton design pattern, not static methods. (There is a
difference).

In the example below you can see how the singleton is accessed
from the classes in the package icommand.patform.nxt 

public class Battery implements NXTProtocol {
	
	private static final NXTCommand nxtCommand = NXTCommand.getSingleton();
	
	// Ensure no one tries to instantiate this.
	private Battery() {}
		
	/**
	 * The NXT uses 6 batteries of 1500 mV each.
	 * @return Battery voltage in mV. ~9000 = full.
	 */
	public static int getVoltageMilliVolt() {
		/*
	     * calculation from LEGO firmware
	     */
		int voltage = nxtCommand.getBatteryLevel();
		return voltage;
	}

	/**
	 * The NXT uses 6 batteries of 1.5 V each.
	 * @return Battery voltage in Volt. ~9V = full.
	 */
	public static float getVoltage() {
	   return (float)(getVoltageMilliVolt() * 0.001);
	}
}

Greetings,
Peter Joosten.



 

Re: [Nxtcommand-developers] Making Icommand ready for differentNXTCOMMimplementations

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

>> Puttng the NXTComm interface in package 'icommand' would even be better.
>> I need  this interface to support multiple implementations.
>>
>> Then I do not need an Interface NXTCommand.
>>
>> This would however mean a "bigger" change in the API.
>>
>> NXTComm.open() and NXTComm.close() instead of NXTCommand.close()
>
> That's fine. Makes more sense really, since you are opening/closing the
> communications link.

But what package would NXTComm reside in, and we still need to make those 
for Bluez etc... don't we? i.e. BluezNXTComm, RXTXNXTComm... We need to give 
the user one singleton class they can use to access methods.

- Brian 

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMMimplementations

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

> We should separate API (for end users) from implementation.
>
> At this moment from the icommand.nxtcomm package the NXTCommand class is
> part of the API (method close()).
>
> package icommand.nxtcomm should NOT be part of the API
>
> Proposal:
>
> Make an interface NXTCommand in the package icommand.platform.nxt
> with open() and close() methods.

Should we just call it NXT in keeping with the other physical objects 
(Motor, Speaker, etc...) - On second thought, see below.

> Change access modifiers in icommand.nxtcomm to package (= no access
> modifier) as much as possible to prohibit access by end users.
>
> In the distribution Javadoc of package icommand.nxtcomm will not be
> included, since it is no longer part of the API.

I agree with that. End users won't be using that.

> Puttng the NXTComm interface in package 'icommand' would even be better.
> I need  this interface to support multiple implementations.
>
> Then I do not need an Interface NXTCommand.
>
> This would however mean a "bigger" change in the API.
>
> NXTComm.open() and NXTComm.close() instead of NXTCommand.close()

That's fine. Makes more sense really, since you are opening/closing the 
communications link.

- Brian 

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

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

Puttng the NXTComm interface in package 'icommand' would even be better.
I need  this interface to support multiple implementations.

Then I do not need an Interface NXTCommand.

This would however mean a "bigger" change in the API.

NXTComm.open() and NXTComm.close() instead of NXTCommand.close()

Peter.

On Thu, 2006-11-09 at 02:23 +0100, Peter Joosten wrote:
> On Thu, 2006-11-09 at 02:21 +0100, Peter Joosten wrote:
> > We should separate API (for end users) from implementation.
> > 
> > At this moment from the icommand.nxtcomm package the NXTCommand class is
> > part of the API (method close()).
> > 
> > package icommand.nxtcomm should NOT be part of the API
> > 
> > Proposal:
> > 
> > Make an interface NXTCommand in the package icommand.platform.nxt
> > with open() and close() methods.
> > 
> 
> Putting the interface in the "icommand" package would be a good
> (/better?) alternative !
> 
> > Change access modifiers in icommand.nxtcomm to package (= no access
> > modifier) as much as possible to prohibit access by end users. 
> > 
> > In the distribution Javadoc of package icommand.nxtcomm will not be
> > included, since it is no longer part of the API.
> > 
> > Peter Joosten.
> > 
> > 
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxt...@li...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

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

On Thu, 2006-11-09 at 02:21 +0100, Peter Joosten wrote:
> We should separate API (for end users) from implementation.
> 
> At this moment from the icommand.nxtcomm package the NXTCommand class is
> part of the API (method close()).
> 
> package icommand.nxtcomm should NOT be part of the API
> 
> Proposal:
> 
> Make an interface NXTCommand in the package icommand.platform.nxt
> with open() and close() methods.
> 

Putting the interface in the "icommand" package would be a good
(/better?) alternative !

> Change access modifiers in icommand.nxtcomm to package (= no access
> modifier) as much as possible to prohibit access by end users. 
> 
> In the distribution Javadoc of package icommand.nxtcomm will not be
> included, since it is no longer part of the API.
> 
> Peter Joosten.
> 
> 

[Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

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

We should separate API (for end users) from implementation.

At this moment from the icommand.nxtcomm package the NXTCommand class is
part of the API (method close()).

package icommand.nxtcomm should NOT be part of the API

Proposal:

Make an interface NXTCommand in the package icommand.platform.nxt
with open() and close() methods.

Change access modifiers in icommand.nxtcomm to package (= no access
modifier) as much as possible to prohibit access by end users. 

In the distribution Javadoc of package icommand.nxtcomm will not be
included, since it is no longer part of the API.

Peter Joosten.

[Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

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

I am making changes to make Icommand ready for different NXTCOMM
implementations: RXTX, BlueZ, ...

Changes to properties file:

	/* Type of NXTCOMM implementation; defaulting to 'rxtx' */
	private static final String PROP_NXTCOMM_TYPE = "nxtcomm.type";
	
	private static final String PROP_RXTX_PORT    = "rxtx.port";

	/* Changed property name from 'nxtcomm' to 'rxtx.port';
	 *  still supporting the old property name.
	 */
	private static final String PROP_RXTX_PORT_OLD = "nxtcomm";
	
	private static final String PROP_BLUEZ_DEVID  = "bluez.devid";
	

Any comments ?

Peter Joosten.