Network Switch
 

I was looking through the QA and rules and I can't find many rules regarding the use of network switches. Does anyone know about whether is has been permissible in the past to use switches? I feel like this must have been brought up before, but if it hasn't, I will QA it.

The only relevant rule I have found is As long as the roboRIO is attached directly to the bridge, is it ok to use a netgear (or any other brand) network switch provided it complies with all other rules regarding power?

Re: Network Switch
 

In prior years, the Wifi Adapter had one port, and the cRio has 2 ports. The cRio connected directly to the Wifi Adapter, and you connected other stuff through the other cRio port. If you needed to connect more than one other thing, you had to connect the cRio to a hub or switch.

As long as your Network Switch is a non-broadcasting switch (does not have wifi), you should be fine. I don't see why the Network Switch is not considered a COTS Computing Device.

Re: Network Switch
 

I'm curious why you need this with the bridge already acting as a switch for the ports on it. Can you tell us what you are trying to do?

Re: Network Switch
 

Sam,
I have to ask what you are trying to accomplish. The DAP has four ports only one of which will be in use on the robot. I believe that a second switch can be used provided that there is no "collisions" with data on the robot and that the RoboRio be connected to the DAP and not routed through another switch. Please be sure that the list in R49 is satisfied. A question to the Q&A will get you a response from FIRST Engineering as to their thoughts on the subject and that is my recommendation.

Re: Network Switch
 

I can't think of any rules that would prohibit connecting an Ethernet switch to one of the D-Link's ports.

I'm curious why you would need extra connections, though. Do you have multiple cameras or off-board processors?

Re: Network Switch
 

The reason why this has come up is this year our robot has 5 co-processors. We considered using the SPI or I2C bus; however, ultimately we decided on using IP based communication. We only have 4 ports on the access point and we need 5 ports for processors, 1 for programming, 1 for roboRIO, 1 for camera, and potentially 1 for a driver station at comps. This adds up pretty quickly and we are looking at 9 ports.

An alternative is to switch to a different communication method; however, UDP is working pretty well and we have the most experience with it.

I will ask whether it is legal to use a switch in the QA. If they conclude that it isn't, does anyone have any experience with SPI or I2C and/or have any suggestions on what to use (or another communication protocol/bus I am missing).

Re: Network Switch
 

:eek:

You didn't mention straight serial UART, or CAN.

Re: Network Switch
 

UART is something to consider.

I was hesitant about using CAN because 2 of the processors are on moving components and I don't want to kill our entire bus because of a wire snag. Is this a legitimate concern or am I imposing a flaw on CAN that doesn't really exist?

Re: Network Switch
 

It's generally never a good idea to place your electronics on moving parts--do you mind going into a little more detail about that?

In any case, you're correct about the CAN bus: since everything is daisy-chained, a disconnect mid-way through the match is something you definitely don't want. I'm not sure if you would lose control just over all components past the disconnect, or if you would lose control of everything because you will have lost your endpoint. Either way, it's not worth the risk.

Re: Network Switch
 

Find a layer 2->7 managed switch and traffic shape on the robot :yikes:

At the baseband non-packetized:
Differential RS422/485 would allow a bus where a device on the bus could disconnect or 'vampire tap' without killing the whole bus.
http://en.wikipedia.org/wiki/Vampire_tap
http://en.wikipedia.org/wiki/RS-422
http://en.wikipedia.org/wiki/EIA-485

However if you intend to run star configuration instead of a bus you may as well just use Ethernet and a switch.
The effort involved is really pretty similar and the conversion of the signals to differential built into most of the Ethernet devices.

Generally I think working around the broken wire issue is not entirely possible because sooner or later the FIRST control system has a few single points of failure.

Re: Network Switch
 

As a general rule, I definitely agree and we avoid it when we can.

