Getting Driver Station Inputs on Dashboard

[KillerGardevoir]

So my team needs to do I/O faster than the latency between the Driver Station, Robot, Dashboard loop allows, I suggested they cut out the round trip to to the robot by simply looking at the port that the robot is getting locally. However, it appears that you cannot initiate any sort of UDP listener on the port that dashboard is talking to the robot on.

Ultimately, the timing operation is so critical that the only way to the controls operate correctly (without a significant redesign to the control's system) is to set up a packet sniffer on the Dashboard to look for the correct data and unpackage it accordingly, and then transmit the final value back over using TCP 1180 (see team update 5 on the control system for legality of this).

My question is such a technique legal with the addition of the rules as you are just listening to yourself and sending over what would be the "camera port". Also, when I set up Wireshark to listen for traffic, the ports specified in the document are different from the ones that are specified by the team update 5 (we tried listening on this port as well, to no avail).

[Greg McKaskle]

What data is it you are wanting to speed up?

The I/O values are sent from the robot just once or twice a second. This was done primarily to keep the CPU load a bit lower. Reading every single analog, digital, solenoid, relay, and servo at 50Hz is a bit expensive. If you rewrite the team code for the dashboard data, you can easily read the I/O faster and only read the I/O actually being used. If it is other robot data, you can send it back as often as you like, and the lag should be way less than 100ms, probably more like 50ms.

Greg McKaskle

[KillerGardevoir]

I think you misunderstood the question, from the Cyprus PSoC we need to count the pulses from a old rotary phone (don't ask). The phone sends pulses at approximately 25hz, and this is faster than the latency etc between the robot and the driver station. The only (obvious) way to the programmers was to go from PSoC to Robot back to driver station for display. This is slow and when our program grew in complexity, it became unreliable. So now we need to know the legality of doing this other way (using a packet sniffer on the driver station to listen to itself)

[Greg McKaskle]

I can't speak as to whether field personnel will allow you to run a packet sniffer. Now that I understand the signal your are trying to decode, I can suggest a couple other ways.

The PSoC enhanced mode has some quad decoding ability. It was provided for encoded knobs or other rotary devices. I'm not sure if you can figure a way to use that to count the pulses. Another approach is to abandon the PSoc connection to the DS, and instead, reprogram it and send the data back to your dashboard. You can decode it using the PC and send the data using the open ports to your robot. Similarly, you can use any other device you like, perhaps even the audio mic of your laptop to capture the signal, process on PC, ...

I hope this helps.
Greg McKaskle

[KillerGardevoir]

I wouldn't see why they wouldn't allow a packet sniffer to be running locally, since it won't be able to see any other traffic than that passing through your computer.
I figured we could use the signal from the rotary phone in terms of rotation, but the phone's dialing mechanism already does this, so we are just reading the digital switch that occurs using one of the PSoC inputs, and since the signal is so slow we were able to have enough time to send the input to the robot and accurately decode the data, we should have the same result on the dashboard, with less of the drudgery of getting the raw PSoC inputs.

Thank you for your input, as far as getting this data from the driverstation, I think there should have been an existing way (e.g. FRC toolkit) to do this from the driver station, as hardware that acts similarly cannot be rare, and custom sensors and such would need use of these inputs.

[Greg McKaskle]

I'm not sure if the UI or DS has ever had that capability, but you are correct, edge counters certainly could be added.

I suspect that in the past, teams would have built a small TTL circuit for counting edges and uploading to the digital lines. Or the would have built a small PIC device that counted and uploaded the digital value.

Have you considered reworking the phone mechanism to turn a pot? Read the pot with the PSoC analog channel? Or mount an encoder and hook that to the Quad encoders on the PSoC.

On the far other end of the spectrum, I'd think that there must be an HID device that would output a radial direction value.

Greg McKaskle