strands-project/strands_qsr_lib

[QTC] rectify timestamps

Closed this issue · 10 comments

I've noticed that QTC timestamps do not match a World_Trace object timestamps. This is expected in default behavior, i.e. validate is True and no_collapse is False (or either of the two conditions).

However, it would be nice/useful when validate is False and no_collapse is True to get back the right timestamps. Here is a function below that rectifies them:

def rectify_qtcb_timestamps(world_trace, world_qsr_trace):
        for t, tqtc in zip(world_trace.get_sorted_timestamps()[1:], world_qsr_trace.get_sorted_timestamps()):
            world_qsr_trace.trace[t] = world_qsr_trace.trace.pop(tqtc)

Can either be done class the QTC if above conditions are met, or can go in the qsrlib_utils/utils.py file.

@cdondrup What do you think?

If this is only the case for qtc then it should got in here: https://github.com/strands-project/strands_qsr_lib/blob/master/qsr_lib/src/qsrlib_qsrs/qsr_qtc_simplified_abstractclass.py

I can add that and call it when validate=False and no_collapse=True.

Sounds good to me, yes it is only for QTC atm. Ideally IMO it should "automatically" return the rectified timestamps when these conditions are met, but I am happy also if you decide it shouldn't. Also, happy where you want to insert it (QTC abstractclass sounds the most reasonable if automatic, otherwise the above function can go in utils to be exposed).

I'll add it to qtc tomorrow most likely and make it automatic as I don't see any problems with that.

This I think is bugged. I will give it a shot to fix it as I think it is in the rectify_timestamps function the issue.

And actually causes qtcbs to fail.

These are the test results for the PR with rectify:

[ROSTEST]-----------------------------------------------------------------------

[qsr_lib.rosunit-qtc_tester/test_qtcb][passed]
[qsr_lib.rosunit-qtc_tester/test_qtcb_future][passed]
[qsr_lib.rosunit-qtc_tester/test_qtcbc][passed]
[qsr_lib.rosunit-qtc_tester/test_qtcbc_future][passed]
[qsr_lib.rosunit-qtc_tester/test_qtcc][passed]
[qsr_lib.rosunit-qtc_tester/test_qtcc_future][passed]

SUMMARY
�[32m * RESULT: SUCCESS�[0m
 * TESTS: 6
 * ERRORS: 0
 * FAILURES: 0

So qtcbs works and also I am currently using it and everything works fine.

Download this world_trace pickle file.

From qsrs_for branch in my repo in the example_ros_client replace the dbg section near the end to the folllowing (dont forget to change the path to load the pickle from):

# ********************** DBG *********************
    import cPickle as pickle
    with open("/home/yiannis/dbg/world_trace_qtcbs_fails.p", "r") as f:
        my_world_trace = pickle.load(f)
    print(my_world_trace.get_sorted_timestamps())
    print(dynamic_args)
    qsrlib_request_message = QSRlib_Request_Message(which_qsr=which_qsr, input_data=my_world_trace, include_missing_data=True,
                                                    dynamic_args=dynamic_args,
                                                    future=args.future)
    # DONT FORGET TO COMMENT OUT FOLLOWING qsrlib_request_message
    # ********************** eof DBG *********************

Yes the bug is here. I know why.

These are the test results for the PR with rectify:
resutls of rostest
So qtcbs works and also I am currently using it and everything works fine.

I am afraid it most defintely didn't and since #95 any QTC results were wrong under certain conditions (validate=False, no_collapse=True, the timestamps of the World_QSR_Trace overlap the timestamps of the World_Trace). Apparently the rostest failed to capture the error and I am not sure it could capture it in any case cause of variable returns (need to look in more detail the rosttest).

You're correct, the test only works on collapsed and validated chains. I'll add a test for non_collapsed and non validated chains at some point.