Subject:
|
Re: Brute Force Brick
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 12 Mar 2004 02:04:15 GMT
|
Viewed:
|
943 times
|
| |
|
|
In lugnet.robotics, Ralph Toepper wrote:
>
> It would be more nice to have ports, that you can define from the software.
> Simply assigning the function of a port, either sensor input or motor
> output makes it a most flexible system. Regardless of the optimal number of
> ports of an Expansion Unit.
I consider myself pretty well atuned to "what would be nice". In the process of
actually designing and building prototypes which bear a resemblance to what
might actually be reproducible as a product, there are certain limitations which
apply. The "generalized" I/O port is a goal. But so far, I have not found an
economical I/O circuit structure which can have the finesse of input, requiring
leakage currents of less than 1uA which can also act as outputs capable of
delivering over a couple of amps.
My personal opinion, which appears to disagree with our illustrious forfathers
at MIT would indicate that about a 2:1 ratio is typically required for sensor
ports in proportion to motor ports. (MIT reseachers seem to think that 1:1 is
good - ref: their cricket spec.) Think of a simple example - a motorized device
with a limit switch at each end of its travel.
BFB has 2:1.
>
> Ever attached an oszilloscope to an RCX input? Then you know the 3 ms cycle
> consisting of two phases: sensor read phase (approximatly 0.1 ms) and power
> out phase (approximatly 2.9 ms).
>
> Although it is imagined in the literture as bound to the port mode, this
> 3 ms cycle is independent of it. Meaning, it is allways there, after you
> switch on the power of the RCX.
>
> I suggest now, that the three inputs of the RCX are scanned in a 1 ms cycle.
> Meaning every one millisecond another input is scanned. The Expansion Units
> must go coincident with this.
Actaully, the RCX turns off all sensors at the same time and then zips around
and does all three channels inputs during this off time.
BFB cannot do this as it has ten sensor inputs, So it does exactly as you
describe and sequences the procedure.
BFB is intended as having enough horse power to perform the CPU functions
required in any modest application. The expansion port capability via the
powered serial interface is supposed to be a mechanism via which intelligent
sensors might be connected, such as a "camera and tracking software" in a box.
(Built - done that - been there :)
A standard serial port (ttl version) has been implemented because it is a cheap
to conform to standard - most modern microcontrollers include a UART. Bluetooth,
USB and other PC communication technologies are wholly inappropriate to this
application as their respective "consortia" require mega-bucks to join the club
and require software overheads which are at least 100x if not 1000x greater
those necessary to support a serial connection. I am very happy to let someone
else build a Lego compatible CPU brick around these "new" communications
standards.
As far as the UHF link goes, it works. Its 10x faster than IR and works around
corners :)
I suspect if you've become used to the current memory bloat in modern PCs
running windows, then the idea that resources like memory capacity and data
transfer rates might be limited would come as a bit of a shock. If you've
arrived in the robotics arena via embedded computing, or PCs of even a few years
ago, then you may have an appreciation of limiations, as they may apply.
I understand that that comment may apply to my apparent need to push beyond the
limitations of the existing RCX. I couldn't agree more. I really enjoy working
within its limits especially in competitions where it (the RCX) impose a level
playing field. And its 3+3 architecture is well suited to things like Sumo and
pipe crawlers of all kinds.
There's nothing stopping anyone putting a laptop PC on wheels if they want to.
Actually it's been done a few times. My goal, however, is to evolve a design
which provides 90% of what people might want as the next step up from the RCX
while trying to keep a highly open ended wish list (as expressed on lugnet over
the past couple of years) within bounds of reason and to keep the purchase cost
within budget.
best
JB
|
|
Message is in Reply To:
 | | Re: Brute Force Brick
|
| (...) A very well solution. I even think, it would be possible to interconnect multiple BFBs in a communication line like that, the cable would reduce UHF bandwith restrinctions. Such, that a cable connection loads some of the communication load (...) (20 years ago, 11-Mar-04, to lugnet.robotics)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
