Clarification of Team Update #5

[bomber7]

Part of Team Update #5 states that we are only allowed to send 1024 byte packets from the robot to the driver station.

Even before this update I figured out how to use the librarys to send custom packets from the cRIO to the computer. Using this I built a pretty-reliable (though not perfect) way to print formated debug messages across the ethernet complete with its own checksum. =P

When I first got this working I noticied that the first 8 bytes of the packet are untouchable, and that no matter what the packet is always 1024 bytes long.

As far as I understand the packets I send from the robot don't go to the driver station, they go straight to the computer.

I heard that you can have a laptop with your driver station. Does that mean I can plug a computer into the driver station during a match and get custom packets from the robot?

I have plans in which I could get data from the robot and display it on the computer which would be useful to the drivers. Is this legal?


P.S. If anyone is intrested in my system or what I've discovered while messing with the cRIO's communications just ask.

[Joe Ross]

It sounds like you are sending your own TCP/IP packets on your own port. This type of data will be blocked by the FMS when you are on the field. If you only want to use it for debugging, don't worry about it, but don't plan on using it on the field.

You can still use the dashboard class to printf data to the dashboard, and that won't be blocked.

I've also written my own application that sends data through TCP/IP, so I understand how frustrating it can be to find out it won't be able to do anything on the field.

[bomber7]

Your sure? Even if the laptop is plugged directly into the driver station?

I quote from team update #5:
"If a team really wants to transmit images from the camera back to the Driver Station during a competition, they can decompose the video frame and pass it as user data in the available 984 bytes per packet. "

This makes it sound like you CAN send custom packets. As long as they conform to those size rules and the target, in this case the laptop is plugged into the driver station. (Into port #2)

This way the packets will goto the driverstation then the laptop.
I don't suppose theres any answer in the FAQ?
P.S. What does FMS stand for?

[Mike Betts]

Originally Posted by bomber7

...P.S. What does FMS stand for?

Field Management System

[bomber7]

Can anyone confirm your allowed to have a laptop with the driverstation during competition?


Something else I noticied about rule #5

Another quote:
"This year, the Field Management System will not pass data sent through that port during a match (to ensure adequate system performance during competition events, until the new system is better characterized in actual competition settings)."

More things I noticied after the fifth re-read. Its dissallowing large camera packets so as to make sure the network doesn't get bogged down. Sending 1024 packets at even a 10 mpbs connection shouldn't be a problem. They only specifically state that that particular port is disabled. They also state that 1024 byte packet size will be enforced and that around 95% of that packet will be usable for user data.

From my point of view the user has no buisness sending any (custom) packets at all to the driver station. Its not going to compute anything for you, thats the cRIO's job. However if a laptop were connected to the driver station and it simply passed the (custom) packets on to it, that would be useful.

[Joe Ross]

Originally Posted by bomber7

Can anyone confirm your allowed to have a laptop with the driverstation during competition?

See <R81>

Originally Posted by bomber7

Something else I noticied about rule #5

Another quote:
"This year, the Field Management System will not pass data sent through that port during a match (to ensure adequate system performance during competition events, until the new system is better characterized in actual competition settings)."

More things I noticied after the fifth re-read. Its dissallowing large camera packets so as to make sure the network doesn't get bogged down. Sending 1024 packets at even a 10 mpbs connection shouldn't be a problem. They only specifically state that that particular port is disabled. They also state that 1024 byte packet size will be enforced and that around 95% of that packet will be usable for user data.

The reason team update 5 was phrased the way it was is because the GDC got tired of people asking on the Q/A if they could view live camera data. If many people had instead asked of they could send raw TCP/IP data through Port XXXXX, the answer would have been that data through port XXXXX is blocked and send it through the user data. In reality, all data except the dashboard data will be blocked.

Originally Posted by bomber7

From my point of view the user has no buisness sending any (custom) packets at all to the driver station. Its not going to compute anything for you, thats the cRIO's job. However if a laptop were connected to the driver station and it simply passed the (custom) packets on to it, that would be useful.

That is exactly what the dashboard class does.

[bomber7]

Wow >.>
I can't believe I never fully looked into the dashboard class. It really could have saved me a lot of time. I'm going to look further into this and get back to this thread.

I'm going to spend some time examining the dashboard packets.

I see Dashboard.h but I'm not sure how to use it as of yet. Continuing research.

After looking into it further, I think this is going to be pretty easy to harness my way.

Under the assumption we can recieve the packets using any program we want, this is going to be easier than the way I was previously doing it.

[Phazonmutant]

Yes, you can have a laptop connected to the Driver Station in competition: http://forums.usfirst.org/showthread.php?t=11640

And apparently other people are thinking about redirecting the packets to a custom gui: http://forums.usfirst.org/showthread.php?t=11360