| |
Having had a good look inside my RCX, I'm thinking seriously about what is
really possible in the same space envelope, whether extra ports or functions
could be added for RCX3.
I think it's useful for us to know what's inside the RCX, especially if we want
to have any input into what's inside the next evolution of it, which is one
reason why I've been looking into the circuits. Perhaps our ideas are more
likely to be taken seriously if we understand the constraints of the space
envelope and available electrical and processing power.
Much of the circuit board is quite densely packed with components on both sides,
and the board already has 3 track layers, so the only way to fit more ports in
(with the necessary components) would be to hybridise parts of the circuit.
(Hybridisation is where all the components without their cases (just the silicon
bits) are put together inside one package, miniaturising the circuit. The
resulting hybrid might be a package looking a bit like the processor).
I don't think the motor port circuit could be miniaturised, as the motor
controllers are already 90% of the motor port circuit and the diodes need to be
rated for more power, so they should stay as discrete components.
The power supply circuit, likewise, needs to be rated for power. The capacitors
are some of the largest components. Does anyone know if some of them (6x300uF)
been removed in the RCX2? Certainly we want the original mains input port to be
put back for RCX3, though this would require the same space as the RCX1 power
circuit.
The sensor ports could be hybridised. Each sensor port requires 3 transistors,
5 resistors and 1 diode, plus the protection diodes and capacitor, which would
have to stay as discrete components for power reasons. If the pull-up
components were included then all three (or more) sensor port circuits could fit
into one hybrid. However, the sensor port circuits surround the port connection
clips, so the hybrid would have to go elsewhere on the board.
The processor, ROM and Octal flip-flops (74HC377) could be made into a hybrid.
This would not save much space, but it might be enough for a sensor port hybrid
to fit on that side of the board. The processor has eight ADC ports, of which
three are used for sensors. Others may be used for power supply or motor
monitoring, but there may be another one free for a fourth sensor port.
The display is a finite size and already has its controller chip and the sound
device underneath it, so no space could be saved there.
The IR LEDs and receiver device need to be where they are, behind a window at
one end of the unit.
Summarising, there is the possibility that sensor ports or the main computer
parts of the circuit could be shrunk into one IC, as long as the components are
available in die form. Therefore some space could be saved on the circuit
board.
Given that there is a custom IC inside the RC Tower, the miniaturisation of
circuits onto ICs is not impossible. The question is more one of the cost
feasibility for a production run of maybe 300,000 units.
I think enough circuit board space could be saved for a Bluetooth IC to be
placed in the space. This would give the RCX the freedom to wander out of sight
and still communicate, which would greatly expand its roving possibilities,
including a colony of RCX robots interacting. I'd like to see a port for the
camera to be plugged in, so that this too could take advantage of the Bluetooth
capability, making a remote spy robot!
The port connection clips are within 8mm of the edge of the board, so four ports
of each type across the case width is not possible with the current scheme. The
control center uses leads cut in half with wires to the circuit board, but the
trend is away from this and towards the clips. I don't honestly think that any
more ports could be implemented in the same box, unless an alternative connector
scheme were used.
Those of us with greater robotic ambitions, requiring more ports, probably have
the skills to interface two or more RCXs into one robot.
In conclusion, I think TLC did a really great job of fitting as much as they
could into the box. With the addition of Bluetooth and the restoration of the
mains port, the RCX3 would have as much extra hardware functionality as
possible, given the advance in technology since the RCX1 was produced.
Perhaps, given the anticipated release date and the long programme to produce
the next RCX, our time to suggest new functions has now passed, but at least we
can understand the limits if not everything we want is implemented.
PLMKWYT
Mark
|
|
| |
I've seen this topic come up several times, and am
curious why no one suggests that the input and output
ports be extended from the RCX to pods. Using the same
form factor constraints limits the possibilities.
Using a more condensed cable connection between the
RCX and the pods allows for more connectors, and the
pods would use the standard 2x2 arrangement.
Additionally, if the output pod also contained the
motor controls (imagine something 1/3 the size of the
RCX) it could not only have the low density 2x2
connectors, it could make additional room in the RCX
for more circuitry. There could be several output pod
options, allowing for the standard 3 ports, all the
way up to 12 ports using multiple pods.
Adding the external power connector is an option that
seems unanimously agreed on, and moving the batteries
to an external pod that uses that connector would also
open up space for more processing power. (read
additional RAM, program storage space etc.) Being able
to locate the batteries in a space more suited to
balance of the creation is a huge advantage.
The h-bridge functions being in the output pod would
allow for many upgrade option kits ( I'm hoping this
sort of thinking makes this option or one like it seem
like something that would improve the bottom line to
the LEGO folks) I can see some of the LEGO inventions
I've seen greatly benefiting from the ability to
extend the output ports (via the pod) to a place more
local to where the motors are being used.
These style of changes would make room for upgrades to
the motor control options, input options, and power
options while remaining steady with plug-n-play
utility and backward compatability.
I can imagine 6 motor outputs on one pod, and possibly
2 pods per RCX3. Imagine an input pre-processor pod
that has odometry functions built-in, and a processor
to linearize the readings from certain sensors so that
the user sees improved intelligibility on sensor
readings and/or increased range?
This type of 'change' makes sense to me. To improve
the capabilities of the current RCX by removing the
physical limitations that the current form factor puts
on the processor inside. This is what transformed the
original home computers like the Atari and C64 into
the huge processing machines that we have in tower
style pc's... we moved the input and outputs away from
the processor to give it more room.
I can even see a flash card slot on the RCX in the
future, and other such enhancements that make it not
only competative with systems like the basic stamp,
but more capable, and still equipped with the most
amazing building system I've ever had the pleasure to
play with :)
I'd personally like to see a LEGO servo motor option
along with suitable LEGO servo motors, and perhaps
built-in DCC functionality in the output pod so we
could connect many motors to one output if they are
not all to be used at once.
Well, that is what I would put down good money for.
Cheers
--- Mark Bellis <mark.bellis@tiscali.co.uk> wrote:
> Having had a good look inside my RCX, I'm thinking
> seriously about what is
> really possible in the same space envelope, whether
> extra ports or functions
> could be added for RCX3.
>
> I think it's useful for us to know what's inside the
> RCX, especially if we want
> to have any input into what's inside the next
> evolution of it, which is one
> reason why I've been looking into the circuits.
> Perhaps our ideas are more
> likely to be taken seriously if we understand the
> constraints of the space
> envelope and available electrical and processing
> power.
>
> Much of the circuit board is quite densely packed
> with components on both sides,
> and the board already has 3 track layers, so the
> only way to fit more ports in
> (with the necessary components) would be to
> hybridise parts of the circuit.
> (Hybridisation is where all the components without
> their cases (just the silicon
> bits) are put together inside one package,
> miniaturising the circuit. The
> resulting hybrid might be a package looking a bit
> like the processor).
>
> I don't think the motor port circuit could be
> miniaturised, as the motor
> controllers are already 90% of the motor port
> circuit and the diodes need to be
> rated for more power, so they should stay as
> discrete components.
>
> The power supply circuit, likewise, needs to be
> rated for power. The capacitors
> are some of the largest components. Does anyone
> know if some of them (6x300uF)
> been removed in the RCX2? Certainly we want the
> original mains input port to be
> put back for RCX3, though this would require the
> same space as the RCX1 power
> circuit.
>
> The sensor ports could be hybridised. Each sensor
> port requires 3 transistors,
> 5 resistors and 1 diode, plus the protection diodes
> and capacitor, which would
> have to stay as discrete components for power
> reasons. If the pull-up
> components were included then all three (or more)
> sensor port circuits could fit
> into one hybrid. However, the sensor port circuits
> surround the port connection
> clips, so the hybrid would have to go elsewhere on
> the board.
>
> The processor, ROM and Octal flip-flops (74HC377)
> could be made into a hybrid.
> This would not save much space, but it might be
> enough for a sensor port hybrid
> to fit on that side of the board. The processor has
> eight ADC ports, of which
> three are used for sensors. Others may be used for
> power supply or motor
> monitoring, but there may be another one free for a
> fourth sensor port.
>
> The display is a finite size and already has its
> controller chip and the sound
> device underneath it, so no space could be saved
> there.
>
> The IR LEDs and receiver device need to be where
> they are, behind a window at
> one end of the unit.
>
> Summarising, there is the possibility that sensor
> ports or the main computer
> parts of the circuit could be shrunk into one IC, as
> long as the components are
> available in die form. Therefore some space could
> be saved on the circuit
> board.
>
> Given that there is a custom IC inside the RC Tower,
> the miniaturisation of
> circuits onto ICs is not impossible. The question
> is more one of the cost
> feasibility for a production run of maybe 300,000
> units.
>
> I think enough circuit board space could be saved
> for a Bluetooth IC to be
> placed in the space. This would give the RCX the
> freedom to wander out of sight
> and still communicate, which would greatly expand
> its roving possibilities,
> including a colony of RCX robots interacting. I'd
> like to see a port for the
> camera to be plugged in, so that this too could take
> advantage of the Bluetooth
> capability, making a remote spy robot!
>
> The port connection clips are within 8mm of the edge
> of the board, so four ports
> of each type across the case width is not possible
> with the current scheme. The
> control center uses leads cut in half with wires to
> the circuit board, but the
> trend is away from this and towards the clips. I
> don't honestly think that any
> more ports could be implemented in the same box,
> unless an alternative connector
> scheme were used.
>
> Those of us with greater robotic ambitions,
> requiring more ports, probably have
> the skills to interface two or more RCXs into one
> robot.
>
> In conclusion, I think TLC did a really great job of
> fitting as much as they
> could into the box. With the addition of Bluetooth
> and the restoration of the
> mains port, the RCX3 would have as much extra
> hardware functionality as
> possible, given the advance in technology since the
> RCX1 was produced.
>
> Perhaps, given the anticipated release date and the
> long programme to produce
> the next RCX, our time to suggest new functions has
> now passed, but at least we
> can understand the limits if not everything we want
> is implemented.
>
> PLMKWYT
>
> Mark
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
|
|
| |
In lugnet.robotics, Mr S <szinn_the1@yahoo.com> wrote:
> This type of 'change' makes sense to me. To improve
> the capabilities of the current RCX by removing the
> physical limitations that the current form factor puts
> on the processor inside. This is what transformed the
> original home computers like the Atari and C64 into
> the huge processing machines that we have in tower
> style pc's... we moved the input and outputs away from
> the processor to give it more room.
Having built a number of prototype "clone" bricks, I feel reasonably certain
that the RCX's internal space is not the limiting factor. The surface area
occupied by 2x2 I/O connectors is the true limit. (Assuming you dedicate a board
to hosting the physical connections and a second board to hosting the bulk of
the electronics. There's gobs of space for a board with TSSOP parts on both
sides of the board. I've yet to need the second surface of the "CPU" board for
parts in any of my forays into this realm.
If you count out the number of 2x2s that could fit on one surface of the RCX,
you'll see you can get quite a few motor and sensor ports.
(Assuming you put the display and buttons in their own "pod", or on the end,
side or under surface of the brick.)
I suspect the RCX limitations come more from economic considerations than from
physical limitations, based on the target market. Will a child truely expand
beyond what the current 3+3 channels that the RCX offers? I have yet to meet
one.
As an adult user of TLC's basic idea, I simply take it upon myself to expand as
needed. More motors ... more sensors. Yep, just make more interfaces.
As and when TLC comes out with their next generation, I personally would guess
that they may offer a few more sensor types. They may also offer a modest
increase in sensor and motor connectivity, although it has to be backward
compatible. I'd be surprised to see more than that. The one thing thay'd be
really foolhardy in doing would be to invalidate all those FLL group's
investment in the current system.
JB
|
|
| |
hi
so IMHO don't expect more outputs
because of the power
3 motors + 3 sensors + mainboard have to be powered by bateries
some time ago i proposed to make connectors smaller
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=631766
first good think is the size of these connectors of course
second is that they can be passed through the holes
pixel
|
|
| |
In lugnet.robotics.rcx, Paul Kleniewski wrote:
> hi
> so IMHO don't expect more outputs
> because of the power
> 3 motors + 3 sensors + mainboard have to be powered by bateries
I have a proposal that would theoretically allow an RCX to use 49 motors and 147
active sensors (or 588 switches!). This has the potential to control an entire
Ball Contraption or railway! The idea may be expandable to four times those
figures, depending how the signals are interpreted!
I'm thinking of multiplexing them via the speed setting from one or two motor
ports. This requires a clock to be generated that is eight times the PWM cycle
frequency but synchronised to the rising edge of the PWM. This is achievable,
subject to a few experiments. A counter would then count the number of periods
of the eight for which the output is high and convert it to a number for the
multiplexer. I decided to reserve the maximum speed setting of the control
ports for an emergency stop of all motors, driving the reset lines of the
counter latches.
If, as someone has commented, the motor ports' PWM outputs are not always
synchronised, I would put a clock generator on both control ports and
synchronise the latches that would hold the counter states for the decoders to
send to the multiplexer.
This expansion interface would require is own batteries, but with a power supply
it would be able to drive RC car motors or train motors, not just technic
gearmotors.
The 558 switches would be using my series resistor multiplexer, with values of
39k, 47k, 56k and 82k ohms, allowing any combination of the four switches to be
recognised with a reasonable margin to avoid errors.
The RCX program would set motor ports B and C to values corresponding to the
motor or sensors to be addressed, and would then set motor port A and read the 3
sensor ports. The speed settings of ports B and C would either use a cycle to
set and read all motors and sensors, or jump to values to address the ones
required. This is probably an application for alternative firmware, as
addressing 49 combinations and setting ports in a loop would be slow with an
interpreted language, as used by the original firmware.
If back-to-back opto-isolators were used on the motor ports, both directions
could be considered, giving each output 14 control states plus emergency stop,
allowing 196 motors, 588 active sensors or 2352 switches to be addressed!
> some time ago i proposed to make connectors smaller
> http://www.brickshelf.com/cgi-bin/gallery.cgi?i=631766
> first good think is the size of these connectors of course
> second is that they can be passed through the holes
>
> pixel
This is all very well, except that we've had 15 years of these connectors! I
don't expect them to change in the near future. Any connector design must be
large enough and robust enough for kids to handle repeatedly without failure,
and must comfortably handle the current required by an RC car motor (currently
their most powerful application).
I've made 9V to 12V conversion wires by putting 12V plugs onto cut 9V leads.
This way you can make your own leads with 12V plugs, putting the wires through
the holes before the plug goes on. It also means I can use my 12V wires on my
9V railway, reducing the amount of unused parts. Custom circuits can also be
plug and play with 12V plugs, and another advantage is that 1/0.6 bell wire can
be pushed into the ends between the 4 lobes for a temporary connection.
Mark
|
|
| |
In lugnet.robotics, Mr S <szinn_the1@yahoo.com> wrote:
> I've seen this topic come up several times, and am
> curious why no one suggests that the input and output
> ports be extended from the RCX to pods. Using the same
> form factor constraints limits the possibilities.
A friend of mine is actually working on this 'pod' concept. i have been playing
with a working prototype and i must say that it preforms very well. and it is
SO nice to not be limited on the number of sensor inputs.
pictures of the prototype can be found here:
<http://www.brickshelf.com/cgi-bin/gallery.cgi?f=107843>
These pictures are of a sensor mux. it turns 1 sensor port on an rcx in to 6
passive and 4 active sensors. uses a modified BrickOS to talk to the pic on the
mux. there are also pictures of a proof of concept machine and sample code.
But wait there is more! my friend now has a working prototype that will turn 1
rcx sensor port into 6 passive, 4 active, 3 DC motor outputs with 1,024 speed
levels and up to 36V 5A per motor, and 2 R/C servos. For the motors, a separate
supply is obviously required.
so with 3 of these muxes it would be posible to conect 30 sensors, 12 LEGO
motors, and 6 servos to 1 rcx!
if you have any questions please ask my friend at(he is not a lugnet reader):
pat@<AT>nystromengineering<DOT>.com he could also use some encouragement.
bob
|
|
|
