Dashboard protocol documentation

[EHaskins]

I've been working on a custom dashboard viewer, and in the process I've been writing some documentation on the protocol. Eventually I want to have all control system communication documented, but at this point I have the dashboard and camera client documentation somewhat done.

I wanted to wait until I had the documentation finished and a usable dashboard viewer implemented before posting this. However some people may find this useful in it's current state so I wanted to make sure anyone looking can find it.

You'll find both the documentation and the current viewer release on my CodePlex page (http://frc1103dashboard.codeplex.com/).

I welcome any suggestions or feedback, and if you have any luck using this please let me know.

[dpeterson3]

Two questions you may or may not know the answer to.

1. I have written most of the code in Java for a Virtual Driver Station. I am having trouble with the checksums at the end of the FRCComm file. Are they just Xor's or are they some other alograthim? (I have never done checksum calculation before)

2. We give out little disks at the competition. We were thinking of building a shooter this year for off-season use at games and school events. I want to join the CRIO to the school network and then use the camera to drive around. I have been searching for P2P examples so I could write an application for the CRIO. I haven't found much on the low-level workings of P2P networking, but from the sound of your app, the CRIO already uses P2P to communicate. Is this the case? If it is, my life will be so much easier.

thnaks

[EHaskins]

1. The check sum is a CRC32 with 4 empty padding bytes preceding 4 bytes of check sum. I'm not familiar with CRC calculations so you'll have to do your own research on how to implement that.

2. If your network is NOT in using the 10.x.x.x address block it may work out of the box. You can determine this by finding the IP address of any of the computers on the network. The IP will either start with 10. or 172. if its 10.x.x.x it probably won't work.

Next you can try connecting the DS to the network, and then connecting a PC configured with the IP 10.x.y.6 to the network and trying to ping the DS(10.x.y.5) if you can ping the DS try moving the PC or DS to several locations in the building and testing it. If all of your tests succeed you can try connecting the robot to the network, and watching to determine if it can connect to the DS.

Keep in mind that even if this does "work" the school's IT department probably won't like it, and you could potentially cause issues with other parts of the network. In short, talk to your IT people, and hope they're willing to work with you.

[dpeterson3]

Thanks. CRC is just a 1's compliment. Java has a class to do the calculation for me! Unfortunately, the network has a 10.xx.yy.zz configuration. However, I am sure there is a way to set the CRIO's address to something else (invoking VxWorks directly from WindRiver) and use the VDS if it works instead of the physical one.

[writchie]

Thanks. CRC is just a 1's compliment. Java has a class to do the calculation for me! Unfortunately, the network has a 10.xx.yy.zz configuration. However, I am sure there is a way to set the CRIO's address to something else (invoking VxWorks directly from WindRiver) and use the VDS if it works instead of the physical one.

A CRC is not a ones complement. A CRC accumulation has feedback from multiple bit positions. That's why it's called a "Cyclic" redundancy check.:)

To calculate a CRC you need to know the polynominal used. Often but not always it's the 802.3 polynomial x**32 + x**26 + x**23 + x**22 + x**16 + x**12 + x**11 + x**10 + x**8 + x**7 + x**5 + x**4 + x**2 + x + 1 or 0x82608EDB.

You can calculate a CRC an octet at a time using precomputed values and a table lookup or by code that performs the bitshifts. Once upon a time table lookup was always faster. Today, with processor caches, the bitshifting is often faster because the table lookup often requires physical memory accesses.

If the protocol actual involves an XOR instead of CRC that would be a good thing to know. If not, if you find the actual polynomial (and initial value) please post them.

[EHaskins]

If the protocol actual involves an XOR instead of CRC that would be a good thing to know. If not, if you find the actual polynomial (and initial value) please post them.

I believe the polynomial is 0xEDB88320 and the initial value is 0xFFFFFFFF.

Also I have reason to believe this is the implementation (http://damieng.com/blog/2006/08/08/calculating_crc32_in_c_and_net) used by FIRST for communicating between the FMS and DS.

[Greg McKaskle]

I feel obligated to caution people building a soft driver station to make sure that it has good safety measures in place. NI built a soft driver station early on because we didn't have enough PDB ones for testing. The protocol and such is pretty straightforward, and I'm not really concerned about you messing up any aspect of implementing it. But, the HW driver station has several nice safety features that you may want to keep in play if/when using a soft one.

The ones I'm thinking about is primarily the estop, but also the auto/tele. Actually, I'd encourage you to always start your soft station in auto-disabled and not have history like the switches do. But do try to use the spacebar or a HW red button or something similar to allow for quickly disabling when things get intense.

Other than that, I can't wait to see what you come up with.
Greg McKaskle