headers
Todd Thuma | 9 May 2006 19:05
Picon

Lego Education Pamphlet indicates a NXT to old style brick adapter cable

NXT Fans,

In my new position at Indian River Community College I work with faculty in
technical education and have joined the Robotics club. We are excited by the
upcoming release of Mindstorms NXT, and I have personnally ordered my own set
already.

A flyer just arrived in the mail from Lego Education that describes the new
product. One of the interesting aspects of the flyer is a picture on page three
of a cable that bridges the gap from a Mindstorms RCX connector, the 2x2 black
plate with electrical contacts, to the new RJ style NXT connector. 

This may have been discussed previously, but I think that its great that old
sensors and motors will have a cable that will connect them to the new system.

I will try to scan in an image of the flyer and post it here.

Todd
Permalink | Reply | 0 comments |
headers
Philippe Hurbain | 9 May 2006 08:57
Picon
Favicon

Re: NXTway

In lugnet.robotics, Steve Dunn wrote:
> Very cute. I like how it fell over.
>  How does it go on unlevel surfaces ?
I didn't try. Probably not well since it is quite unstable.

> Now im off to build a self leveling touch sensor.
>
> Does the NXT have on/off touch sensors like the RCX or variable (analogue)
> sensors like a playstation controller?

No, it's a simple on/off. The great improvement is that the contact occurs at
half stroke, you don't have to push hard as with RCX touch sensors.

Philo
Permalink | Reply | 0 comments |
headers
John Brost | 10 May 2006 16:05
Picon

Re: NXT newsgroup needed

In lugnet.robotics, Suzanne Rich wrote:

> I'm holding off on creating a new group for a few reasons. One is: when more
> information comes to light about the NXT, it may become apparent that 'RCX' is a
> good place for discussion of it.

As I've been one of the lucky few who have had the opportunity to play with the
NXT as part of the MDP, I can tell you that these two are vastly different
beasts.  I've found the hardware, software, even building techniques to be
significantly different using the NXT vs. my trusty RCXs.  Yes, there is some
overlap, but I think there is going to be a lot of NXT only discussions,
especially software related.  This is the concern I think others have been
alluding to.  I like the idea of separate groups not because I can filter out
either set of discussions (RCX vs. NXT) but I can look at each one individually
without the chance of missing an important message in either.  

This leads me to the NeXT point.  Others have pointed to the number of NXT
related posts already.  YOU HAVEN"T SEEN ANYTHING YET!  If my experience in the
MDP has taught me anything, it is that there will be LOTS of discussion.  

> If the consensus remains that NXT hardware is significantly different than any
> other, and it's discussion is offensive to the other robotics sub-groups, then I
> will surely create a new group, and I'll do it soon. I believe this is likely.

Personally I don't think "offensive" is the correct term, but what I would hate
to see is people who post here looking for help with an RCX related issue only
to have their question lost in the sea of NXT posts (especially new visitors, as
this may turn them off to LUGNET).  In my mind, it is simply a # of posts and
convenience issue.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Byrne | 10 May 2006 16:19

Re: Lego Education Pamphlet indicates a NXT to old style brick adapter cable

In lugnet.robotics, Philippe Hurbain wrote:
> Oh... nice little devices you make me discover! They would be wonderful through
> a technic turntable. But all of these gizmos I've seen on the web have only 4
> contacts (NXT wires have 6), do you know some of them with 6 contacts?
>
> Also, I fear some rapid wear if used with motors in heavy duty applications
> (high currents)
>
> Philo

