nxtcommand-developers Mailing List for iCommand
Status: Beta
Brought to you by:
bbagnall
Menu
▾
▴
nxtcommand-developers — Forum for developers to discuss changes and improvements to iCommand.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(50) |
Dec
(38) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(1) |
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
|
From: Brian B. <bba...@mt...> - 2007-10-20 17:27:10
|
Hi Peter, I noticed that someone mentioned they could not find the libicmdbluez.so native library for Linux, as mentioned in the docs. Any idea where this can be found? http://lejos.sourceforge.net/forum/viewtopic.php?p=1506#1506 - Brian |
|
From: Brian B. <bba...@mt...> - 2007-09-03 21:11:40
|
Hi Peter, iCommand 0.6 is out. Just wanted to let you know that I reorganized the NXTComm classes to take a java.util.Properties instead of the regular properties (made it easier to save). I haven't tested this with the LEGO firmware, but it works well with the NXJ firmware. It also uses defaults: Windows - bluecove (and auto-detects address), Mac OSX - rxtx, and Linux - bluez. Take care, Brian |
|
From: Brian B. <bba...@mt...> - 2007-08-21 22:13:31
|
Hi Peter, Just wondering if you made any progress on reconfiguring NXTCommFactory so it uses Lawrie's method to check automatically for the BT address? (then write it to the properties) A Toshiba/Windows user mentioned that BlueCove does not work with the Toshiba Bluetooth stack. So he would prefer the option to override the default BlueCove usage in favor of RXTX. The thing is, if you don't have anything specified in icommand.properties then it uses RXTX by default. I'd prefer to have it use BlueCove by default for Windows (as the code currently does) but if it sees nxtcomm.type=rxtx in the properties file, only then use RXTX. Any idea the best way to implement that? - Brian |
|
From: Brian B. <bba...@mt...> - 2007-08-05 16:30:25
|
Hi Peter,
> About 1 and 2. I would prefer to make a tool that generates
> the file icommand.properties in the home directory of the user.
>
> windows --> bluecove + detect bluetooth address
> linux --> bluez + detect bluetooth addrress
> os x --> rxtx + edit com port manually
That sounds good. I added some code in the factory to detect OS but you can
remove this if you would prefer a seperate class. For users with one NXT
brick, will this tool will run automatically, without user assistance? It
should be possible to have this function with no additional steps on the
part of the user (other than if using RXTX).
Maybe if they have more than one NXT they might have to specify which one to
use, but then again it could just latch on to whichever one happens to be
on.
> About 3. I have the impression that this is a bluecove problem. Hard too
> fix
> (?)
> See following examples.
> - example 1 works correct.
> Motor.A.rotate(1800); waits until the tacholimit is reached
> - example 2 works correct.
> NXTCommand.setVerify(true); Sound.playTone(1500, 1000); is waiting for a
> response.
> - example 3 has a problem. The connection is not closed even when the
> program is cancelled.
> NXTCommand.setVerify(false); Sound.playTone(1500, 1000); does not wait for
> a response.
>
> example 1: (correct)
>
> for (int i = 0; i < 10; i++) {
> NXTCommand.open();
> Motor.A.rotate(1800);
> System.out.println("Tachometer A: " + Motor.A.getTachoCount());
> NXTCommand.close();
> }
>
>
> example 2: (correct)
>
> NXTCommand.setVerify(true);
> for (int i = 0; i < 10; i++) {
> NXTCommand.open();
> Sound.playTone(1500, 1000);
> NXTCommand.close();
> }
>
> example 3: (error)
>
> NXTCommand.setVerify(false);
> for (int i = 0; i < 10; i++) {
> NXTCommand.open();
> Sound.playTone(1500, 1000);
> NXTCommand.close();
> }
It might not be BlueCove since it happens with RXTX too. It also happens
when using NXJ firmware, whereas Lawrie's works with NXJ firmware. Let's put
that problem on the backburner for now. I'll do some research later and see
if Lawrie has any insight into this since he seems to have it working right
with a Bluecove/NXJ firmware combo.
- Brian
> -----Original Message-----
> From: Brian Bagnall [mailto:bba...@mt...]
> Sent: vrijdag 27 juli 2007 5:41
> To: Peter Joosten
> Cc: iCommand Developers
> Subject: LEGO FW Support
>
>
> Hi Peter,
>
> I changed the NXJ firmware so it properly sends the run state instead of
> mode to indicate if the motor is done turning. This should make it work
> the
> same for LCP and isMoving() shouldn't cause an infinite loop. I'll check
> the
> changes in later for Motor.
>
> The remaining tasks I'd like to get done before release are:
> 1 - Auto NXTComm selection using OS detection (rather than manually
> editing
> the properties file)
> 2 - Auto detection of Bluetooth address and automatically writing it to
> the
> properties file (Bluecove only?)
> 3 - Working close() method so the NXT brick doesn't have to be reset after
> each run (Lawrie figured this out with NXJ somehow)
>
> Any of those interest you?
>
> - Brian
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.22/922 - Release Date: 27-7-2007
> 6:08
>
>
|
|
From: Brian B. <bba...@mt...> - 2007-07-28 17:24:04
|
I just did some house cleaning and removed inactive developers from the project. If I made an error and you are actively developing or intend to, please let me know and I'll add you back to the project. The following users were removed: cjavaho Darwin Felix Stefano Sanna kurt kirkey Roly V. Steve Prior Stefan Gustavson - Brian |
|
From: Brian B. <bba...@mt...> - 2007-07-27 03:40:49
|
Hi Peter, I changed the NXJ firmware so it properly sends the run state instead of mode to indicate if the motor is done turning. This should make it work the same for LCP and isMoving() shouldn't cause an infinite loop. I'll check the changes in later for Motor. The remaining tasks I'd like to get done before release are: 1 - Auto NXTComm selection using OS detection (rather than manually editing the properties file) 2 - Auto detection of Bluetooth address and automatically writing it to the properties file (Bluecove only?) 3 - Working close() method so the NXT brick doesn't have to be reset after each run (Lawrie figured this out with NXJ somehow) Any of those interest you? - Brian |
|
From: Brian B. <bba...@mt...> - 2007-07-24 19:48:28
|
Hi Peter,
Thanks for checking that out. I see what's going on now. I had to change
some of the code to work with leJOS NXJ and didn't recheck with LEGO. That's
why it's working for me and not you. It might require a tweak to the leJOS
NXJ code to get them both working.
My preference is to support primarily NXJ now that the menu system accepts
LCP commands. It would be nice if it worked with LEGO firmware though. This
might take some investigation to figure out a solution.
Just an update, I'm coming along good with the navigation classes. So far
Pilot and TachoNavigator seem to work well. The Compass ones will take a bit
more fiddling.
- Brian
----- Original Message -----
From: "Peter Joosten" <ptg...@up...>
To: "'Brian Bagnall'" <bba...@mt...>
Sent: Tuesday, July 24, 2007 1:17 PM
Subject: RE: Motor
> Just to be sure: On the NXT brick I am using the Lego firmware, not the
> Lejos NXJ
>
> -----Original Message-----
> From: Peter Joosten [mailto:ptg...@up...]
> Sent: dinsdag 24 juli 2007 20:11
> To: 'Brian Bagnall'
> Subject: RE: Motor
>
>
> Hi Brian,
>
> I also reverted back locally to v96 to reprodruce the error I reported.
> I detected the error using the TachoCount sample. To reproduce the
> error I have used a simplified example:
>
> public static void main(String [] args) throws Exception {
> NXTCommand.open();
> NXTCommand.setVerify(true);
> System.out.println("Tachometer A: " + Motor.A.getTachoCount());
> Motor.A.rotate(5000);
> System.out.println("Tachometer A: " + Motor.A.getTachoCount());
> NXTCommand.close();
> }
>
> Output:
>
> Looking for 'icommand.properties' in working dir:
> C:\projecten\icommand\data\eclipse\workspace\icommand-samples
> Looking for 'icommand.properties' in home dir: C:\Documents and
> Settings\Peter
> BlueCove version 2.0.0 on winsock
> Tachometer A: 0
>
> The 2nd tachometer position is not shown. The connection is not closed.
> Debugging:
>
> public boolean isMoving() {
> OutputState o = nxtCommand.getOutputState(id);
> System.out.println(o.mode);
> return ((MOTORON & o.mode) == MOTORON);
> }
>
> The value is 7 and doesn't change. As a result isMoving stays true and the
> rotate method
> is in an endless loop. This bug occurs for all motors: A, B, or C.
>
> Peter Joosten.
>
>
> -----Original Message-----
> From: Brian Bagnall [mailto:bba...@mt...]
> Sent: maandag 23 juli 2007 23:49
> To: Peter Joosten
> Subject: Motor
>
>
> Hi Peter,
>
> The Motor changes caused the Motor no longer wait until the command has
> completed before continuing, so the following code no longer works
> properly:
>
> Pilot p = new Pilot(5.6F, 16.0F,Motor.B, Motor.C, true);
> p.travel(100);
> p.rotate(90);
> p.travel(-100);
>
> I reverted back to version 96 (locally) and that seems to work properly.
> You
> mentioned in your email that Motor A goes into an endless loop when the
> tacholimit is reached. I'm using motors B and C for my example. Is the
> problem only with Motor A?
>
> - Brian
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: 24-7-2007
> 13:50
>
>
|
|
From: Brian B. <bba...@mt...> - 2007-07-22 18:28:39
|
> I have added a BlueCove NXTComm implementation, and commited the changes
> to
> SVN.
> I did perform a little test: run Tachocount and Melody samples. Result:
> OK!
> I am using the Microsoft BT stack. I am very pleased that we know have a
> stable BT link for Windows (1st impression).
Hi Peter,
I gave it a whirl and it works great, and fast - faster connecting than even
RXTX I think. The only problem I found was that it can't run twice in a row
without turning off the NXT brick. Lawrie is able to do this so there must
be a way to finalize a Bluetooth connection on the close() method.
> Remark: there is a bug in the Motor class. After the motor A has reached
> it's
> tacholimit and has stopped, the method "public boolean isMoving()" is
> still
> returning true,
> causing an endless loop while(isMoving()) {Thread.yield();} in the method
> "public int rotate(long count, boolean returnNow)" Some additional testing
> / bug fixing
> before a new release may be wise.
I'll look into that.
> The NXTCommBleuCove is not documented yet. Probably I have some time next
> week (23-29 July)
> Instructions:
> - bluecove-2.0.0.jar must be in the classpath.
> - icommand.properties (in home or work directory):
> nxtcomm.type=bluecove
> nxt.btaddress=00:16:53:01:EC:04
>
> So 1. there is a new value for the nxtcomm.type --> bluecove
> 2. there is a new property nxt.btaddress : the bluetooth address of the
> NXT
> brick.
> This property is used both for BleuCove and BlueZ.
>
> I have kept the old property bluez.address. The new property nxt.address
> is
> preferred.
> Both properties are interchangeable. nxt.btaddress is examined 1st, if
> it's
> null bluez.address is used.
>
> I have implemented the NXTCommBlueCove just like the other existing
> NXTCom implementations in icommand. I didn't make use of the search
> function and OS detection (yet). The main reason is because I
> didn't want to adapt the other implementations (lack of time).
>
> What do you think of NXTCommBlueCove that is in SVN now ?
> - We could you OS detection to prevent a user to choose an implementation
> that is not supported on his OS.
Definitely. Lawrie's code in NXTCommFactory is dead simple for that.
> User still has to supply a COM port or BT address in icommand.properties.
> - searching for BT devices is a neat feature when using a GUI to select a
> device from a list; supplying a BT address is faster (did you notice).
I'd like to see it search for an NXT brick and automatically add the first
address it finds to the properties file. I think users will have a hard time
finding and entering their address. Once it's in the properties it wouldn't
have to search again (unless it fails to connect using that address).
> I think it would be good to discuss the NXTComm implementations in the
> near
> future:
> - what can be automatically detected (OS, BT devices) platform, should not
> be configured (icommand.properties). I agree
> - Prevent duplicate code between Lejos NXJ and Icommand. Options:
> 1. Move PC code of Lejos to Icommand, or 2. move Icommand to Lejos (and
> stop Icommand project) ??? Vote: 1 ?
I mentioned this to Lawrie and basically we don't want to do this quite yet,
though it might be on the table in the future. He wants to get some other
things straightened up and simplified before adding complexity to the
project. I agree with him on that.
> - The number of BT / USB implementations is becoming overwhelming. Can we
> eliminate some of them ? Probably Not :-(
The surefire things we have are:
- BlueCove for Windows (coming soon for Linux)
- Bluez for Linux (and OS X?)
- ?? For Mac OS X.
And of course we should implement USB support sometime in the future, but
probably not for the next release. I don't mind leaving in support for
multiple methods as an option, but once we have good solid solutions for
Win/Linux/Mac maybe we could just not document them anymore.
In summary, the changes I'd like to see in the next release are:
- Bug in Motor (me)
- Auto OS detection and NXTComm selection (ME or you?)
- Auto detection of address and write to properties (me or you?)
- Better close() method (me or you?)
- General cleanup of some methods to match NXJ (me)
- Little bit of testing.
- Aim for a release soon - Friday or sooner.
- Brian
|
|
From: Brian B. <bba...@mt...> - 2007-07-21 16:59:41
|
Thanks, Peter. I think you'll be pleasantly surprised. I think Lawrie took your code as a base and then expanded it a bit more. He's done some good work on his end. He changed the NXTComm interface to support multiple NXTs via a search (inquiry) method that returns an array of NXTInfo. Search is a little slow, but we might be able to store the address in a property file so it doesn't have to go through that each time. He also added Java streams and support for the Lego Fantom driver via NXTCommFantom. There might also be the possibility of supporting USB if we wanted to, via NXTCommLibnxt, but that's something for another time. (Libusb is a seperate download.) What I kind of like is his NXTCommFactory code, which checks the OS system and then automatically chooses the solution. It eliminates the need for the end user to know anything about Bluez, Bluecove, RXTX, etc... This could eliminate a lot of troublesome setup steps for end users. - Brian ----- Original Message ----- From: "Peter Joosten" <ptg...@up...> To: "'Brian Bagnall'" <bba...@mt...> Sent: Friday, July 20, 2007 4:04 PM Subject: RE: NXTCommBluecove >I will have a look at it this weekend. > > Peter Joosten. > > -----Original Message----- > From: Brian Bagnall [mailto:bba...@mt...] > Sent: vrijdag 20 juli 2007 21:35 > To: Peter Joosten > Subject: NXTCommBluecove > > > Hi Peter, > > I was just checking out Lawrie's Bluecove code and it looks like it is > very > similar to the NXTComm mechanism used in iCommand: > - Add https://lejos.svn.sourceforge.net/svnroot/lejos to Eclipse SVN > - Browse to trunk - pccomms - lejos - pc - comm - NXTCommBluecove > > His NXTComm interface differs slightly from ours in a few minor ways, but > basically the same. Since I'm not all that familiar with the NXTComm API I > was wondering if you have time these days to port that over to iCommand? > If > not, do you have any pointers for me or see any problems? > > - Brian > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19-7-2007 > 18:10 > > |
|
From: Brian B. <bba...@mt...> - 2007-07-19 22:36:05
|
Hi Peter, You're right, I thought Linux was currently supported because Bluecove was packaged in a tar file but it isn't. They mention that Bluecove will support BlueZ on the Linux stack for the next version, though, so it might be something to consider. Ever since pairing my NXT with Bluecove, iCommand doesn't work for me (though I haven't tested iCommand in a while too). I didn't troubleshoot the problem yet but it has me worried, which is one reason I was thinking of adding Bluecove support - the main reason though to eliminate the RXTX dependency. - Brian ----- Original Message ----- From: "Peter Joosten" <ptg...@up...> To: "'Brian Bagnall'" <bba...@mt...> Cc: "'Lawrie Griffiths'" <law...@nt...> Sent: Thursday, July 19, 2007 3:00 PM Subject: RE: iCommand release > OOPs! I hit some wrong key, and the message was gone. > > Bluecove supports Widcomm, MS BT Stack, BlueSoleil on Windows, and MS BT > Stack on Windows Mobile. > > We have: > - RXTX for Windows / Linux / OS X > - Bluez for Linux > - javax.comm for ??? > > We have to keep RXTX to support OS X. > > Peter Joosten. > > -----Original Message----- > From: Peter Joosten [mailto:ptg...@up...] > Sent: donderdag 19 juli 2007 21:53 > To: 'Brian Bagnall' > Cc: 'Lawrie Griffiths' > Subject: RE: iCommand release > > > Hi Brian, > > Bluecove supports widcomm, MS BT > > -----Original Message----- > From: Brian Bagnall [mailto:bba...@mt...] > Sent: donderdag 19 juli 2007 20:17 > To: Peter Joosten > Cc: Lawrie Griffiths > Subject: iCommand release > > > Hi Peter, > > Thanks for the tip on Bluecove 2.0 - it works great with Widcomm. It's > been > over 6 months since an iCommand update and I'd like to do a release soon > now > that NXJ 0.3 is out. There's a few classes in the navigation package that > I'd like to straighten out first so they more closely resemble NXJ > navigation classes. > > I was wondering if you think it would be easy to end RXTX dependency by > using Bluecove? (Maybe you have an opinion, Lawrie, since you've used it > so > much?) If we could do a NXTCommBluecove class and include bluecove.jar > this > might be the preferred default. > > - Brian > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 18-7-2007 > 15:30 > |
|
From: Brian B. <bba...@mt...> - 2007-07-19 18:17:45
|
Hi Peter, Thanks for the tip on Bluecove 2.0 - it works great with Widcomm. It's been over 6 months since an iCommand update and I'd like to do a release soon now that NXJ 0.3 is out. There's a few classes in the navigation package that I'd like to straighten out first so they more closely resemble NXJ navigation classes. I was wondering if you think it would be easy to end RXTX dependency by using Bluecove? (Maybe you have an opinion, Lawrie, since you've used it so much?) If we could do a NXTCommBluecove class and include bluecove.jar this might be the preferred default. - Brian |
|
From: Brian B. <bba...@mt...> - 2007-03-14 20:29:16
|
----- Original Message ----- From: "Peter Joosten" <ptg...@ch...> > > 2. Sensor >> Port > - Maybe SensorPort would be a better name ? ( SensorPort / OutputPort) > <--> > (MotorPort / InputPort) Hi Peter, We just renamed the classes SensorPort/MotorPort in leJOS. There's a complex number of interfaces for these, such as I2CPort, SimpleSensorPort and others to deal with RCX motors vs NXT motors. I'm going to wait for things to settle a bit before renaming things in iCommand. - Brian |
|
From: Brian B. <bba...@mt...> - 2007-03-12 05:15:05
|
I just got iCommand running on a Windows Mobile 5.0 Pocket PC. I downloaded the Mysaifu JVM and Javacomm, then uploaded the regular icommand.jar file to Pocket PC, along with a test class to run motors and the icommand.properties file. It works fine without any changes and it uses the same compiled bytecode classes as the PC. So from what I can tell there's no real reason to branch the project into two parts for mobile user as long as they can use Mysaifu. We can just give them directions on how to upload that to Windows Mobile. Stefano, is there any reason to use CLDC over Mysaifu? Does CLDC give us a broader range of mobile devices? I'm still uncertain what JVM they use in conjunction with CLDC. - Brian |
|
From: Brian B. <bba...@mt...> - 2007-03-03 20:42:13
|
Hi Peter, Now that we have a developing API for leJOS NXJ I'd like to start mirroring that API. I already started renaming (e.g. icommand.platform.nxt > icommand.nxt). I'd like to rename icommand.nxtcomm to icommand.nxt.comm but it will break the Bluez native methods (unsatisfied link error). Just wondering if you could update the BlueZ code. - Brian ----- Original Message ----- From: "Peter Joosten" <ptg...@ch...> To: "iCommand Developers" <nxt...@li...> Sent: Tuesday, February 20, 2007 3:17 PM Subject: Re: [Nxtcommand-developers] Test (please ignore) > Brain, Stefano, > > I remember a lengthy discussion about unique/duplicate icommand sources, > using SJPP (Simple Java PreProcessor), moving some packages of icommand > to a separate project, ... (see archives). I let you both decide how to > handle things. If you need my assistance, I am willing to help. > > Peter Joosten. > > On Tue, 2007-02-20 at 14:02 -0600, Brian Bagnall wrote: >> Hey Stefano, long time no hear! I can't recall what we were previously >> talking about with regard to MIDP cupport (or was it CLDC?). In any >> event, >> is that portion of the code in place on Subversion so users with Windows >> ME >> 5.0 can use it? >> >> - Brian >> >> ----- Original Message ----- >> From: "Stefano Sanna" <ger...@ti...> >> To: "iCommand Developers" <nxt...@li...> >> Sent: Friday, February 16, 2007 4:42 AM >> Subject: [Nxtcommand-developers] Test (please ignore) >> >> >> > My mailbox crashed. Just to test if sf account is still working. :-( >> > >> > Sorry. >> > >> > ------------------------------------------------------------------------- >> > 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 >> > >> >> >> ------------------------------------------------------------------------- >> 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 > > > ------------------------------------------------------------------------- > 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 > |
|
From: Brian B. <bba...@mt...> - 2007-02-27 04:54:12
|
I'll have a Windows Mobil 5.0 unit for about a week starting tomorrow so I'll be able to try some things out and maybe then I can form an opinion about what would be the best way to handle things. - Brian ----- Original Message ----- From: "Peter Joosten" <ptg...@ch...> To: "iCommand Developers" <nxt...@li...> Sent: Tuesday, February 20, 2007 3:17 PM Subject: Re: [Nxtcommand-developers] Test (please ignore) > Brain, Stefano, > > I remember a lengthy discussion about unique/duplicate icommand sources, > using SJPP (Simple Java PreProcessor), moving some packages of icommand > to a separate project, ... (see archives). I let you both decide how to > handle things. If you need my assistance, I am willing to help. > > Peter Joosten. > > On Tue, 2007-02-20 at 14:02 -0600, Brian Bagnall wrote: >> Hey Stefano, long time no hear! I can't recall what we were previously >> talking about with regard to MIDP cupport (or was it CLDC?). In any >> event, >> is that portion of the code in place on Subversion so users with Windows >> ME >> 5.0 can use it? >> >> - Brian >> >> ----- Original Message ----- >> From: "Stefano Sanna" <ger...@ti...> >> To: "iCommand Developers" <nxt...@li...> >> Sent: Friday, February 16, 2007 4:42 AM >> Subject: [Nxtcommand-developers] Test (please ignore) >> >> >> > My mailbox crashed. Just to test if sf account is still working. :-( >> > >> > Sorry. >> > >> > ------------------------------------------------------------------------- >> > 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 >> > >> >> >> ------------------------------------------------------------------------- >> 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 > > > ------------------------------------------------------------------------- > 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 > |
|
From: Peter J. <ptg...@ch...> - 2007-02-20 21:17:38
|
Brain, Stefano, I remember a lengthy discussion about unique/duplicate icommand sources, using SJPP (Simple Java PreProcessor), moving some packages of icommand to a separate project, ... (see archives). I let you both decide how to handle things. If you need my assistance, I am willing to help. Peter Joosten. On Tue, 2007-02-20 at 14:02 -0600, Brian Bagnall wrote: > Hey Stefano, long time no hear! I can't recall what we were previously > talking about with regard to MIDP cupport (or was it CLDC?). In any event, > is that portion of the code in place on Subversion so users with Windows ME > 5.0 can use it? > > - Brian > > ----- Original Message ----- > From: "Stefano Sanna" <ger...@ti...> > To: "iCommand Developers" <nxt...@li...> > Sent: Friday, February 16, 2007 4:42 AM > Subject: [Nxtcommand-developers] Test (please ignore) > > > > My mailbox crashed. Just to test if sf account is still working. :-( > > > > Sorry. > > > > ------------------------------------------------------------------------- > > 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 > > > > > ------------------------------------------------------------------------- > 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 |
|
From: Brian B. <bba...@mt...> - 2007-02-20 20:02:37
|
Hey Stefano, long time no hear! I can't recall what we were previously talking about with regard to MIDP cupport (or was it CLDC?). In any event, is that portion of the code in place on Subversion so users with Windows ME 5.0 can use it? - Brian ----- Original Message ----- From: "Stefano Sanna" <ger...@ti...> To: "iCommand Developers" <nxt...@li...> Sent: Friday, February 16, 2007 4:42 AM Subject: [Nxtcommand-developers] Test (please ignore) > My mailbox crashed. Just to test if sf account is still working. :-( > > Sorry. > > ------------------------------------------------------------------------- > 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 > |
|
From: Stefano S. <ger...@ti...> - 2007-02-16 10:42:08
|
My mailbox crashed. Just to test if sf account is still working. :-( Sorry. |
|
From: Brian B. <bba...@mt...> - 2007-01-07 06:02:24
|
We just went over 1500 downloads for iCommand according to the Sourceforge stats. Pretty good for a new project. I think a lot of people must have got NXT kits for Christmas. - Brian |
|
From: Brian B. <bba...@mt...> - 2006-12-19 04:37:38
|
Hi Steve and Peter, >I think I have taken on the role of the "infrastructure" (subversion / ant, > sjpp, ...) > guy here, which suits me fine. So I did not have a look speech / vision > packages yet. > > If I understand it correct vision and speach are more like lejos extension > libraries. > Brian, I assume since there is no Lejos NXT yet, you just run them on your > PC They will always be run from PC since there's no microphone for the NXT and not enough memory. Lego released a Vision package for the RCX and Lawrie Griffiths did a similar package (the Vision package adapted for iCommand) in Java. Basically robot-helper packages (like Navigation) that makes it easy for people to do advanced robot tasks. > That would be a very good reason to put them in seperate projects, and > restrict the > icommand project to the implementation of the Direct / System commands of > the Bluetooth SDK. > > (If my assumption is correct, maybe it would even be better to make vision > and speach part of > the lejos project.) > > Another reason to split it up is, that Stefano is not using (yet?) any > part > of the vision and > speach packages. So it would be nice having the option not to include them > in the CLDC project(s). > > In the icommand-sources project i can make 3 source folders that can be > linked into every > other project that needs them: > > folder1: > icommand.nxtcomm > icommand.platform > icommand.robotics > > folder2: > icommand.speach > folder3: > icommand.vision > > -------------------- > Your opinion please ! > Should icommand.robotics in a seperate 4th folder ? I changed the icommand.robotics to icommand.navigation (haven't committed yet). Could speech, vision and navigation all go in folder 2? If some of these packages don't work out very well we can turf them later or try something else. - Brian |
|
From: Peter J. <ptg...@ch...> - 2006-12-18 02:44:58
|
I think I have taken on the role of the "infrastructure" (subversion / ant, sjpp, ...) guy here, which suits me fine. So I did not have a look speech / vision packages yet. If I understand it correct vision and speach are more like lejos extension libraries. Brian, I assume since there is no Lejos NXT yet, you just run them on your PC That would be a very good reason to put them in seperate projects, and restrict the icommand project to the implementation of the Direct / System commands of the Bluetooth SDK. (If my assumption is correct, maybe it would even be better to make vision and speach part of the lejos project.) Another reason to split it up is, that Stefano is not using (yet?) any part of the vision and speach packages. So it would be nice having the option not to include them in the CLDC project(s). In the icommand-sources project i can make 3 source folders that can be linked into every other project that needs them: folder1: icommand.nxtcomm icommand.platform icommand.robotics folder2: icommand.speach folder3: icommand.vision -------------------- Your opinion please ! Should icommand.robotics in a seperate 4th folder ? Brian, I will wait for you to finish your work. Give me a sign when I can go ahead. Peter. > -----Original Message----- > From: nxt...@li... > [mailto:nxt...@li...]On Behalf Of > Steve Prior > Sent: Monday, December 18, 2006 2:59 AM > To: Brian Bagnall > Cc: iCommand Developers > Subject: Re: [Nxtcommand-developers] Supporting Multiple Platforms - > Using the SJPP Simple Java PreProcessor > > > While as a new guy I've been sitting here quietly and watching for a > bit, I'll chime in on this one. It seems to me that the speech and > vision functions are really host computer functions which are only > related to the NXT brick itself as inputs to the host program which > could influence what commands are sent to the brick. In fact it sounds > like the vision and speech functions might be useful for programs which > have nothing to do with NXT at all. > > I'd therefore make them an independent project from iCommand. > > Steve > > Brian Bagnall wrote: > > I have some speech stuff to check in. This brings up another > question - the > > icommand.vision and icommand.speech packages rely on external > JAR files. For > > speech it needs some sphinx4 jar files (2) and the Java Speech > API (1 more > > jar). > > > > Do you think we should branch icommand.vision and > icommand.speech into a > > seperate project in subversion? We should we just add these jars to the > > build-icommand/lib directory, same as rxtx and jmf. > > > > - Brian > > > ------------------------------------------------------------------------- > 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 |
|
From: Steve P. <sp...@ge...> - 2006-12-18 01:58:44
|
While as a new guy I've been sitting here quietly and watching for a bit, I'll chime in on this one. It seems to me that the speech and vision functions are really host computer functions which are only related to the NXT brick itself as inputs to the host program which could influence what commands are sent to the brick. In fact it sounds like the vision and speech functions might be useful for programs which have nothing to do with NXT at all. I'd therefore make them an independent project from iCommand. Steve Brian Bagnall wrote: > I have some speech stuff to check in. This brings up another question - the > icommand.vision and icommand.speech packages rely on external JAR files. For > speech it needs some sphinx4 jar files (2) and the Java Speech API (1 more > jar). > > Do you think we should branch icommand.vision and icommand.speech into a > seperate project in subversion? We should we just add these jars to the > build-icommand/lib directory, same as rxtx and jmf. > > - Brian |
|
From: Brian B. <bba...@mt...> - 2006-12-18 01:15:42
|
I have some speech stuff to check in. This brings up another question - the icommand.vision and icommand.speech packages rely on external JAR files. For speech it needs some sphinx4 jar files (2) and the Java Speech API (1 more jar). Do you think we should branch icommand.vision and icommand.speech into a seperate project in subversion? We should we just add these jars to the build-icommand/lib directory, same as rxtx and jmf. - Brian ----- Original Message ----- From: "Peter Joosten" <ptg...@ch...> To: "Brian Bagnall" <bba...@mt...>; "iCommand Developers" <nxt...@li...> Sent: Sunday, December 17, 2006 4:40 PM Subject: Supporting Multiple Platforms - Using the SJPP Simple Java PreProcessor > In order to support multiple platforms I will make some changes to > subversion. > > The first change I will make is to move the java sources of the icommand > project > to a new icommand-sources project. > > Actions: > 1. I would ask you to finish your current work on the icommand project. > 2. After this I will make the change. during this short period no commit > is > allowed > 3. I will send an e-mail when I have finished action 2. > > After the change you must DELETE the icommand project in your workspace, > and > check out the project icommand and icommand-sources from subversion. > > You have to link the sources of the icommand-sources project to the > icommand > project. Than you can start editing the icommand sources from within > the --> > icommand <-- project, like before. > > I will send instructions how to link the sources of the icommand-sources > project to the icommand project, for both eclipse and netbeans. > > Please let me know if you still have some work on icommand that you want > to > finish. > I like to start with action 2 at wednesday. But if every one has commited > his > changes, I will start with action 2 now. > > > Peter. > |
|
From: Peter J. <ptg...@ch...> - 2006-12-17 22:40:33
|
In order to support multiple platforms I will make some changes to subversion. The first change I will make is to move the java sources of the icommand project to a new icommand-sources project. Actions: 1. I would ask you to finish your current work on the icommand project. 2. After this I will make the change. during this short period no commit is allowed 3. I will send an e-mail when I have finished action 2. After the change you must DELETE the icommand project in your workspace, and check out the project icommand and icommand-sources from subversion. You have to link the sources of the icommand-sources project to the icommand project. Than you can start editing the icommand sources from within the --> icommand <-- project, like before. I will send instructions how to link the sources of the icommand-sources project to the icommand project, for both eclipse and netbeans. Please let me know if you still have some work on icommand that you want to finish. I like to start with action 2 at wednesday. But if every one has commited his changes, I will start with action 2 now. Peter. |
|
From: Brian B. <bba...@mt...> - 2006-12-17 18:09:10
|
Your solution sounds good to me. I think we should go for it. ----- Original Message ----- From: "Peter Joosten" <ptg...@ch...> To: "Brian Bagnall" <bba...@mt...>; "iCommand Developers" <nxt...@li...> Sent: Saturday, December 16, 2006 2:56 PM Subject: RE: [Nxtcommand-developers] CLDC > >> With this setup will we still be able to make changes to iCommand >> code and use it "realtime" in Eclipse? > > Yes. > > You will see sources in the projects icommand, icommand-cldc. > You will edit / make changes to the sources in the projects icomand, > icommand-cldc. > (So for the developer the new icommand project will look and behave as > before.) > The differences are: > 1. While it looks like you are editing the sources in icommand, > icommand-cldc, > you are actually editing the sources in the project icommand-sources. > In this way we achieve our goal: 1 source tree. > 2. The sources in projects icommand, icommand-cldc are compiled according > their > own project settings, which is a requirement to support the diffent > platforms. > > Or will we have to manually run an >> ANT build >> after every change to the iCommand source? >> >> ----- Original Message ----- >> From: "Peter Joosten" <ptg...@ch...> >> To: "Brian Bagnall" <bba...@mt...>; "iCommand Developers" >> <nxt...@li...> >> Sent: Friday, December 15, 2006 10:23 AM >> Subject: RE: [Nxtcommand-developers] CLDC >> >> >> > Supporting multiple runtime environments / platforms >> > with different development kits, requieres different >> > project settings. These can not coexist in 1 project. >> > (In eclipse terms: there can only be 1 .project, 1 >> > .classpath, and 1 .settings). Therefore each platform >> > should have its own project(s). I suggest the next setup: >> > >> > project icommand-sources : contains only the java sources >> > (with prepocessor commands) these sources are linked into >> > the other projects as an external source folder. >> > >> > project icommand : the sources of icommand-sources are linked >> > as an external source folder in this project and prepocessed & >> > compiled according the settings of the icommand project. >> > >> > project icommand-cldc : the sources of icommand-sources are linked >> > as an external source folder in this project and prepocessed & >> > compiled according the settings of the icommand-cldc project. >> > >> > The name of the project "icommand-cldc" is just an example. >> > >> > - In this ways every project only has 1 set of files for the project >> > settings. >> > - In this way we can use netbeans (if requied) for one project and >> > eclipse for another. >> > - we have 1 source tree in the project icommand-sources >> > >> > - This will break the ant build system, but that can be fixed. >> > >> > Agree/Disagree ? Questions ? If I get a GO a start implementing it, and >> > will integrate icommand-0.5_CLDCpre2.zip into icommand-sources. >> > >> > Stefano, is icommand-0.5_CLDCpre2.zip the latest version ? >> > >> > Peter. >> > >> >> >> ------------------------------------------------------------------------- >> 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 >> > |
