FMS enabling sequence?

[Citrus Dad]

The question came up this weekend in Sacramento as there were at least 3 fast auto can grabbers in the field: Does the FMS enable robots in sequence during auto, or simultaneously? And if its in sequence, is it known which stations enable in sequence and what is the delay between each station?

High speed video of 1678 and 971 in a semifinal match show that a delay could affect match outcome.

[AdamHeard]

Originally Posted by Citrus Dad

The question came up this weekend in Sacramento as there were at least 3 fast auto can grabbers in the field: Does the FMS enable robots in sequence during auto, or simultaneously? And if its in sequence, is it known which stations enable in sequence and what is the delay between each station?

High speed video of 1678 and 971 in a semifinal match show that a delay could affect match outcome.

Do you have video?

[ATannahill]

I suggest you view the FMS White Paper to better understand how the field works.

[Kyler Hagler]

Same thing happened on Dallas week one. There were a couple of can grabbers and 118 showed us high speed footage that showed us not moving for ~60ms from when the opposing alliances robot was moving. We were told that the FMS does enable in a sequence but that's all we were told. Don't quote me on the last part.

[rich2202]

There is one Ethernet connection between the FMIS Server and the rest of the world. The commands have to go out serially.

I'm guessing the Cisco Wifi router has 3 channels, and 2 robots are assigned to each channel. Wifi Contention could delay the receipt of commands by a robot.

If the command is routed through the Driver Station, then there is minimal delay between when FMIS sends the Auto Start, and when your DS is first able to react.

How fast your robot can react to the DS commands depends upon how much wifi traffic there is on your signal. Also, the Cisco Router has one ethernet connection, so how fast your DS responds will determine where in the que is your command.

[Tom Bottiglieri]

Originally Posted by rtfgnow

I suggest you view the FMS White Paper to better understand how the field works.

This paper does not address how the FMS software goes about enabling robots, only the order in which it traverses match state.

We have not measured exactly delay, but have anecdotal evidence of seeing some robots move before others. Field timing issues were pretty prevalent last year and it's unclear to me any of it has been fixed.

Unfortunately, the delay from the FMS may decide Einstein.

[FrankJ]

Originally Posted by rich2202

There is one Ethernet connection between the FMIS Server and the rest of the world. The commands have to go out serially.

I'm guessing the Cisco Wifi router has 3 channels, and 2 robots are assigned to each channel. Wifi Contention could delay the receipt of commands by a robot.

The FMS AP has 6 SSIDs Each robot & DS is own its own VLAN & AP. Presumably there is only one ethernet connection to the FMS server. The FMS server sends the enable to the Driver stations which then send the enable to the robots. I don't know how you would be able to predict how much jitter is in all that what testing. Since the enable is being processed by the DS, maybe the speed of the DS has some effect as well?

[dcarr]

I'd be interested to hear how this was approached with Cheesy Arena.

[Thad House]

Based on things I've seen in the past, its a mix between ds, fms, fpga and the robot code itself. Based on my understanding I would say the fms actually affects it very little.

[Jared Russell]

I would think that each DS is running its own polling loop asynchronously at ~50Hz (the rate of driver control packets). So even if the disabled bit toggles simultaneously for all six bots from the FMS (which it doesn't since the FMS->DS packets must be sent serially, but it ought to be close), there could be a 20ms swing in when each DS sends the first enabled packet depending on the phasing.

( I am just guessing at how the FMS and DS are architected here since I don't think it is publicly documented; please set me straight if I have made an incorrect assumption. )

Realistically, with our wireless links, synchronization is always going to be hard.

[wireties]

It could be multicast to begin to deal with the delay of serially issuing the "change of state" messages.

[Thad House]

Originally Posted by Jared Russell

I would think that each DS is running its own polling loop asynchronously at ~50Hz (the rate of driver control packets). So even if the disabled bit toggles simultaneously for all six bots from the FMS (which it doesn't since the FMS->DS packets must be sent serially, but it ought to be close), there could be a 20ms swing in when each DS sends the first enabled packet depending on the phasing.

( I am just guessing at how the FMS and DS are architected here since I don't think it is publicly documented; please set me straight if I have made an incorrect assumption. )

Realistically, with our wireless links, synchronization is always going to be hard.

There's also another 20+ ms delay caused by the wpilibs if you use anything but the sample robot template. Could end up being up to 40ms depending on how the fpga loops.

[Jared Russell]

Originally Posted by Thad House

There's also another 20+ ms delay caused by the wpilibs if you use anything but the sample robot template. Could end up being up to 40ms depending on how the fpga loops.

Please elaborate?

[Jared]

Here's a frame by frame of the Dallas Q39 (118 and 3310 in same match).

118 is going for their 3 tote auto, 3310 is going for containers, and a team 932 (middle of field red side) is driving forward at a high speed in auto mode.

Frame 1 - Yellow lights on field illuminate
Frame 2 - Red/Blue DS stack lights illuminate
Frame 3 - Nothing
Frame 4 - 932 tips back and begins movement
Frame 5 - 932 continues to move
Frame 6 - 3310 begins to drop arms

Another frame by frame on Dallas F1 (118 grabbing from step, 148 auto)

Frame 1 - Yellow lights
Frame 2 - stack lights
Frame 3 - Nothing
Frame 4 - 148's arm moves
Frame 5 - 118 drops arms

From watching a few other matches, there is usually a different number of frames between lights and robot movement for teams like 118 and 3310.

[Thad House]

Originally Posted by Jared Russell

Please elaborate?

In LV I know that it runs disabled for 1 extra loop after it receives an enabled packet. Then it will run auto on the next enabled packet.

Based on the last time I looked in the Java code, it will run auto init, then the next packet run auto periodic. So unless you are starting your sequence in auto init, it wont run motors until it gets a second enabled packet.

Note that the whole time this is happening, the fpga is enabled, so it will run 20ms with the values it last receives. This is why there are times the robot jumps between disabled and enabled.