USB-based network?

Status
Not open for further replies.
D

doug

Member
I'd like to use one Teensy to control 10 others. Each of the others is driving a servo and a couple of other components, and they're in the order of 15-20 cm apart (they're in individual boxes). The "master" only needs to write commands. The slaves only need to read. It's ok if it works as broadcast (i.e. all slaves receive all the commands).

I considered i2c but I think I need individual power (because I'll want to power all the teensys, and drive all 10 servos at the same time). To save me having to run one set of power and a set of data leads between the boxes, I considered using USB and a hub.

Could I use a powered USB-hub? Would this allow me to write using USB-serial from one device and have the others able to read it? Would I need the USB-host shield for the master, or for all of them?

Cheers,
Doug
 
USB would be challenging. Serial is less challenging and well-understood.

Hi Doug, I have a similar need for one-to-many networking, and have decided on a serial protocol, with connectivity provided by the Teensys with only enough signal and impedance control to make my test network reliable. The total length of my test bus is less than 1 meter, with stub lengths less than 3 cm. (bus length and stub length are basically the dominant factors in whether such a plan can work...)

If the entire "network" has a good (common, low impedance) ground reference, limited number of participating devices and strictly limited physical lengths, then it's possible to use a wired serial "network". It is important to manage signal edge rates, so the use of series drive resistors or possibly the K20's built-in drive strength controls (see the K20 manual, chapter 11: Port control and interrupts) is a very good idea. Even for short buses with impedance-controlled drivers, it's a good idea to employ matching terminating impedances at the ends of the bus to control reflections.

Another alternative would be SPI or something similar, which provides potentially higher bandwidth (with the attendant requirement of being significantly more careful with bus design hardware) and lower latency.

Your consideration of I2C as a protocol may imply that bandwidth is not super-critical in your application, which is why I thought of serial connectivity.

USB has significant protocol overhead (generally software complexity), so proposing to make a Teensy the master would introduce some very interesting challenges.

If I can get out from under an increasing amount of day-to-day firefighting at work, I have a goal of seeing just how fast I can make a localized multipoint teensy-to-teensy network go. The stuff I'm working with is RS-485 right now, but if I can make a local network run reliably without the RS-485 drivers etc., then I can reduce its hardware complexity. Let's see how the firefighting goes...
 
I agree, serial is by far the simplest and easiest way to do this. If the boards have a good common ground and the wires aren't "too long", you can probably just connect the TX1 output from 1 board to the RX1 input on all the others. For moderate serial lengths, simple buffer chips might work well. For really long wires, RS-485 signals are excellent.

The Arduino Serial1.write() and Serial1.available() & Serial1.read() are simple and easy to use. You'll need some sort of protocol, like using ascii-only data and a specific character to indicate message start and which board receives the message, or perhaps a binary protocol where certain numbers or patterns of numbers frame the messages and can't occur within the data.

With USB, you'd need to have the USB Host Shield on the master board, which adds quite a lot of complexity.

Powering many servo motors will be challenge. Those RC servos can use pretty large currents when mechanically loaded and delivering substantial torque. The main thing you want to avoid is large ground currents flowing though the ground wires that establish all the Teensy grounds to be the same. Usually the simplest approach is to run dedicated power and ground wires to the actual servo motors, and have Teensy's ground meet the power ground at or near the motor. It's pretty much the same issue as connecting thousands of LEDs.

http://www.pjrc.com/store/octo28_adaptor.html

http://www.pjrc.com/teensy/td_libs_OctoWS2811.html
 
Paul and Len - thanks for your replies.

Based on some long thinking, I think I'm going to try to simplify and just use a single teensy controlling multiple servos, using something like the adafruit 16-channel servo driver.

To let the cat out of the bag, I want to make flappy character displays, like at airports. I was considering making each of them a completely standalone unit, with a teensy inside, and some way of telling it to rotate to position n. But for my purposes I only need 10 characters, I should be able to drive the servos using the above board, and use a mux to read either optical switches or rotary encoders for the position.

Thanks anyway, and I'll remember just using serial.
 
Thanks Paul - unfortunately I need to control 10 servos (the pulseposition library runs 8).

I'm currently concentrating on the mechanics of the project - can I laser cut the parts, will it actually work - before I get around to deciding whether to put a teensy into each character or try and run them all from a single board.

One thing that is making me lean towards putting smarts in each character is that I can then make them a bit more autonomous - they can be told to rotate to position X, and they manage it all. Otherwise I need to haul sensor inputs back, and monitor them, and I'm just not sure how successful I will be at monitoring the sensors at the speed the flaps will be rotating.

If I do put smarts into each digit, then I2C is quite appealing from an interoperation point of view. However, I've never done anything with I2C so stop me if this is stupid.

I could use a teensy - this gives me the I2C (or serial) interface, counters and servo control. Which is nice.

Alternatively, I could build it, with an I2C 8-bit I/O expander, an 8-bit counter that counts the wheel position (with a couple of sensors), and a comparator to tell when the counter is the same as the output from the I2C chip. When they're not, the comparator output enables the servo, wheel turns, counter counts. Send a command to the I2C telling it "27", and the comparator enables the servo until the wheel is in position 27, comparator goes low, servo stops. Yes?

Or tell me to just move on from I2C. :)
 
doug said:
Thanks Paul - unfortunately I need to control 10 servos (the pulseposition library runs 8).
Click to expand...

PulsePosition creates 8 PPM outputs, each capable of controlling 16 servo motors, using 74HCT164 chips.

The Servo library is capable of controlling 12 servos, each connected directly to a pin.
 
Status
Not open for further replies.
Back
Top