Resorting Telemetry Data causing difficulty in debugging

[dlevyaaas]

Observed rules of telemetry.addData(key,message);
Rule A) items with unique keys are listed separately in alphabetical order
Rule B) multiple writes with the same key will overwrite the original entries in place

Issue 1: Items entered with unique keys should appear on the display in the order that they are entered. Please take out the re-sorting by key in alphabetical order. This make it difficult to debug time sensitive events.
It is possible to place a timestamp in the key so as to influence the order of the display however that will violate Rule B above. ( meaning you will never be able to overwrite an existing row)

[rgatkinson]

Can I as whether you're using a LinearOpMode or a loop() OpMode?

[dlevyaaas]

Linear but I do not think it matters as I observed problems regardless of the number of hardware cycles.

[rgatkinson]

If any new telemetry gets written by an OpMode, the contents of the telemetry object is transmitted from the robot controller to the driver station after the call to OpMode.loop() (if you're digging around in the decompiled source, have a look at FtcEventLoop.loop()). After it is transmitted, the telemetry is always cleared with a call to telemetry.clearData() (this happens in FtcEventLoopHandler.sendTelemetryData()). Until transmitted, accumulated telemetry is keyed by the first argument to addData(): if multiple addData()s are issued with the same key before transmission, later ones will replace earlier ones.

The net effect is if you change any telemetry then the contents of all telemetry must be rebuilt with addData() calls on every call to loop(). The contents of telemetry accumulated in each loop() call entirely replace the then-current contents of the driver station telemetry section. The telemetry object on the robot is then cleared, and the cycle begins again. It's an all-or-nothing thing: either the driver station telemetry is left entirely alone, or it is completely replaced.

If you're writing code in a loop() OpMode, this is reasonably natural (though I agree about the sorting issue): whatever you wrote in any one loop() call will end up being the contents of the driver station display.

If you're writing in a LinearOpMode, though, you're taking a chance, in that most of the time your addData() calls will all fall in one loop() cycle, and so will work as expected, but sometimes a first chunk of them are in one loop() cycle and the remainder are in the next, which would have the apparent effect of the first chunk not appear on the driver station display. This perhaps seems to be what you are seeing. It is a flaw in the design of LinearOpMode.

[rgatkinson]

You might want to have a look here or here. We have a layer on top of the built-in telemetry which address many of your concerns, such as the sorting issue and a 'log' to support timely delivery of time-critical data.

In a SynchronousOpMode, the tearing of the driver station display I mention above is also fixed, but in a LinearOpMode, that chance still remains.

[dlevyaaas]

"(though I agree about the sorting issue):"
rgatkinson,
With respect to issue #1 Are you able to tag this as a bug or verified issue so it gets worked on for a future release? Perhaps you are correct about Issue 2,3. I have a utility that lets you add telemUtil.addData calls throughout a linearOpmode and defer the actual sending of real telemerty.addData calls in one batch before the loop ends. I'll re-test with that.

In the meantime, I believe the following is still a real issue. Do you concur?

Issue 1: Items entered with unique keys should appear on the display in the order that they are entered. Please take out the re-sorting by key in alphabetical order. This makes it difficult to debug time sensitive events.
It is possible to place a timestamp in the key so as to influence the order of the display however that will violate Rule B above. ( meaning you will never be able to overwrite an existing row)

[dlevyaaas]

rgatkinson - thanks for the advice with LinearOpmode. I changed my utility and no longer observe the missing data and have therefore removed those issues from this report.
The one that still remains however is the issue of resorting. Again, It is preferable to have the unique key telemetry displayed in the order that it is added.
thanks,
David

[calebsander]

In the 2016.01.04 release, Telemetry now uses a LinkedHashMap to store its data, so I suspect this has been fixed. I will test when I can.
Edit: still an issue. Test code:

public class TelemetryOrder extends OpMode {
    public void init() {}
    public void loop() {
        this.telemetry.addData("xyz1", "test");
        this.telemetry.addData("abc2", "test");
        this.telemetry.addData("def3", "test");
    }
}

[rgatkinson]

The 2016.01.04 release has telemetry.setSorted() and telemetry.isSorted() by which this can be controlled. It defaults to sorted for backward compatibility.

[calebsander]

Yup, this seems to work as intended. Can this issue be closed?

[slylockfox]

Sorry for the naive question, but is there a 2016.01.04 release ? I see only the 15.11.04.001 release

[coder-bot]

There is, but it was stored in a beta branch (upstream/beta if I recall
correctly)

On Wednesday, January 13, 2016, Matt Snyder notifications@github.com
wrote:

Sorry for the naive question, but is there a 2016.01.04 release ? I see
only the 15.11.04.001 release

—
Reply to this email directly or view it on GitHub
#43 (comment).

Sincerely,
Max Jarcho

[gearsincorg]

Closed, as this issue was resolved, and relates to previous season code.