Using Maya Cakmak's PbD system as a base, my fork contains branches for different projects, as well as branches for different aspects within each project.
This means there are lots of branches, and it can be hard to tell what is what.
Git's branching system doesn't support branch descriptions, and branch names need to be concise, so the this README.md file in the root of the repository will contain information about the branch it's in.
This branch (groovy-devel) should just be a mirror of the groovy-devel branch of the main PbD code (PR2/pr2_pbd:groovy-devel). I will list below information about all of the branches that branch off of this (that is, the projects that are based off of the groovy PbD code).
I'll try to keep the branch descriptions up to date below in this readme, but most of the documentation will likely be from the main documentation effort I did on May 14, 2014.
I'll try even harder to keep the branch descriptions up to date in the README.md file of each branch. Check there as the authority for documentation.
Branches are listed alphabetically below by project. At the bottom are the 'default' branches (that came with the fork).
Language-only PbD.
WIP.
Less constrained language → PbD commands.
Joint work with the UW SPF folks (Yoav + Kenton).
This branch is for trying out the automatic grasping capabilities built into the PR2 Object Manipulation stack (pr2_interactive_manipulation).
I'm testing out the built-in functionality by trying to run demos and then using API calls.
repo: vovakkk/pr2_pbd:hydro
Get PbD migrated to hydro & catkin.
Vladimir did a near complete rewrite of the PbD code, and took the opportunity to bring about several new features:
- Use MoveIt! as the PR2 controller
- Javascript / HTML / CSS button UI using rosbridge (no RQT)
- planned: Javascript / WebGL UI using ros3djs (no Rviz)
- YAML action representation
- Richer action representation (action reference, trajectories)
- Various other library migrations because of catkin and/or Hydro, usually to a newer and better library
See what's used (and what's not) in PbD, as well as what's slowing us down (if anything).
There is a lot of code in PbD that is
- legacy (deprecated and unsupported)
- undocumented
- confusing (variable names imply incorrect object types)
- unorganized (public / private / static / class functions mixed around)
- slow (marker movement w/ IK calls)
I think profiling is the first step just to see what can be cleaned up and perhaps get a vauge handle to what's taking the most time.
Experiment with documentation tools.
I'm primarily trying
-
Sphinx
- By default, you need to write a bunch of separate documentation, and then this renders it nicely. You can use autodoc to automatically include docstrings, but it doesn't seem 'out-of-the-box' usable (you still need to write .rst files).
-
pycco
- This uses your # comments to make an 'annotated source' view: a side-by-side view of your code and comments, like with underscore.js. It doesn't do the method / function level documentation.
"da" stands for "Data Analysis;" run tests, analyze data and generate graphs with this branch.
This branch has several functions related to the analysis of collected data:
-
automatically run reachability tests for users data on a test set (can take many hours for all users & tests)
-
draw graphs for the results of reachability tests as well as other tests (e.g. success testing)
-
processes other log files (both processed and raw) and generate graphs
This branch contains the final versions of crowd PbD graphs.
Generate new test data (for users to fix, or to run evaluation) with this branch.
"Test data" means the automatic sampling of object positions / rotations, using a given seed and object sizes / numbers, for varied (but specified) numbers of unreachable poses.
This code, once launched via a click on the GUI, will continue sampling data until the specified quantity is fulfilled. (Look in launch file or code for these quantities.)
The data is a 'fresh set' of experiment data, and as such can be used either as a worker's starting point to collect data, or left untouched and used as test data (reachability and/or success).
Record the video (screen recording) of the user interface with this branch.
This branch was a tiny offshoot off of normal development where I hardcoded in the size/position/rotation of a new object (lavamoss) not used in the user study. I then used this object to record a video of the user interface as a tutorial for a worker to watch.
I used a different object so that workers who viewed the video would not get extra information about how to complete their task.
In case it's not clear from the above, the code is quite old (pre-active sampling) and should only be used for user interface video-purposes.
Run user studies with this branch.
This is the branch on which the Crowd PbD project is based. It serves as the "main branch" off of which most other code is branched. User studies may be run using this branch.
Run user studies on "true" crowd (MTurk) with this branch.
We need to do some serious work before mock-objects is ready for "the crowd:"
-
GUI improvements (top 5 suggestions from user study)
-
ROS on servers (AWS?)
This was branched directly off of mock-objects.
Collect object positions (before user study) with this branch.
This branch was used to record object positions on the PR2 in order to get baseline positions and rotations of real-world objects on the table. It prints the coordinates of objects it scans (and I think it can also create 'mock' boxes in the UI of provided boxes, allowing you to compare virtual vs real object positions).
This isn't actively used during user studies; it was merely used to collect prerequisite data for running the studies.
Test user-provided fixes on real test data on the real robot (desktop version, with GUI) on this branch.
This branch contains the score functions as well as a full GUI for loading up test scenarios, automatically scoring them based on different score functions, and loading the action. It is the desktop component of the success testing.
As a prerequisite, you must have done reachability testing (all worker actions vs all test scenarios). This is because doing so is expensive (dozens of hours) and so should be done offline and beforehand. Because of this requirement, we can quickly filter out unreachable demonstrations and score only the reachable ones. (This data is a log file, generated by branch da).
Test user-provided fixes on real test data on the real robot (PR2 version) with this branch.
This branch contains the PR2-side of doing success testing. This means that when a test scenario is loaded, it will send to the GUI 'mocked' (white silhouette) boxes for the locations of the objects in the test scenario, as well as boxes (green) for the 'true' objects that it scans and recognizes.
When doing success testing, the goal is to match the 'real world' object as closely as possible with the mocked version that is rendered (as this is the test case).
For more info on success testing (score functions, prerequisites) see the desktop version of this branch, success-testing.
Code to run a demo of Mike's ICRA 2014 paper on the PR2 (instead of Gambit).
This runs a loop where the robot asks for colored blocks in an 8 x 8 grid and sets them down on a plane in front of it. It is based off of Priya Rao's code (she did the majority of the work). Implementation notes are here.
This code is a demo for the press release for the ICRA 2014 work, which actually doesn't run PbD at all, but rather Mike's crowdsourcing framework. However, we had to switch the demo from running on the Gambit to the PR2 because the Gambit is out of commission, and the PbD framework provided an easy code foundation on which to do this.
This branch contains the 'main' PbD code, off of which others fork and build. It's in "development." As far as I know, this is never built / realeased into binaries.
All project-agnostic improvements and bugfixes should go here.
As far as I know, this branch is the release that is built into (debian) binaries for ROS distribution with apt-get.
I think that this branch is only for marking release points in groovy-devel. I could be wrong, though.
As far as I know, this branch is a legacy branch that marks a point on the groovy-devel line that is pre-groovy (i.e. before the branch marked 'groovy'), and serves no purpose.
Just a legacy checkpoint, looks like.