 | | | | | |
Hi,
Thinking of getting the NXT kit, just wanted to know what programming
languages / sdks are out there. I looked on the Lejos site, and it seems
like they were thinking about porting for NXT but it seems to have gone
quiet recently. Ideally I'd like to be able to develop in Java...
Thanks
Nick
--
View this message in context: http://www.nabble.com/NXT-What-Programming-Languages-%2B-Open-source--tf2555941.html#a7122549
Sent from the LEGO Robotics mailing list archive at Nabble.com.
| | | | | | | | | | | | | | | | |
| |
|
There are currently two alternative programming solutions for the NXT.
NBC is a assembly language programming solution that is incorporated as
part of the BricxCC development environment. It is open source. It uses
the standard NXT firmware. See http://bricxcc.sourceforge.net/
RobotC is a C programming solution available from Carnegie-Mellon
University's Robotics Academy. It is a commercial program but can be
downloaded and used for a 30-day evaluation period. It uses an alternate
NXT firmware that is performance optimized for the C environment. See
http://www-education.rec.ri.cmu.edu/robotc/
I'm not the right person to comment on which is best. As a co-developer
of RobotC, I might be accused of bias.
There's also a set of "Development Kits" available for download from the
Lego site. Currently these are principally of use in writing PC based
programs that communicate and control the NXT over the Bluetooth or USB
link. There any many different "solutions" that have emerged using these
DKs. You can find more on these by scanning the forums at nxtasy.org.
At present, Lego has not released open source firmware for the NXT. They
have announced their intent to do so.
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
Thanks for the info. So if I want to program in Java, am I better off getting
one of the RCX models and using something like Lejos? I'd be interested in
what people think of the NXT / RCX comparison...
Or I could try C but its been a while :-)
Cheers
Nick
Dick Swan wrote:
>
>
> There are currently two alternative programming solutions for the NXT.
>
> NBC is a assembly language programming solution that is incorporated as
> part of the BricxCC development environment. It is open source. It uses
> the standard NXT firmware. See http://bricxcc.sourceforge.net/
>
> RobotC is a C programming solution available from Carnegie-Mellon
> University's Robotics Academy. It is a commercial program but can be
> downloaded and used for a 30-day evaluation period. It uses an alternate
> NXT firmware that is performance optimized for the C environment. See
> http://www-education.rec.ri.cmu.edu/robotc/
>
> I'm not the right person to comment on which is best. As a co-developer
> of RobotC, I might be accused of bias.
>
>
> There's also a set of "Development Kits" available for download from the
> Lego site. Currently these are principally of use in writing PC based
> programs that communicate and control the NXT over the Bluetooth or USB
> link. There any many different "solutions" that have emerged using these
> DKs. You can find more on these by scanning the forums at nxtasy.org.
>
> At present, Lego has not released open source firmware for the NXT. They
> have announced their intent to do so.
>
>
--
View this message in context: http://www.nabble.com/NXT-What-Programming-Languages-%2B-Open-source--tf2555941.html#a7124194
Sent from the LEGO Robotics mailing list archive at Nabble.com.
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Nick77 <nickbaker77@gmail.com> wrote:
> Thanks for the info. So if I want to program in Java, am I better off getting
> one of the RCX models and using something like Lejos? I'd be interested in
> what people think of the NXT / RCX comparison...
> Or I could try C but its been a while :-)
> Cheers
>
> Nick
Hi Nick,
You can control the NXT over Bluetooth using Java with iCommand:
www.lejos.org
We are working on a full blown JVM for replacement firmware on the NXT.
- Brian
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, <dickswan@sbcglobal.net> wrote:
>
> There are currently two alternative programming solutions for the NXT.
>
> NBC is a assembly language programming solution that is incorporated as
> part of the BricxCC development environment. It is open source. It uses
> the standard NXT firmware. See http://bricxcc.sourceforge.net/
In terms of Open Source, it should be noted that NBC/BricxCC is the only
currently available alternative on-brick programming solution. It could also be
argued that NBC is the most highly preferred solution because it is available
for Linux, Mac OSX, and Windows platforms. It is the only NXT on-brick
programming solution available for Linux at the present time. It's the only
text-based NXT on-brick programming solution for the Mac. NQC (for all
platforms) is also on its way soon. Admittedly, I'm slightly biased since I am
the lone developer of BricxCC, NBC, NQC (since Dave Baum gave me the job a while
back), and a slew of other NXT-related cross-platform utilities.
> At present, Lego has not released open source firmware for the NXT. They
> have announced their intent to do so.
I suspect that the firmware sourcecode will be released very soon. Once it is I
think that non-open source solutions will quickly fade into obscurity.
John Hansen
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, John Hansen wrote:
>
> I suspect that the firmware sourcecode will be released very soon. Once it is I
> think that non-open source solutions will quickly fade into obscurity.
Not sure I agree with that sentiment - I think there will always be a place
closed-source programming environments, as long as they provide quality
solutions with useful features, and good support.
Having said that, I'd love to see an open-source firmware/environment similar to
BrickOS for NXT, using the gcc toolchain.
ROSCO
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Ross Crawford wrote:
> Having said that, I'd love to see an open-source firmware/environment similar to
> BrickOS for NXT, using the gcc toolchain.
Ross, I demonstrated a gcc toolchain at Brickfest this year, with
a GDB stub running on the NXT and using GDB on a host PC through the
USB cable.
I was able to do a download and single step of a program to toggle
the speaker port and generate sound on the NXT speaker by flipping
bits on an output port "manually"
Once we have access to the firmware source, you'll see a version
of this available freely in a more user friendly package, with
a run-time library of routines to drive the NXT peripherals.
Oh, and I also demonstrated my port of the Lua scripting language
running natively on the NXT, parsing a simple program that initialized
some array values and sorting them - very quickly.
So yes, there will be open source text based scripting languages
available for the NXT shortly, and I'd say Christmas would be
a fun time this year, like the first Mindstorms Christmas...
Cheers, Ralph
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Ross,
Have you been able to reproduce this under Cygwin? I tried about six months ago
but kept hitting some errors in building the toolchain. I used a variety of
build scripts, even trying to reproduce the GNU ARM toolchain but with very
similar error. I did not try their binaries as I wanted to reproduce it myself.
I just was interested if anyone has done this under cygwin?
In lugnet.robotics, Ralph Hempel wrote:
> Ross Crawford wrote:
>
> > Having said that, I'd love to see an open-source firmware/environment similar to
> > BrickOS for NXT, using the gcc toolchain.
>
> Ross, I demonstrated a gcc toolchain at Brickfest this year, with
> a GDB stub running on the NXT and using GDB on a host PC through the
> USB cable.
[SNIP]
>
> Once we have access to the firmware source, you'll see a version
> of this available freely in a more user friendly package, with
> a run-time library of routines to drive the NXT peripherals.
Has anyone heard any more on the timeframe for this? Last I heard it was
supposed to be coming out with the SDKs back in August.
Ed
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Ross Crawford wrote:
> In lugnet.robotics, John Hansen wrote:
> >
> > I suspect that the firmware sourcecode will be released very soon. Once it is I
> > think that non-open source solutions will quickly fade into obscurity.
>
> Not sure I agree with that sentiment - I think there will always be a place
> closed-source programming environments, as long as they provide quality
> solutions with useful features, and good support.
I am not wishing that they fade into obscurity. I just will be extremely
surprised if they don't.
Already a single not very bright individual with no monetary funds, working in
his spare time has produced an open source IDE that is 10-times better than
current proprietary alternatives. And he released a cross-platform open source
text-based programming language solution that supports the standard NXT firmware
well before a commercial alternative became available - even though the
commercial solution had the entire firmware sourcecode at their disposal for
many months before work ever commenced on NBC. Additionally, several powerful
open source NXT utilities and libraries were produced during this same time
frame by just one individual. NQC for the standard NXT firmware is in progress
as is also NQC for the LEGO Robolab 2.9 NXT firmware, and I plan on working on a
brickOS NXT port, if I can find a bit more spare time.
Since the release of the NXT and the SDKs we've started to see a flood of open
source off-brick programming tools and utilities. And it's just the beginning
of what we are about to see once the firmware sourcecode is released.
Ralph Hempel's firmware will almost certainly eclipse the RobotC firmware in
terms of features, programming power, and speed. And Lua is a language that is
soaring in popularity. Michael Barrett Anderson has indicated his intent to
produce an open source RCX2-compatible firmware for the NXT once the firmware
source code is released. I have no doubt it will be extraoridinarily popular.
Brian Bagnall and Jurgen Stuber are working on leJOS for the NXT which will also
draw a huge crowd. Dave Anderson and others have discussed a uCOS
implementation for the NXT which will also be a huge draw - especially in the
university setting. All of these alternative firmwares and programming
languages will be supported in the open source BricxCC IDE and I am sure there
will be Eclipse-based solutions developed as well.
Before long there simply won't be a reason to pay for an alternate firmware and
a second-rate development environment.
John Hansen
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
At 08:41 AM 11/2/06, John Hansen wrote:
> In lugnet.robotics, Ross Crawford wrote:
> > In lugnet.robotics, John Hansen wrote:
> > >
> > > I suspect that the firmware sourcecode will be released very • soon. Once it is I
> > > think that non-open source solutions will quickly fade into obscurity.
> >
> > Not sure I agree with that sentiment - I think there will always be a place
> > closed-source programming environments, as long as they provide quality
> > solutions with useful features, and good support.
>
> I am not wishing that they fade into obscurity. I just will be extremely
> surprised if they don't.
Who cares?
Years ago, we saw many IDEs for the RCX come and go. I suspect for
most people, it was a chance to play with programming and LEGO at the
same time. A challenge to one's self to see if it "can be done". I
doubt any of these were attempts to conquer the world, become famous,
or get rich.
Personally, I've already made several NXT programming tools which
will never see the light of day outside my LEGO workshop. I've made
them because I enjoy the challenge, and I won't publish them, because
I don't think people will find them useful.
> Already a single not very bright individual with no monetary funds, working in
> his spare time has produced an open source IDE that is 10-times better than
> current proprietary alternatives.
It's fine that you have this opinion of yourself, and your
software. However, it's possible people feel different about the software.
> Before long there simply won't be a reason to pay for an alternate
> firmware and
> a second-rate development environment.
>
> John Hansen
It's unfortunate that you choose the same path as many politicians,
and resort to saying so many bad things about the work others have
done. I believe you would earn a great deal more respect by trying
to point out some good work you've done.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Steve Hassenplug wrote:
> I believe you would earn a great deal more respect by trying
> to point out some good work you've done.
ROTFLOL!
John Hansen
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, John Hansen wrote:
> In lugnet.robotics, Ross Crawford wrote:
> > In lugnet.robotics, John Hansen wrote:
> > >
> > > I suspect that the firmware sourcecode will be released very soon. Once it is I
> > > think that non-open source solutions will quickly fade into obscurity.
> >
> > Not sure I agree with that sentiment - I think there will always be a place
> > closed-source programming environments, as long as they provide quality
> > solutions with useful features, and good support.
>
> Before long there simply won't be a reason to pay for an alternate firmware and
> a second-rate development environment.
That's why I qualified it by saying "as long as they provide quality solutions
with useful features, and good support". Yes, RobotC has a way to go before it
gets to the commercially acceptable stage, but that doesn't mean it won't.
And there's also no reason to suppose that an open-source solution couldn't be
commercially viable either - Linux is a great open source operating system, but
many companies now make good money selling and supporting their particular
distributions and tools.
ROSCO
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
This is in reply to the post by John Hansen on Wednesday, November 01.
It's difficult to compare the end user value of an assembler language
programming environment (NBC) vs a high level C programming language
like Robot C. There are several weaknesses in John's post that need to
be put in context. His message is below:
||In terms of Open Source, it should be noted that NBC/BricxCC is the
||only currently available alternative on-brick programming solution.
You're right, RobotC did not support playback of on-brick programming
(OBP). It does now. I simply wrote a C program for it. It's just under
100 lines of code. No big deal! The toughest challenge was figuring out
the format of the playback file!
I had imagined that most 'power' users (and by definition, the readers
of this list are power user) had already deleted the 14K NXT-G on-brick
programming playback file (RPGReader.sys) to recover flash memory space.
I simply hadn't thought that support for this feature was a big deal.
I'm surprized that you couldn't find a higher value potential positive
differentiation for NBC.
Most recent RobotC development time has been spent on much higher value
functionality. There's a great list of very high value firmware features
that are unique to RobotC posted at
http://forums.nxtasy.org/index.php?s=&showtopic=434&view=findpost&p=3652
. There are comparable unique feature lists for both the IDE and
compiler. It's these features that substantiate my "best in class" claim
when RobotC is compared with the alternative programming solutions:
1. Absolutely the best sensor support. Includes not only the standard
Lego sensors but also the emerging 3rd party sensors. RobotC is
particularly strong in support for the Digital I2C sensors.
2. Absolutely the best "watch sensor values and motor encoders" on PC
support. RobotC is only solution at present that allows you to
watch the values of all motor encoders. And it appears to be the
only solution that allows you to watch the values of the Ultrasound
sensors. I regard both these items as "table stakes" features.
3. The best support for motor control through tuning and customization
of the firmware PID algorithms. The end result is that RobotC
drives robots in straighter lines with less waviness; and they stop
when you tell them to without overshoot!
4. The best real-time performance -- meaning program execution times
and speed of motor updates and sensor scanning. I will be
disappointed if RobotC doesn't execute 10X faster than the
alternative solutions; my expectation is probably closer to 20.
All of the above are extremely important in implementing great robots.
Far more important in my mind than OBP. Of course, the list of good
stuff goes on.
5. Best in class sound system support. Includes support for compressed
sound files to reduce usage of the critical flash memory resource.
And includes internal queuing of sounds so that you don't have to
"stall" within your application program waiting for previous sound
to complete.
6. The most feature rich functionality for control over the NXT LCD
display. Extra functions like fill and erase shapes. Precise
control over text placement on the LCD screen. Coupled with high
performance (i.e. fast execution) graphics routines.
And no, contrary to one suggestion, you can't simply use IOMAP
access and user subroutines to provide equivalent functionality.
IOMAP accesses are currently extremely slow! See
http://forums.nxtasy.org/index.php?s=&showtopic=415&view=findpost&p=3799
for an explanation.
7. The only alternative programming solution to support floating point
variables and native trig functions. Extremely important for
accurate dead reckoning robots.
8. The only alterative programming solution that currently supports
interactive PC based debugging. Start/stop/suspend/resume, full
display on PC screen, exception handling, single step at line or
code or instruction level, etc.
I'll cut off the list here so that I can get to other issues.
Back to the OBP. I'm very interested in a direct side-by-side comparison
of RobotC vs NBC for this. There's been many claims about the
compactness of the NBC code. The RobotC program -- attached at the end
of this email compiler to 480 bytes (includes code and constants) and
was 142 lines of which the first 40 was an 'enum' for making the code
more readable -- the enum could easily be replaced if I wanted to use
hard coded constants.
I'd love to see someone develop equivalent NBC program so that they can
be compared. As an incentive I'll offer a "prize" of a NXT digital
compass (either HiTechnic or Mindsensors -- winner decides) to the first
person who posts on LUGNET within a week of this post a NBC program that
compiles to a RXE file size under 1,100 bytes -- i.e. about 1,000 bytes
for compiled code and 100 bytes for file system overhead.
I'll make a similar challenge to the first person that can reproduce the
following RobotC program functionality in NBC in the same timeframe.
Same rules, reward and timeframe as first challenge. This program is
used to play any sound files on the NXT in sequential fashion.
{
string sFileName;
short nSize;
short hFileHandle;
TFileIOResult nIoResult;
FindFirstFile(hFileHandle, nIoResult, "*.rso", sFileName, nSize);
while (nIoResult == ioRsltSuccess)
{
PlaySoundFile(sFileName);
FindNextFile(hFileHandle, nIoResult, sFileName, nSize);
}
while (bSoundActive) () // wait for all sounds to complete.
}
||It could also be argued that NBC is the most highly preferred
||solution because it is available for Linux, Mac OSX, and Windows
||platforms.
Currently NBC has Mac OSX and Linux markets. This is a strong positive
for NBC, if you happen to be the 15% of the population that uses Macs
and/or Linux. I guess it gets that part of the market.
But of course we are talking solutions and not individual components. It
appears the BricxCC, just like RobotC, is currently a Windows only
product. As far as I know NBC is a command line executable on the MAC;
the BricxCC IDE is only available on Windows environment.
||It is the only NXT on-brick programming solution
||available for Linux at the present time. It's the only text-based
||NXT on-brick programming solution for the Mac. NQC (for all
||platforms) is also on its way soon.
Yes. You currently enjoy a unique position in the Mac market. For now!
||Admittedly, I'm slightly biased since I am the lone developer of
||BricxCC, NBC, NQC (since Dave Baum gave me the job a while back),
||and a slew of other NXT-related cross-platform utilities.
Perhaps you have spread yourself too thin and need to focus.
||I suspect that the firmware source code will be released very soon.
||Once it is I think that non-open source solutions will quickly fade
||into obscurity.
The marketplace will determine which solutions survive. Commercial
solutions, like RobotC, will thrive if they continue to have the same
level of positive differentiation that currently exists.
If you read this newsgroup then you're already in a select group of high
end users and are comfortable with low level bit twiddling. But that's a
small percentage of the market.
At a recent city-wide "science week" hundreds of middle school students
went through a 1.5 to 2 hour class where, starting from scratch they
were able to program build and program NXTs in that time. I think it
would be a stretch to have tried to achieve similar success with NBC for
this.
Here's the OBP playback program.
//////////////////////////////////////////////////////////////////////
//
// Playback of On-Brick Programming Files
//
//////////////////////////////////////////////////////////////////////
#pragma fileExtension("sys")
typedef enum
{
cmdType_EMPTY = 0x21, // Empty
cmdTypeForwardUntil = 0x22, // Forward until
cmdTypeForwardFive = 0x23, // Forward 5 rotations
cmdTypeBackLeftTwo = 0x24, // Back left 2 rotations
cmdTypeTurnLeftUntil = 0x25, // Turn left until
cmdTypeTurnLeftTwo = 0x26, // Turn left 2 rotations
cmdTypeBackRightUntil = 0x27, // Back right until
cmdTypeTurnRightUntil = 0x28, // Turn right until
cmdTypeTurnRightTwo = 0x29, // Turn right 2 rotations
cmdTypeBackLeftUntil = 0x2A, // Back left until
cmdTypePlayTone1 = 0x2B, // Tone 1
cmdTypePlayTone2 = 0x2C, // Tone 2
cmdTypeBackwardUntil = 0x2D, // Backward until
cmdTypeBackwardFive = 0x2E, // Backward 5 rotations
cmdTypeBackRightTwo = 0x2F, // Back right 2 rotations
cmdTypeINVALID = 0x30, // Invalid
waitTypeEMPTY = 0x41, // Empty
waitTypeLIGHT = 0x42, // Light
waitTypeSeekObject = 0x43, // Seek obj.
waitTypeSOUND = 0x44, // Sound
waitTypeTOUCH = 0x45, // Touch
waitTwoSeconds = 0x46, // Wait 2 seconds
waitFiveSeconds = 0x47, // Wait 5 seconds
waitTenSeconds = 0x48, // Wait 10 seconds
waitTypeDARK = 0x49, // Dark
waitTypeINVALID = 0x4A, // Invalid
} TCommands;
tMotor motorRight = motorB;
tMotor motorLeft = motorC;
tSensors touch = S1;
tSensors light = S2;
tSensors mike = S3;
tSensors sonar = S4;
const string sFileName = "Program.tmp";
TFileIOResult ioResult;
uword hFile;
uword nFileSize;
uword nProgramStep = -1;
TCommands getNextCommand()
{
TCommands nCommand;
++nProgramStep;
nOnBrickProgrammingStep = nProgramStep;
ReadByte(hFile, ioResult, nCommand);
return (ioResult == ioRsltSuccess) ? nCommand : cmdTypeINVALID;
}
void stopMotors()
{
motor[motorRight] = 0;
motor[motorLeft] = 0;
}
void motorControl(TSynchedMotors nSyncType, int nPower, int nTurn, int
nTarget)
{
tMotor nPrimeMotor;
nSyncedMotors = nSyncType;
nPrimeMotor = (nSyncType == synchBC) ? motorB : motorC;
nMotorEncoderTarget[nPrimeMotor] = nTarget;
motor[nPrimeMotor] = nPower;
nSyncedTurnRatio = nTurn;
return;
}
bool processNextCommand()
{
switch (getNextCommand())
{
case cmdTypeForwardUntil: motorControl(synchBC, 75, 100, 0);
break;
case cmdTypeForwardFive: motorControl(synchBC, 75, 100, 360 *
5); break;
case cmdTypeTurnLeftUntil: motorControl(synchCB, 75, 50, 0);
break;
case cmdTypeTurnLeftTwo: motorControl(synchCB, 75, 50, 360 *
2); break;
case cmdTypeTurnRightUntil: motorControl(synchBC, 75, 50, 0);
break;
case cmdTypeTurnRightTwo: motorControl(synchBC, 75, 50, 360 *
2); break;
case cmdTypeBackwardUntil: motorControl(synchBC, -75, 100, 0);
break;
case cmdTypeBackwardFive: motorControl(synchBC, -75, 100, 360 * 5);
break;
case cmdTypeBackRightUntil: motorControl(synchBC, -75, 50, 0);
break;
case cmdTypeBackRightTwo: motorControl(synchBC, -75, 50, 360 * 2);
break;
case cmdTypeBackLeftUntil: motorControl(synchCB, -75, 50, 0);
break;
case cmdTypeBackLeftTwo: motorControl(synchCB, -75, 50, 360 * 2);
break;
case cmdTypePlayTone1: PlayTone(440, 2000); while (bSoundActive)
{}; break;
case cmdTypePlayTone2: PlayTone(440, 5000); while (bSoundActive)
{}; break;
case waitTypeSeekObject:while (SensorValue[sonar] > 25) {};
stopMotors(); break;
case waitTypeSOUND: while (SensorValue[mike] < 400) {};
stopMotors(); break;
case waitTypeTOUCH: while (SensorValue[touch] > 25) {};
stopMotors(); break;
case waitTypeLIGHT: while (SensorValue[light] < 50) {};
stopMotors(); break;
case waitTypeDARK: while (SensorValue[light] > 30) {};
stopMotors(); break;
case waitTwoSeconds: wait1Msec( 2000);
stopMotors(); break;
case waitFiveSeconds: wait1Msec( 5000);
stopMotors(); break;
case waitTenSeconds: wait1Msec(10000);
stopMotors(); break;
case waitTypeINVALID: break;
case cmdType_EMPTY: break;
case cmdTypeINVALID: return false;
default: return false;
}
return true;
}
task main()
{
nVolume = 3;
SensorType[touch] = sensorTouch;
SensorType[mike] = sensorSoundDB;
SensorType[light] = sensorLightActive;
SensorType[sonar] = sensorSONAR9V;
OpenRead(hFile, ioResult, sFileName, nFileSize);
if (ioResult == ioRsltSuccess)
{
int i;
const int kFileHeaderSize = 8;
for (i = 0; i < kFileHeaderSize; ++i)
getNextCommand();
nProgramStep = -1;
while (processNextCommand())
{}
Close(hFile, ioResult);
}
return;
}
| | | | | | | | | | | | | | | | | | | | | | |
A few corrections/updates to my original post
atnews:000501c701ed$52bc7d70$070ba8c0@dickdesktop...
I was wrong in stating BricxCC does not support reading of all three
NXT motor encoders. My comment was based on the BRicxCC "Wathcing the
brick window; this is a legacy RCX/Cybermaster/etc window which
has'watch' capability for the integrated Cybermaster motor encoders.
This encoder watching also works for the NXT's motors A and C. I was
not familiar enough with BricxCCto know that it also has a
"Configurable Watch Window" that is able to selectively view all three
NXT motor encoders.
There area couple of small bug in the RPGReader.prg program. It
requires the use of the RobotC 1.0.26 release which should be posted
tomorrow. This release will also include the updated RPGReader.c
source file among its sample programs.
| | | | | | | | | | | | | | | | | |
In article <7122549.post@talk.nabble.com>, Nick77 <lego-
robotics@crynwr.com> writes
> Hi,
>
> Thinking of getting the NXT kit, just wanted to know what programming
> languages / sdks are out there. I looked on the Lejos site, and it seems
> like they were thinking about porting for NXT but it seems to have gone
> quiet recently. Ideally I'd like to be able to develop in Java...
I have not looked at Lejos yet, (shame on me), but Brian Bagnall seems
particularly active with this.
There are new releases about once a month, with October's release just
announced today in the news://lugnet.robotics.nxt newsgroup:
http://news.lugnet.com/robotics/nxt/?n=206
There is also a book due out in January:
http://www.amazon.com/Maximum-Lego-NXT-Building-Brains/dp/0973864915
I have also seen reports of someone developing a Java library for a PC
to communication with a NXT.
Hope that helps,
Tony
--
The NXT Step blog discusses the Lego Mindstorms NXT:
http://thenxtstep.blogspot.com/
| | | | | | | | | | | | | | | | | |
| |
|
Thanks for info and all replies - looks like there are a few options, and
stuff in the pipeline! Now I get to spend my hard earned cash!
Cheers
Nick
Tony Naggs wrote:
>
> In article <7122549.post@talk.nabble.com>, Nick77 <lego-
> robotics@crynwr.com> writes
> > Hi,
> >
> > Thinking of getting the NXT kit, just wanted to know what programming
> > languages / sdks are out there. I looked on the Lejos site, and it seems
> > like they were thinking about porting for NXT but it seems to have gone
> > quiet recently. Ideally I'd like to be able to develop in Java...
>
> I have not looked at Lejos yet, (shame on me), but Brian Bagnall seems
> particularly active with this.
>
> There are new releases about once a month, with October's release just
> announced today in the news://lugnet.robotics.nxt newsgroup:
> http://news.lugnet.com/robotics/nxt/?n=206
>
> There is also a book due out in January:
> http://www.amazon.com/Maximum-Lego-NXT-Building-Brains/dp/0973864915
>
>
> I have also seen reports of someone developing a Java library for a PC
> to communication with a NXT.
>
>
> Hope that helps,
> Tony
> --
> The NXT Step blog discusses the Lego Mindstorms NXT:
> http://thenxtstep.blogspot.com/
>
>
--
View this message in context: http://www.nabble.com/NXT-What-Programming-Languages-%2B-Open-source--tf2555941.html#a7130598
Sent from the LEGO Robotics mailing list archive at Nabble.com.
| | | | | | | | | | | | | | | | | |
| |
|
Nick,
Sorry for being late, but before you spend your money it might be useful
to have a look at the list of available programming environments for the
NXT listed at
http://mynxt.matthiaspaulscholz.eu/tools/index.html
It should be pretty complete and I tried most of them with a real task
for a real robot.
Of particular interest for people that want to program the NXT with Java
might be ICommand, derived from leJOS and hosted on lejos.org.
Regards,
Matthias
Nick77 wrote:
> Thanks for info and all replies - looks like there are a few options, and
> stuff in the pipeline! Now I get to spend my hard earned cash!
> Cheers
> Nick
>
> Tony Naggs wrote:
>
> > In article <7122549.post@talk.nabble.com>, Nick77 <lego-
> > robotics@crynwr.com> writes
> >
> > > Hi,
> > >
> > > Thinking of getting the NXT kit, just wanted to know what programming
> > > languages / sdks are out there. I looked on the Lejos site, and it seems
> > > like they were thinking about porting for NXT but it seems to have gone
> > > quiet recently. Ideally I'd like to be able to develop in Java...
> >
> > I have not looked at Lejos yet, (shame on me), but Brian Bagnall seems
> > particularly active with this.
> >
> > There are new releases about once a month, with October's release just
> > announced today in the news://lugnet.robotics.nxt newsgroup:
> > http://news.lugnet.com/robotics/nxt/?n=206
> >
> > There is also a book due out in January:
> > http://www.amazon.com/Maximum-Lego-NXT-Building-Brains/dp/0973864915
> >
> >
> > I have also seen reports of someone developing a Java library for a PC
> > to communication with a NXT.
> >
> >
> > Hope that helps,
> > Tony
> > --
> > The NXT Step blog discusses the Lego Mindstorms NXT:
> > http://thenxtstep.blogspot.com/
> >
> >
>
>
| | | | | | |
