Subject:
|
RE: NXT What Programming Languages + Open source?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 6 Nov 2006 21:48:40 GMT
|
Reply-To:
|
<dickswan@sbcglobal.netSTOPSPAMMERS>
|
Viewed:
|
3881 times
|
| |
|
|
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;
}
|
|
Message has 1 Reply:
 | | Re: NXT What Programming Languages + Open source?
|
| A few corrections/updates to my original post atnews:000501c701ed$...desktop... 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 (...) (18 years ago, 10-Nov-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: NXT What Programming Languages + Open source?
|
| (...) 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 (...) (18 years ago, 1-Nov-06, to lugnet.robotics)
|
17 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
