Fix/aron conversions

Aron conversions of enums cause errors due to the enums being converted to empty dictionaries. In case of other conversions, it is difficult to see where errors come from, if they originate from int64 vs. plain int or, lesser, from double vs. float differences. This merge request tries to

• Fix existing problems
• Make detecting usage mistakes easier (although at the cost of some more checks)
• Make aron-related type conversions from common python types easier (e.g., specifying a time or pose using plain python float values)

Thanks @peller and @gao for help.

If @peller, @gao and/or @plewnia have objections regarding the changes, please feel free to communicate them so we can discuss how to do it in the best way!

requested review from @plewnia

assigned to @daab

added 4 commits

• da351743...c9515b06 - 3 commits from branch master
• b7e8c808 - Merge branch 'master' into fix/aron-conversions

Compare with previous version

This fails for the conversion of longs in the tests provided in 'tests/armarx/armarx_memory/aron/test_conversion.py', unless one changes the long value to be of type np.int64.

@peller: we need to decide if we want to only use np.int64 or if normal int and long values should be allowed too.

added 1 commit

• 9fd44b8e - remove duplicate line using old type

Compare with previous version

Oh, thanks, I did not see that! However, if I get it correctly, this failure isn't introduced by this MR, but occurs on master as well. Or did I miss something?

added 2 commits

• 5f466bc6 - use duration from date_time
• b1a6e92d - Merge branch 'fix/aron-conversions' of...

Compare with previous version

added 2 commits

• 2127a265 - change import order for durations
• fe119345 - define numeric constant in duration, as datetime has to depend on it

Compare with previous version

added 1 commit

• 8733a28a - make Duration compatible with automatic aron conversions

Compare with previous version

@plewnia: I would like to merge the dev/programming-by-demonstration branches in several repositories into the mainline, as we are approaching using the new PbD GUI on the robots. To keep the merge requests reasonably small, this one (fix/aron-conversions) should be merged separately/beforehand.

Can you please decide on the np.int64/long/int question you raised above, so that I can either adapt this MR before merging, or you can merge it directly? Thank you!

merged

mentioned in commit 08270447

mentioned in issue #19 (closed)

resolved all threads

mentioned in issue #20 (closed)