Their are a few reasons why we chose to put processors on moving parts. The moving ones are on our elevator carriages. We are using them to get the absolute position of the elevator. The frame of our elevator has an overlay on it that has a gray code binary system encoded on it. We are then using reflective photo interrupters to read the encoded binary. We are encoding 10 bit numbers meaning we need 10 photo interrupters, each with 4 wires (2 for LED, 2 for photo diode). Rather than running 40 wires to our belly pan and doing the decoding there, we are using an arduino to convert the data into a decimal number on the carriage then sending that to our main controller.

We decided it was better to put the processor on the carriage and have a communication cable running through our cable carrier than to run 40 cables and put the processor on the belly pan.

Re: Network Switch
 

I would use whatever you are familiar with. If devices talk to each other (vs. the roboRio), a switch would give them an independent pathway.

I don't think it would kill the entire bus. It would just isolate that portion of the network.

CAN Bus tends to be Daisy Chained, rather than connected to a common bus. So anything after that failure point would be isolated from anything before that failure point. As a multi-master serial bus, you don't have to worry about being disconnected from the Bus Master.

Re: Network Switch
 

Yes; however, my fear is that there would no longer be a terminator on the bus which to my understanding would bring the whole thing down. That being said, I don't have a thorough understanding of the inner-workings of the CAN bus and would love to be told I'm wrong.

Re: Network Switch
 

Wow, that certainly sounds like a complex feedback setup!. Have you considered other options that may be simpler? For example, if your elevator is powered on a winch, you could hook up a potentiometer to the winch and use it to measure the location of the elevator. We did something similar a few years back with a winch and a 10-turn pot, and it worked perfectly the entire season.

Re: Network Switch
 

It definitely is very complicated. We didn't want to gear down a shaft on our winch to only rotate 10 turns over 6'. We ran the numbers and we were aiming for more precision than we would be getting with a pot. We also have a large electronics and software team this year so we have an entire subteam working on this one sensor. They have made lots of progress and it actually is working really nicely.

There are a number of benefits most notably precision (1/8" over the whole travel). After this year we may package up the sensor so it's easy to reuse.

Re: Network Switch
 

Make sure you follow the rules for reusing manufactured stuff. For code, it is easy: Post it. For actual hardware, it may need to be available to everyone.

You could post the design, and then quickly make them at the beginning of each build season. That would save redesign time.

Re: Network Switch
 

You could always measure position with an encoder instead. Just start the elevator at the bottom at the beginning of the match, and then count rotations as it goes up and down. Have a recalibrate feature if anything goes wrong so you manually drop the elevator to the bottom and re-zero.

Re: Network Switch
 

Last year we did this and we ran into a number of issues with our encoders not being calibrated during autonomous. Based on our autonomous strategy this year, we decided that having to slowly lower the elevator until a limit switch was pressed wasn't super feasible.

Re: Network Switch
 

Sam,
Please ask on the Q&A before you spend a lot of time developing. CAN buss is a relatively stable easy to use system if you are careful with the wiring. This is something you are going to do even if you stick with the LAN solution. I have one personal rule that you should consider. I never put solid wire on a moving device if I can help it. Solid wire tends to break when you need it the most due to vibration. For the LAN wiring on the robot we tie everything down so there is a minimum of movement and add some service loop so nothing is stressed. I have seen teams lose elim matches due to failed LAN wiring.
I would also ask, if you couldn't add the sensors to the non-moving side of the lift so that you don't have to worry about buss wiring that will fail.

Re: Network Switch
 

Could you clarify what you mean here?

Re: Network Switch
 

From your description it sounds as if you plan to mount the sensors on the moving part of your mechanism. Could you add those to a non-moving section and have the bar codes mounted on the moving parts?

Re: Network Switch
 

I see what you are saying. At first glance it doesn't seem possible but I will delve into it a bit and think it through more.

Re: Network Switch
 

One thing I like about this year's control system is that it forces teams to tether to the router. Cheaper to replace when someone trips over the tether wire.

Note that Ethernet patch cables are commonly made with stranded wire, which addresses some of Al's concerns. If I was building out a LAN on the robot, consider using fresh-out-of-the-bag stranded patch cables for wiring, rather than solid wire intended for fixed installations. They are very inexpensive.