Re: Mindstorms.NET Request for Comments

My first inclination is that the ports should be fixed in the
constructor, since you have fixed number of ports on the hardware. 
This would prevent you from adding more ports than the hardware can
support.  With NXT this may change.  Since I don't know how NXT ports
are handled, you may be able to multiplex the ports and create as many
as possible.

Just my 2 cents.

Louis

On 4/17/06, Jordan Bradford
<[email protected]> wrote:
> I've been working with José David Parra on the next version of his
> <http://www.geeksco.com/rcxnet/ 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, <http://www.dcl.hpi.uni-potsdam.de/research/lego.NET/
> 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 <http://news.lugnet.com/robotics/?n=25787 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.
>