simlink-develop Mailing List for Rossum to leJOS Bridge
Status: Beta
Brought to you by:
gumbo
Menu
▾
▴
simlink-develop — List for developers and ideas for Simlink
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(6) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Andy G. <gom...@ea...> - 2002-09-02 22:17:53
|
Simlink 1.0 final has been released with many improvements. I didn't = make a Changelog (something I am starting now), so there isn't a big = list of things I did. Basically, it is more stable, works better, and = has more features. Download it and try it out for yourself.=20 https://sourceforge.net/project/showfiles.php?group_id=3D32200&release_id= =3D108569 (281 KB) Andy |
|
From: Andy G. <gom...@ea...> - 2002-08-23 03:05:01
|
When this topic was brought up before, several people indicated they may = be interested in helping me implement this model. I can't find the = messsages right now (I can't access the archives), but I wanted to = restate some thoughts/new ideas so work can begin. Basic IR communciation would ignore the effects of IR transmission = range, light characteristics, etc. A socket link would be established = between the driver code and the leJOS comm routines, allowing = communication no matter the situation of the robot. Raycasting or other = techniques can determine if the IR tower is in range and is visible, and = a flag is set in one of the communicators. This effectively causes the = host to stop sending data, or the client (robot) to stop listening to = any new data receieved. =20 An accurate light model could involve raycasting from the source, and = using simple geometry to determine where the ray impacts a barrier, what = the angle of incidenc/reflection is, and how far it will travel before = it is undetectable. If my TI83+ can run a raycaster with texturing = quite fast, I would expect a full PC to be able to handle this with no = problem. Thoughts? |
|
From: Andy G. <gom...@ea...> - 2002-04-28 01:21:26
|
I am implementing the indicators that show when a motor or sensor is = active, using a translucent red JLabel. =20 The lables are moved around using the JLayeredPane parent, which was = faster than setting setOpaque(false), and a subsequent repaint. Anyway, I have a small decision. The sensors deactivate after a = certain period of time, currently .75 seconds. This will eventually be = user adjustable, but the main point is to get it working now, before I = hack apart the options. ;-) The motors currently never deactivate. I cannot think of a situation = except where a motor is not accessed where it cannot be in one of 4 = states - Forward, Reverse, Stop, or Float. If this is true, then I = don'[t have anything to worry about. A symbol for Float and I will be = done. However, if a motor should not show an active status after a = certain period, in your opinion, what should the time delay be? All I = have to do is setup another javax.swing.Timer, identical to the sensor = delay, so it is not that much work. Any thoughts? The new release should also have about 50 error message = boxes, a new installer using IzPack, and improved malformed input = acceptance. Andy |
|
From: Andy G. <gom...@ea...> - 2002-03-28 02:07:21
|
Simlink v1.0 alpha is available for testing at = http://simlink.sourceforge.net/files/simlink.zip It is very rough, and = many errors are not caught - you get a stack trace or quit. I especially need to know if any text is being printed to your output - = I think I eliminated it all, but some stuff almost never gets called. I = also would like feedback on the relative stability of Simlink - it = requires knowledge of the information required, but I think the Readme = explains it. I also chose a value for motor speed from some very quick = and innacurate testing. If you can change Motor.java and find a value = more suitable, please tell me. It looks right, but it may prove not to = be. Anyway, enjoy. Keep in mind that this is an alpha release - don't get your hopes up too = high. ;-) Requesting feedback, Andy |
|
From: Andy G. <gom...@ya...> - 2002-03-02 23:15:10
|
Hello all, I am almost ready to release Simlink v.01 pre alpha for pre-alpha = testing. Much functuality is not working, such as Sensor listeners - = note that regular polling works though. Motors function, but I need = your help in determining an appropriate scaling value. A few minutes of = experimentation and some luck does not mean that the motion is accurate. = :) I still have to incorperate everything into the GUI, and get the = robot class to load correctly. Anyway, with this upcoming release I have started to look at the Rossum = and leJOS licences and what effect they have. Since Rossum is GPL and = leJOS is MPL, according to the GNU Licences page I cannot even develop = software with the two together. I cannot ask Jose, Paul, or Jurgen = nicely to change to the GPL, since Kekoa Proudfoot's librcx code was = used - it was licenced under the MPL, forcing leJOS to be in the first = place. My original workwaround was to tell users to download both leJOS and = Rossum, then my installer would copy all the files over and replace the = modified copies. This looks like it would have no legal effect, and no = matter how it happens, I cannot install the two differently licensed = packages into the same directory, much less modify both of them.=20 I do not know if I distribute this under the MPL if I can use both = packages - of course, distributing the Java portion of the code under = the GPL is legal and would hopefully make the entire project legal. Expect some final interface screenshots tomorrow/Monday, and a composite = action pic when I get the release out. Any thoughts or comments are welcome, Andy |
|
From: Andy G. <gom...@ya...> - 2002-01-29 22:47:03
|
Okay, I have more time now that I am not getting ready to go to school. =
:)
Yes, the first thing that is chosen is the lejosc compiled class that =
contains a main method. This class is also linked into the modified =
leJOS classes. I would like to have buttons or something to launch =
installed Rossum tools, but unfortunately, none have been created. I =
have thought about creating a floor plan editor after Simlink is =
working, to aid in usage, which shouldn't be that hard. A Java Canvas =
that can draw lines based on the mouse pointer, and a reference box in =
meters, cm, feet or in to guage distances. A body plan editor would be =
much harder, and not something I would want to write right now.
When you get simlink configured directly and start a simulation, the =
Rossum window (The floor plan area) will pop up. It could be started =
before, but to control speed and logging, it must have a .ini file as an =
argument (java Server -p simlink.ini). Then, the specified body plan =
will be shown, and the label above the exception area that shows the =
running class will be set (so you know the robot actually started). =
Whenever a program requests that a Sensor be read or a Motor turned on, =
the appropriate port will turn from black to red, indicating usage. =
This is similar to the different icons that appear on the real LCD. =
Perhaps Motors will be a different color based on thier direction, but I =
am not sure. Anyway, the robot should move around then, and any LCD =
messages will come up. All control is directed from the robot program, =
unless, when the serial tower is somehow implemented (I need to redirect =
serial communications to an input so I can communicate to external, PC =
based robot programs), the PC can control the action (it is handled =
transparently, though). =20
Is that a good enough description? I am not sure on a lot since it is =
not working yet, but it is how I envision it. Whether those options =
prove to be too difficult to implement, I don't know. :)
I just hope it doesn't turn out half-baked like lVI did. I had a whole =
slew of upgrades ready, but a hard drive crash left me without a current =
backup. I had not gotten CVS to work yet, so I got kind or discouraged =
and quit.
Andy
----- Original Message -----=20
From: Brian Bagnall=20
To: sim...@li...=20
Sent: Tuesday, January 29, 2002 5:25 AM
Subject: Re: [Simlink-develop] Screenshots of interface up (alpha)
Hi Andy,
I like the look of things. If you want to go for the extra level of =
spiffiness I could render the face of the RCX brick instead of using the =
current abstract visuals, and then the LCD could be nicely superimposed =
on the image. I have a few questions regarding the usage. It looks like =
the first thing a programmer would do is set up their simulation run by =
choosing the class with the main() method - is this going to be a =
compiled class or java source code? Floor plan and body plan are =
obviously files handled by Rossum. It would be nice to be able to click =
a button on the GUI that would automatically launch some Rossum tools =
(if these exist) for quick editing. Now let's say I have my simulation =
run all ready and I start to run it, what will I see and what kind of =
interactions could I do with it?
Looking like a very cool project so far!
Brian
----- Original Message -----=20
From: Andy Gombos=20
To: sim...@li...=20
Sent: Sunday, January 27, 2002 9:24 AM
Subject: [Simlink-develop] Screenshots of interface up (alpha)
I know Brian expressed intrest in seeing what the implementation =
would look like, so I put screenshots up for you to look at. :) If you =
see any problems with features, like the generated exceptions list I am =
not sure how I am going to implement (I need to see how the leJOS code =
prints it to the LCD, hopefully it is Java). Eventually there will be a =
toolbar with quick access to the features, and hopefully a debugger of =
sorts that shows the current line being executed - first I have to learn =
how to use the JDPA.
Please comment.
Andy
|
|
From: Brian B. <bba...@mt...> - 2002-01-29 10:26:37
|
Hi Andy, I like the look of things. If you want to go for the extra level of = spiffiness I could render the face of the RCX brick instead of using the = current abstract visuals, and then the LCD could be nicely superimposed = on the image. I have a few questions regarding the usage. It looks like = the first thing a programmer would do is set up their simulation run by = choosing the class with the main() method - is this going to be a = compiled class or java source code? Floor plan and body plan are = obviously files handled by Rossum. It would be nice to be able to click = a button on the GUI that would automatically launch some Rossum tools = (if these exist) for quick editing. Now let's say I have my simulation = run all ready and I start to run it, what will I see and what kind of = interactions could I do with it? Looking like a very cool project so far! Brian ----- Original Message -----=20 From: Andy Gombos=20 To: sim...@li...=20 Sent: Sunday, January 27, 2002 9:24 AM Subject: [Simlink-develop] Screenshots of interface up (alpha) I know Brian expressed intrest in seeing what the implementation would = look like, so I put screenshots up for you to look at. :) If you see = any problems with features, like the generated exceptions list I am not = sure how I am going to implement (I need to see how the leJOS code = prints it to the LCD, hopefully it is Java). Eventually there will be a = toolbar with quick access to the features, and hopefully a debugger of = sorts that shows the current line being executed - first I have to learn = how to use the JDPA. =20 Please comment. =20 Andy |
|
From: Andy G. <gom...@ya...> - 2002-01-27 15:25:21
|
I know Brian expressed intrest in seeing what the implementation would = look like, so I put screenshots up for you to look at. :) If you see = any problems with features, like the generated exceptions list I am not = sure how I am going to implement (I need to see how the leJOS code = prints it to the LCD, hopefully it is Java). Eventually there will be a = toolbar with quick access to the features, and hopefully a debugger of = sorts that shows the current line being executed - first I have to learn = how to use the JDPA. Please comment. Andy |
|
From: Andy G. <gom...@ya...> - 2002-01-11 12:29:39
|
Thanks for the input. :)
The target sensor appears to be, as far as I can tell, sort of like a =
proximity sensor like you said. The floor plan targets have a center =
point, and probably an influence or strength factor as well. The target =
sensor essentially returns true or false, depending on if the target =
sensor detects the target at all. It is hard to find the exact return =
values (tat would be useful) from the TargetSensorEvent. Using the =
cheating fields of distance and the vector pointing to the target, a =
solution should be workable.
I guess for now power will not be implemented, speed only being =
controlled when you create the RsWheelSystem(m/s).
Andy
----- Original Message -----=20
From: Brian Bagnall=20
To: sim...@li...=20
Sent: Friday, January 11, 2002 4:32 AM
Subject: Re: [Simlink-develop] Implementing the Motor and Sensor =
classes
Hi Andy,
Definitely implement range sensor if possible. I've seen lots of =
plans for them on the internet and even have one myself. Contact of =
course. I'm a little confused by target sensor. You describe it as a =
light sensor, but are you sure it isn't a proximity detector? i.e. A =
sensor that detects if an object is within a defined perimiter. It =
sounds like maybe Rossum doesn't have a true light sensor defined. Maybe =
this is something we can define - and if so we would need to come up =
with a simplified model of how light reacts to a sensor, which might be =
as you describe - proportional to distance. (We don't want to do =
something overcomplex like making a complete ray tracing program.)
For motor control, it's a shame Rossum doesn't just control motion =
with independent motors. Somehow the Rossum to leJOS link is going to =
have to translate all the motor commands to the appropriate rossum =
movement. e.g. Motor.A.forward() and Motor.C.backward() =3D =
RsClient.rotateLeft() [or something to that effect]. There are a lot of =
combinations though.
My experience with motors tells me technically changing the power to =
the motor does not alter speed. The only thing power changes is the =
torque (rotational force), not the actual speed. (I wish it was possible =
to alter the speed of a lego motor). So it really shouldn't be a factor.
Can't wait to see what you come up with for an interface.
Brian
----- Original Message -----=20
From: Andy Gombos=20
To: sim...@li...=20
Sent: Thursday, January 10, 2002 7:05 PM
Subject: [Simlink-develop] Implementing the Motor and Sensor classes
I have started work on the simulator in earnest due to a virtual 1 =
month deadline. I have finally gotten around to deciding the structure =
of the simulator interface, and wanted your guys input. :) =20
For the Sensor class, new listeners are being written that morph the =
Rossum events into leJOS events. With some constructor changing, I =
think events will work properly. What about the actual sensor values? =
Using private listeners that are automatically registered to poll =
sensors, I can only get the canonical value of the contact, range, and =
target sensors. Also, if you read the Users Manual, the return values =
for the target sensor are less than perfect. A range sensor is really =
only a custom sensor, but will probably be implemented due to relative =
ease. The target sensor are what I have no clue on. The PDF appears to =
only allow a detected or not detected state for a point target - a light =
source. To use this as a light sensor, I think the distance to the =
target would have to be used, and then the intensity of the light =
calculated. Does this seem like a good approach? Does anyone else have =
any ideas?
The Motor class is much harder. RsClient.sendMotionHaltRequest() =
stops both motors, so some creative behind the scenes managing will be =
necessary. Unfortunately, power levels are not a simulator concept. =
They can be semi-set with the body plan spec, but that determines the =
speed of the robot (using RsWheelSystem) like gear reductions, more than =
a power decrease that lowers speed. Perhaps the movement time can be =
calculated to make it seem like the bot goes slower? Again, I would =
appreciate anyone's input. :P
Thanks for any input,
Andy
|
|
From: Brian B. <bba...@mt...> - 2002-01-11 09:32:44
|
Hi Andy, Definitely implement range sensor if possible. I've seen lots of plans = for them on the internet and even have one myself. Contact of course. = I'm a little confused by target sensor. You describe it as a light = sensor, but are you sure it isn't a proximity detector? i.e. A sensor = that detects if an object is within a defined perimiter. It sounds like = maybe Rossum doesn't have a true light sensor defined. Maybe this is = something we can define - and if so we would need to come up with a = simplified model of how light reacts to a sensor, which might be as you = describe - proportional to distance. (We don't want to do something = overcomplex like making a complete ray tracing program.) For motor control, it's a shame Rossum doesn't just control motion with = independent motors. Somehow the Rossum to leJOS link is going to have = to translate all the motor commands to the appropriate rossum movement. = e.g. Motor.A.forward() and Motor.C.backward() =3D RsClient.rotateLeft() = [or something to that effect]. There are a lot of combinations though. My experience with motors tells me technically changing the power to the = motor does not alter speed. The only thing power changes is the torque = (rotational force), not the actual speed. (I wish it was possible to = alter the speed of a lego motor). So it really shouldn't be a factor. Can't wait to see what you come up with for an interface. Brian ----- Original Message -----=20 From: Andy Gombos=20 To: sim...@li...=20 Sent: Thursday, January 10, 2002 7:05 PM Subject: [Simlink-develop] Implementing the Motor and Sensor classes I have started work on the simulator in earnest due to a virtual 1 = month deadline. I have finally gotten around to deciding the structure = of the simulator interface, and wanted your guys input. :) =20 =20 For the Sensor class, new listeners are being written that morph the = Rossum events into leJOS events. With some constructor changing, I = think events will work properly. What about the actual sensor values? = Using private listeners that are automatically registered to poll = sensors, I can only get the canonical value of the contact, range, and = target sensors. Also, if you read the Users Manual, the return values = for the target sensor are less than perfect. A range sensor is really = only a custom sensor, but will probably be implemented due to relative = ease. The target sensor are what I have no clue on. The PDF appears to = only allow a detected or not detected state for a point target - a light = source. To use this as a light sensor, I think the distance to the = target would have to be used, and then the intensity of the light = calculated. Does this seem like a good approach? Does anyone else have = any ideas? =20 The Motor class is much harder. RsClient.sendMotionHaltRequest() = stops both motors, so some creative behind the scenes managing will be = necessary. Unfortunately, power levels are not a simulator concept. = They can be semi-set with the body plan spec, but that determines the = speed of the robot (using RsWheelSystem) like gear reductions, more than = a power decrease that lowers speed. Perhaps the movement time can be = calculated to make it seem like the bot goes slower? Again, I would = appreciate anyone's input. :P =20 Thanks for any input, =20 Andy =20 |
|
From: Andy G. <gom...@ya...> - 2002-01-11 01:06:59
|
I have started work on the simulator in earnest due to a virtual 1 month = deadline. I have finally gotten around to deciding the structure of the = simulator interface, and wanted your guys input. :) =20 For the Sensor class, new listeners are being written that morph the = Rossum events into leJOS events. With some constructor changing, I = think events will work properly. What about the actual sensor values? = Using private listeners that are automatically registered to poll = sensors, I can only get the canonical value of the contact, range, and = target sensors. Also, if you read the Users Manual, the return values = for the target sensor are less than perfect. A range sensor is really = only a custom sensor, but will probably be implemented due to relative = ease. The target sensor are what I have no clue on. The PDF appears to = only allow a detected or not detected state for a point target - a light = source. To use this as a light sensor, I think the distance to the = target would have to be used, and then the intensity of the light = calculated. Does this seem like a good approach? Does anyone else have = any ideas? The Motor class is much harder. RsClient.sendMotionHaltRequest() stops = both motors, so some creative behind the scenes managing will be = necessary. Unfortunately, power levels are not a simulator concept. = They can be semi-set with the body plan spec, but that determines the = speed of the robot (using RsWheelSystem) like gear reductions, more than = a power decrease that lowers speed. Perhaps the movement time can be = calculated to make it seem like the bot goes slower? Again, I would = appreciate anyone's input. :P Thanks for any input, Andy |
|
From: Andy G. <gom...@ya...> - 2001-09-04 02:26:32
|
I have recently been tied up in my personal life, and could not post to = this list like I promised. Sorry for any who have waited/lost intrest. = :) Does anyone have any idea of what features that need to be = implemented, or would like to help? I kind-of have an idea of what to = do for the basic link, but any extras would be a benifit. =20 Andy |