Alas, I've only seen the phone ones.  I used one through a turntable with the
RCX cables, but of course that's only two wires.  (Actually I used all four
wires and basically sent two RCX cables through the one "detangler").  I would
imagine they have some 6 pin version somewhere, or perhaps one with RJ-45, but
several google searches have turned up nothing :(

-Tim
Permalink | Reply | 0 comments |
headers
Steve Dunn | 9 May 2006 05:37
Picon

Re: NXTway

Very cute. I like how it fell over.
 How does it go on unlevel surfaces ?
Now im off to build a self leveling touch sensor.

Does the NXT have on/off touch sensors like the RCX or variable (analogue)
sensors like a playstation controller?

Steve
Permalink | Reply | 1 comment |
headers
David Schilling | 21 May 2006 07:58

Re: Ultrasonic sensor interactions

In lugnet.robotics, steve <sjbaker1 <at> airmail.net> wrote:
> John Barnes wrote:
>
>> Pulses emitted by "the other sensor" can arrive at just the wrong moment,
>> creating a false range reading. Clever numerical filtering can eliminate this
>> kind of thing under certain circumstances - for example you may be following
>> parallel to a wall and obtaining a series of readings which should be all within
>> a likely range. If you suddenly receive a reading which is outside the expected
>> range, you might discard it. In otherwords, if you maintain an average and only
>> accept readings within a certain range of that average as bona fide, then you
>> may be able to guard against this kind of interference to a certain extent.
>
> A better alternative would be to develop protocols in which the NXT
> controllers use their communications to tell each other what they are
> about to do.  If you can sent a message that says "I'm about to do an
> ultrasound 'ping' - so you'd better ignore any readings you are about
> to get and refrain from doing a 'ping' of your own."  then do a range
> measurement and finally send another message "Thanks - I'm done with
> the ultrasound system for a while."...then the systems can arrange to
> avoid interfering with each other.
>
> After all, robots move slowly - you are unlikely to need high speed
> readings.
>
> I guess it all assumes that you have software control of the ultrasound
> sensor so that you can control when it sends a ping and make it shut
> down between pings.
>
> For competitive NXT events, it might be worthwhile for this group to
> come up with a standard protocol that contest organisers could
(Continue reading)

Permalink | Reply | 18 comments |
headers
Arthur Clarke | 21 May 2006 11:31

Re: Ultrasonic sensor interactions

The problem here is the management of a single shared resource, i.e. the air
through which the ultrasonic signals travel. The lack of a Bluetooth broadcast
mechanism makes the implementation of a conventional resource locking system
difficult, but not impossible.

A similar situation exists in Ethernet communication where a set of
communication channels must be implemented over a single physical cable, optical
fibre etc. This is achieved without using a separate communication mechanism to
achieve locking.

When an Ethernet interface wishes to transmit a packet, it first listens to see
if the “Ether” is in use. If it is, it continues to listen until the “Ether” is
quiet. If the “Ether” is not in use it transmits the packet but listens to see
if the packet is corrupted by a “collision” with a another packet from a
different interface that has started to transmit at the same time. If there is a
collision, it waits for a randomly selected interval and then repeats the whole
procedure until the packet is transmitted successfully. All packets are
transmitted in full weather or not a collision occurs to ensure that all senders
detect collisions.  In this environment “collisions” are a normal part of
network operation. This is called “carrier sense multiple access with collision
detection” (CSMA/CD).

I wonder is the characteristics of the ultrasonic sensor might permit something
similar. It must be able to listen to see if the “Ether” (the air) is quiet, but
could it detect “collisions”? If this is possible, the next problem concerns the
relatively low bandwidth of the ultrasonic channel compared to even the slowest
Ethernet. It might be that, in order to avoid deadlock, the collision back-off
times would need to be quite long, e.g. several seconds.  If this is the case,
the rate at which an individual robot could sample its ultrasonic sensor data
might be too low to be useful for navigation purposes. [I suspect that this last
(Continue reading)

Permalink | Reply | 16 comments |
headers
Tim Byrne | 21 May 2006 14:09

Re: Ultrasonic sensor interactions

In lugnet.robotics, David Schilling wrote:
> In lugnet.robotics, steve <sjbaker1 <at> airmail.net> wrote:
>> John Barnes wrote:
>>
>>> Pulses emitted by "the other sensor" can arrive at just the wrong moment,
>>> creating a false range reading. Clever numerical filtering can eliminate this
>>> kind of thing under certain circumstances - for example you may be following
>>> parallel to a wall and obtaining a series of readings which should be all within
>>> a likely range. If you suddenly receive a reading which is outside the expected
>>> range, you might discard it. In otherwords, if you maintain an average and only
>>> accept readings within a certain range of that average as bona fide, then you
>>> may be able to guard against this kind of interference to a certain extent.
>>
>> A better alternative would be to develop protocols in which the NXT
>> controllers use their communications to tell each other what they are
>> about to do.  If you can sent a message that says "I'm about to do an
>> ultrasound 'ping' - so you'd better ignore any readings you are about
>> to get and refrain from doing a 'ping' of your own."  then do a range
>> measurement and finally send another message "Thanks - I'm done with
>> the ultrasound system for a while."...then the systems can arrange to
>> avoid interfering with each other.
>>
>> After all, robots move slowly - you are unlikely to need high speed
>> readings.
>>
>> I guess it all assumes that you have software control of the ultrasound
>> sensor so that you can control when it sends a ping and make it shut
>> down between pings.
>>
>> For competitive NXT events, it might be worthwhile for this group to
(Continue reading)

Permalink | Reply | 0 comments |
headers
steve | 21 May 2006 14:30

Re: Ultrasonic sensor interactions

Arthur Clarke wrote:
> When an Ethernet interface wishes to transmit a packet, it first listens to see
> if the “Ether” is in use. If it is, it continues to listen until the “Ether” is
> quiet. If the “Ether” is not in use it transmits the packet but listens to see
> if the packet is corrupted by a “collision” with a another packet from a
> different interface that has started to transmit at the same time. If there is a
> collision, it waits for a randomly selected interval and then repeats the whole
> procedure until the packet is transmitted successfully. All packets are
> transmitted in full weather or not a collision occurs to ensure that all senders
> detect collisions.  In this environment “collisions” are a normal part of
> network operation. This is called “carrier sense multiple access with collision
> detection” (CSMA/CD).

The 'Aloha' protocol was the predecessor of this.

> I wonder is the characteristics of the ultrasonic sensor might permit something
> similar. It must be able to listen to see if the “Ether” (the air) is quiet, but
> could it detect “collisions”?

Someone earlier told us that the thing runs all the time and can't even
be shut off.

That being the case, I think we're pretty much doomed.

> If this is possible, the next problem concerns the
> relatively low bandwidth of the ultrasonic channel compared to even the slowest
> Ethernet.

Yes - but the relatively low frequency at which you need data from it
compensates for that.
(Continue reading)

Permalink | Reply | 15 comments |
headers
John Barnes | 21 May 2006 16:13

Re: Ultrasonic sensor interactions

In lugnet.robotics, steve <sjbaker1 <at> airmail.net> wrote:
> Ultrasound travels at about 350 meters per second.  If it's
> detectable range is (say) 3.5 meters then we only need (theoretically)
> 1/50th of a second to emit a ping and get the echo back at
> maximum range.  The actual duration of the ultrasound ping should
> be very short - the sound frequency should be up in the 100kHz to
> MHz range so a very brief pulse is enough.

The device operates at 40kHz, the transmit and receive piezo devices are only
resonant at that frequency.

Even though the measurement period is short (time from transmit to time to
receive) it is necessary to wait quite a while for the sound pulse to finish
bouncing around the environment before starting a new measurement cycle. 

The actual quality of the received signal is such that it is difficult to do
more than measure the time to the earliest received pulse. After the arrival of
this pulse, which has taken the most direct route to the nearest surface within
its "beam" width, further echos will continue to arrive for quite a while, often
with intensities higher than the first pulse because they are coming back from
more highly ultrasound reflective surfaces.

It would thus be hard to emit an "id" string of pulses and do any kind of pulse
compression (by correlation techniques as radar does) to avoid interference or
even to detect it.

JB
Permalink | Reply | 1 comment |

Gmane