How much lag is "normal"?

[rsthj]

Update: This discussion applies to Issues from the 2010 FTC season and is no longer relevant for current FTC competition software.

---

Greetings,

We are looking for some insight as to what is considered  "normal" bluetooth lag.  It will of course vary but it would be helpful if teams could share their experiences.  1 sec?  .25 sec?  Unnoticeable?

Thanks much.

[MarkBlack]

In the case of FTC there shouldn't the lag due to Bluetooth should be unnoticeable.   If you are seeing lag it may be for the following reasons.

• You are not using the Communication loop that is in the templates.  This loop has been optimized to prevent Bluetooth lag from occurring. 
• You are using a new(er) Apple computer that has Broadcom Bluetooth hardware.  There is a known issue with some Apple hardware that manifests itself as laggy communication.  The work around for this is to use the Bluetooth dongle that ships with the FTC KOP.  You don't have to do anything, but plug it in.
• You are pushing the NXT to hard with excessively large or inefficient code.  This is the hardest issue to identify, but I have often seen this caused by using nested cases structures (case structures within a case structures within case structures...).  Because it takes the NXT so long to execute the code the Bluetooth appears to be lagging.  If you think this is the case please post your code and I will be happy to give you some pointers for improving its efficiency.

Cheers,

Mark

[rsthj]

Hi Mark,

Thanks for writing.  This is indeed a case of bloated, inefficient code--our main control loop is executing at about 4 hz.  That said, the driving loop in the FTCteleopBasic.vi runs at about 8hz.  The template was run unmodified except to display loop time.  It seems like the 20ms wait to limit to 50hz is a bit optimistic?

One additional question, the documentation states "You can often use Local Variables and Shift Registers to accomplish the same task. Note that, due to the way that they compile, shift registers are faster in Direct mode and local variables are faster in Remote mode."  Could you perhaps expand on that statement?  While there are certain situations that require locals in LabVIEW, using them in place of shift registers seems like a bad coding practice.

Thanks much.

[rsthj]

Greetings Mark,

We've isolated the problem and I wonder if you could comment on the underlying cause.  The attached snippets both use the "TETRIX move DC motors.vi" to accomplish the same task.  However calling the "move DC motors" instance multiple times is more than twice as fast as using the move DC motors (multi) instance. 

Thanks much.

[imaqmonkey]

Hello rsthj,

The reason this happens is because inside the Move DC Motors VI, there are some loops that run through the list of motors in the array to group them according to motor controller. The VI is written this way so that if two motors are connected to the same controller, the two motors will start simultaneously.

Unfortunately, the longer this list is, the more processor-intensive it is for the program to sort all of these motors into groups, and this is the problem you are running into. The code you show in the first image runs faster because the VI does not need to do any sorting. The downside is that the NXT is sending two separate commands to the Motor Controller to stop x1 and x2, so they may not stop/start simultaneously.

My recommendation is that you still use Move DC Motors (grouped) VI, but limit the size of the array to 2 and make sure that those motors are on the same controller.

Hopefully, this will give you the best of both worlds where the sorting loops don't negatively impact performance, but you are still synchronizing motors on the same controller.

Tony