Clean up Interaction.py

[mbforbes]

I wanted to submit this first to discuss any changes before I go through the other files. This is also the "central point" of the application so I thought it best to do first, as this is often where people start looking.

Main changes are:

• make code follow pep8, the standard Python style guide
• make docstrings follow Google standards, including module/class descriptions as well as function descriptions that include types & descriptions of arguments and return values
• remove dead code (undo, edit, save)
• refactor (e.g. execution_z_offset) or make meaningful (e.g. 0 → Side.RIGHT) magic constants
• make all private functions named so (with a preceeding _)
• organize all functions (based on public/private and functionality patterns)
• annotate long argument lists to functions with their types

[mbforbes]

BTW I tested this semi-thoroughly in simulation and everything worked.

[mayacakmak]

(not sure if my comment got logged, so here it is again)

This all sounds great!

I'm still slightly worried about introducing bugs so perhaps we can agree on a common testing protocol. The main worry is breaking our go-to demo, so let's agree on what that basic demo is and we can just make sure the demo works before each merge. What do you think?

[mbforbes]

I totally agree about the need for testing to ensure the main branch stays functional!

Before I made the pull request I did the following tests:

• try all commands before any actions made (most fail; exercises most error checking cases)
• make an action, and try all commands (most succeed; delete all/last step still fail)
• try all commands twice in a row (exercises "already frozen" etc.)
• save poses, then try commands that require saved poses (delete all / last step)
• create more actions, switch between them, including not-possible switching
• select steps and actions in the GUI
• record objects
• saves poses relative and not relative to objects
• execute action
• stop execution (during and not during execution)
• move some poses to be unreachable, try execution, move back, try execution
• switch, delete / add steps, execute again

This seemed "generally thorough" enough, but you writing this has gotten me thinking, we can do better.

I will investigate programmatic testing. I've wanted to do this for a while, but my ROS / PbD knowledge wasn't up to par. I won't spend too long on it, but I think at least half of it will be really easy.

The easy half: I'll just publish speech and GUI commands with a test node to exercise all the above cases that I mentioned. Only hard part about this will be moving the robot's arms to test relativeness of objects, but this probably also possible with a couple other messages.

The hard half: how do we programmatically check for success of tests? Node didn't crash? Check state of robot? Expose a whole new API in PbD for querying the state of the system? Inject testing code throughout the system for querying it? This seems possible, especially given how easy it is in python to get around public/private functions. I will investigate.