|
|
| |
I’ve been working with José David Parra on the next version of his
RCX.NET project, because 1.) the NXT system is
coming out, and 2.) RCX.NET is basically a .NET wrapper of Spirit.ocx, which
means it’s not so nice to program with.
Another project, Lego.NET, has as its goal to get part of the .NET Framework running on the RCX,
similar to the leJOS VM, except it doesn’t have its own custom firmware (it uses
the BrickOS firmware).
Our project’s goal is to simply let people write programs for Mindstorms bricks
using .NET languages. The Control Lab programs would have to run on the machine,
but the Scout, RCX, and NXT programs would be compiled to LASM and uploaded to
the brick. (Or not. I would like to give people the option to do either.)
Recently I acquired a DACTA Control Lab Interface, which some of you know is the
predecessor to the RCX. It is a simple I/O device, meaning all programs for it
run on the computer, but it uses the same 9V sensors and outputs the newer
Mindstorms system does. I have started
writing a C# control class for it, and now that I have the low-level
communication working, I need to design an API that José and I can also use for
the RCX and NXT systems. The goal is to provide a consistent programming
interface for people to use, regardless of what brick they’re using.
Consider this example C# code. It shows a small part of the API I have in mind
for the redesign of RCX.NET, so I’d like some comments on how people would like
to use this system.
using Mindstorms.ControlLab;
using Mindstorms.RCX2;
class Test
{
// boilerplate
// inside main() or Form1.Load(), etc.
{
ControlLab controlLab = new ControlLab(); // uses "COM1"
RCX2 rcx = new RCX2("COM2");
}
}
|
|
That’s simple object creation. The question now becomes “Should users have to
create ports and sensors explicitly, or just set the sensor type and what
channel it’s on?”
If programmers should be required to create Port objects themselves, then
creating a sensor would look something like this:
Sensor lightSensor = new LightSensor();
rcx.AddSensor(lightSensor, new InputPort("2"));
controlLab.AddSensor(new TouchSensor(new InputPort("1")));
|
|
On the other hand, creating those ports is tedious, especially for the Control
Lab which has 16 ports (8 input, 8 output). Why not simply do this?
rcx.AddSensor(new LightSensor("2")); // will be on port 2
controlLab.SetSensor("1", new TouchSensor()); // will be on port 1
|
|
In this example the RCX and ControlLab objects have created Ports themselves
inside their constructors. This does mean, though, that there could be Port
objects sitting around unused.
I’m simply wondering how much of the internal workings I should want to expose
to programmers. Would there ever be a need to keep references to Port objects?
The only case I can think of is the IR port on the RCX, which is both input
and output.
|
|
| |
Hi all,
Thank you if you completed the survey about your chosen development environment.
Early results are as follows:
48% of respondents use NQC as their main language.
NQC scores 1.6 for usefulness, 1.5 for ease of use and 2.1 for enjoyment. (1 is
the best, 6 is the worst).
18% use Robolab
Robolab scores 2.2 for usefulness, 1.6 for ease of use and 1.5 for enjoyment.
18% use brickOS/C
6% use RCX-code
9% use Java
90% of respondents have been male. The average age of all respondents is 38.
No further analyses have been performed yet.
There is still time to complete the survey at:
http://www.nottingham.ac.uk/~liztc/RobotSurvey.html
Thank you,
Thomas
|
|
| |
Hi,
I am very interested (for a variety of reasons) in which programming language
people are using to build robots. I wonder if you would fill in a questionnaire
about it at:
http://www.nottingham.ac.uk/~liztc/RobotSurvey.html
It's all about how useful, easy and enjoyable your chosen language is.
If anyone does, I will summarise the results on a web page and post up the URL.
Thank you
Thomas
|
|
| |
In lugnet.robotics.scout, Joseph A. O’Donnell wrote:
| |
In lugnet.robotics, Mike Kollross wrote:
| |
I was playing around with my Scout and using a microscout as a third motor
using the VLL and fibre optics.
|
...SNIP...
| |
Thought I would share.
Mike
|
Really nice combination!
Do you have any sample code, either regular Mindstorms or NQC, that runs the
combo. I’d love to try...
Joseph
|
I haven’t tried it with a program on the Scout yet but the scout uses the third
motor commands to send VLL and the Microscout accepts VLL commands when running
the “P” program. The scout also accepts motor commands from the LEGO remote
without a program running, which is how I tested the motor setup.
Mike
|
|
| |
In lugnet.robotics, Mike Kollross wrote:
| |
I was playing around with my Scout and using a microscout as a third motor
using the VLL and fibre optics.
|
...SNIP...
| |
Thought I would share.
Mike
|
Really nice combination!
Do you have any sample code, either regular Mindstorms or NQC, that runs the
combo. I’d love to try...
Joseph
|
|
|
