FMS enabling sequence?

[MikeE]

Caveat: I have had training on use of the FMS but do not know details of it's implementation. I'm engaging in this discussion because it is a interesting topic and educated speculation is fun!

Originally Posted by Citrus Dad

If the serial enabling differences are cumulative, the first bot will move 0.1 second before the last one. That's more than the difference in speed between several of the can grabbers at the moment.

That's a huge assumption. Not only would that require serial enabling, but it assumes only one packet is being sent anywhere per 20ms time slot. As other posters have stated it's much more likely that packets are being sent to all DS within the same 20ms frame.
Just from a safety perspective the overall architecture should allow EStop commands to be acted on quickly, so I feel a 100ms scale of potential delay is very unlikely.

I agree with Thad and other's suggestion that all DSs are likely sent an enable packet within a much smaller window - let's assume within 5ms. With that assumption, the critical issue is where the DS is in the polling cycle when it received the enable, and that's not under FMS control. Big picture: fewer than half of matches would have one or more teams receive the enable one polling period later. With the worst case design of fixed enable order, some specific stations would have a higher probability of getting the one period delay.

So back to my earlier question: given all the other sources of variability, does a finite probability of a 20ms delay matter in the "real world"?
I don't know how consistent the top teams are at can burgling, but my gut sense is that this order of potential delay is of secondary or tertiary concern. However I'm happy to be corrected by members of those inspirational teams.

Originally Posted by MrRoboSteve

6. The FMS developers are likely to be curious about a thread on CD entitled "FMS enabling sequence."

Hi guys!

[Citrus Dad]

Originally Posted by MikeE

That's a huge assumption.

So back to my earlier question: given all the other sources of variability, does a finite probability of a 20ms delay matter in the "real world"?
I don't know how consistent the top teams are at can burgling, but my gut sense is that this order of potential delay is of secondary or tertiary concern. However I'm happy to be corrected by members of those inspirational teams.

I was positing the question because I'm not technically knowledgeable about the FMS. But it appears that a delay of 20ms, particularly if it is cumulative across stations, will be significant in the canburglar race. Teams are already under 300ms and expect much, much faster. That delay could be a high % of the time.

[AdamHeard]

Originally Posted by themccannman

So, since this doesn't seem resolved is there any way we can figure this out aside from FIRST publicly posting the FMS code? They only other way I can think is setting up two robots with known mechanism speeds and comparing them at each possible driver station combination. This would be pretty difficult to do though as you would need to reserve an entire field for only 2 teams for at least 30-60 mins, likely not possible with time constraints and demand for practice matches at most competitions.

It would be easier to add LEDs to all robots.

Unfortunately (as far as I can tell) the RSL doesn't visually convey exactly when teams are enabled.

[orangelight]

Originally Posted by AdamHeard

It would be easier to add LEDs to all robots.

Unfortunately (as far as I can tell) the RSL doesn't visually convey exactly when teams are enabled.

I think that would be a great idea. We always have to guess what time the robot is enabled when we run our canburglars.

[Wetzel]

Originally Posted by MrRoboSteve

6. The FMS developers are likely to be curious about a thread on CD entitled "FMS enabling sequence."

Fine entertainment on the internet super highway.

[Bennett548]

20 ms matters a great deal. I expect in that much time some teams would be 1/4 of the way to the cans already.

A seperate question: why are we all guessing about how FMS works? Why isn't the code 100% available to everyone? Was it developed by an external company that doesn't want their IP shared?

[Bennett548]

We have some evidence of FMS enabling sequence timing issues. At msc, in playoffs, 548 and our partner 1711 ran very similar autonomous modes (i.e. cheesecake). We both run java, and used talons srx connected by can.

The troubling issue is that 548 consistently started moving 10-30 ms before 1711. 548 was always red 1, and 1711 was red 3.

We are working with 1711 to look into DS logs to find out if there was some delay recorded there.

Can anything be done about this? As far as specific details FMS is a black box to us teams.

Hopefully there is a Snowden among the FMS developers that will spill the beans and let the community suggest improvements.

[MikeE]

Originally Posted by Bennett548

20 ms matters a great deal. I expect in that much time some teams would be 1/4 of the way to the cans already.

We will actually know in a couple of days. If they do exist then 80ms canburglers will be a sight to behold! In the meantime there are hundreds of things a team can directly control.

Originally Posted by Bennett548

Hopefully there is a Snowden among the FMS developers that will spill the beans and let the community suggest improvements.

While I don't think that's an apt comparison, after this past winter Moscow might be a welcome respite from the New Hampshire weather.