{{ .Title }}
+ {{ with .Params.lead }}{{ . }}
{{ end }} +
+ {{ .Content }}
+
+
+ 
+ 
+
+
+
+
+
+ 
+ 
+ 
+
{{ . }}
{{ end }} +Now: {{ . }}
{{ end }} - {{ if $member.now_at }} -Now: {{ $member.now_at }}
+ {{ with $member.era }} +{{ . }}
{{ end }}{{ $member.bio }}
diff --git a/layouts/partials/publication-card.html b/layouts/partials/publication-card.html index 8b34300..a2ada01 100644 --- a/layouts/partials/publication-card.html +++ b/layouts/partials/publication-card.html @@ -23,16 +23,25 @@{{ .Params.venue }} + {{ with .Params.award }}— {{ . }}{{ end }}
-{{ .Params.description }}
+ {{ with .Params.description }} +{{ . }}
+ {{ end }}+ Researchers actively working with the lab. +
+ + {{ $anyCurrent := false }} {{ range $cat := $categories }} - {{ $members := where $.Site.Data.members.current "category" $cat }} + {{ $members := where $current "category" $cat.key }} {{ if $members }} -No current members listed yet.
+ {{ end }}
+ Former members of the lab. Many of the entries below were imported
+ from the archived sbpl.net site and reflect each member’s
+ role at that time; some career-history details are still being filled
+ in.
+
+ A few snapshots from the lab over the years (recovered from the
+ archived sbpl.net site).
+
+ 
+ 
+ 
+ Private Files Upload:
+username: REDACTED password: REDACTED
+ + diff --git a/static/archive/legacy-drupal/content/blocks/001-private-files.json b/static/archive/legacy-drupal/content/blocks/001-private-files.json new file mode 100644 index 0000000..d3c1849 --- /dev/null +++ b/static/archive/legacy-drupal/content/blocks/001-private-files.json @@ -0,0 +1,10 @@ +{ + "bid": 1, + "info": "private files", + "format": "full_html", + "slug": "private-files", + "body_html_rewritten": "Private Files Upload:
\r\nusername: REDACTED password: REDACTED
\r\n", + "body_html_raw": "Private Files Upload:
\r\nusername: REDACTED password: REDACTED
\r\n", + "body_markdown": "[Private Files](/private/SBPL/) Upload:\n\nusername: REDACTED password: REDACTED\n", + "_redaction_note": "Original Drupal block body contained plaintext credentials for a /private/SBPL/ upload form on the (now offline) sbpl.net site. Credentials were redacted before publishing this archive snapshot." +} diff --git a/static/archive/legacy-drupal/content/blocks/001-private-files.md b/static/archive/legacy-drupal/content/blocks/001-private-files.md new file mode 100644 index 0000000..4540633 --- /dev/null +++ b/static/archive/legacy-drupal/content/blocks/001-private-files.md @@ -0,0 +1,6 @@ +# private files + +[Private Files](/private/SBPL/) Upload: + +username: REDACTED password: REDACTED + diff --git a/static/archive/legacy-drupal/content/blocks/002-publicfiles.html b/static/archive/legacy-drupal/content/blocks/002-publicfiles.html new file mode 100644 index 0000000..431f917 --- /dev/null +++ b/static/archive/legacy-drupal/content/blocks/002-publicfiles.html @@ -0,0 +1,7 @@ + +Member of the lab? Want to see private files? Log in!
+ + diff --git a/static/archive/legacy-drupal/content/blocks/002-publicfiles.json b/static/archive/legacy-drupal/content/blocks/002-publicfiles.json new file mode 100644 index 0000000..7d1d8b1 --- /dev/null +++ b/static/archive/legacy-drupal/content/blocks/002-publicfiles.json @@ -0,0 +1,9 @@ +{ + "bid": 2, + "info": "publicfiles", + "format": "full_html", + "slug": "publicfiles", + "body_html_rewritten": "Member of the lab? Want to see private files? Log in!
\r\n", + "body_html_raw": "Member of the lab? Want to see private files? Log in!
\r\n", + "body_markdown": "Member of the lab? Want to see private files? Log in!\n" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/blocks/002-publicfiles.md b/static/archive/legacy-drupal/content/blocks/002-publicfiles.md new file mode 100644 index 0000000..9d1ca7f --- /dev/null +++ b/static/archive/legacy-drupal/content/blocks/002-publicfiles.md @@ -0,0 +1,3 @@ +# publicfiles + +Member of the lab? Want to see private files? Log in! diff --git a/static/archive/legacy-drupal/content/blocks_index.json b/static/archive/legacy-drupal/content/blocks_index.json new file mode 100644 index 0000000..93848c3 --- /dev/null +++ b/static/archive/legacy-drupal/content/blocks_index.json @@ -0,0 +1,20 @@ +[ + { + "bid": 1, + "info": "private files", + "slug": "private-files", + "format": "full_html", + "file_html": "content/blocks/001-private-files.html", + "file_md": "content/blocks/001-private-files.md", + "file_json": "content/blocks/001-private-files.json" + }, + { + "bid": 2, + "info": "publicfiles", + "slug": "publicfiles", + "format": "full_html", + "file_html": "content/blocks/002-publicfiles.html", + "file_md": "content/blocks/002-publicfiles.md", + "file_json": "content/blocks/002-publicfiles.json" + } +] \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/menus.json b/static/archive/legacy-drupal/content/menus.json new file mode 100644 index 0000000..28b64c6 --- /dev/null +++ b/static/archive/legacy-drupal/content/menus.json @@ -0,0 +1,910 @@ +{ + "user-menu": [ + { + "menu_name": "user-menu", + "mlid": 2, + "plid": 0, + "link_path": "user", + "router_path": "user", + "link_title": "User account", + "options": { + "alter": true + }, + "module": "system", + "hidden": 0, + "external": 0, + "weight": -10, + "depth": 1, + "node_target": null, + "children": [ + { + "menu_name": "user-menu", + "mlid": 10, + "plid": 2, + "link_path": "user/register", + "router_path": "user/register", + "link_title": "Create new account", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "user-menu", + "mlid": 14, + "plid": 2, + "link_path": "user/login", + "router_path": "user/login", + "link_title": "Log in", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "user-menu", + "mlid": 20, + "plid": 2, + "link_path": "user/password", + "router_path": "user/password", + "link_title": "Request new password", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "user-menu", + "mlid": 15, + "plid": 0, + "link_path": "user/logout", + "router_path": "user/logout", + "link_title": "Log out", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 10, + "depth": 1, + "node_target": null, + "children": [] + } + ], + "navigation": [ + { + "menu_name": "navigation", + "mlid": 3, + "plid": 0, + "link_path": "comment/%", + "router_path": "comment/%", + "link_title": "Comment permalink", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 28, + "plid": 3, + "link_path": "comment/%/view", + "router_path": "comment/%/view", + "link_title": "View comment", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": -10, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 26, + "plid": 3, + "link_path": "comment/%/edit", + "router_path": "comment/%/edit", + "link_title": "Edit", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 24, + "plid": 3, + "link_path": "comment/%/approve", + "router_path": "comment/%/approve", + "link_title": "Approve", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 1, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 25, + "plid": 3, + "link_path": "comment/%/delete", + "router_path": "comment/%/delete", + "link_title": "Delete", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 2, + "depth": 2, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 4, + "plid": 0, + "link_path": "filter/tips", + "router_path": "filter/tips", + "link_title": "Compose tips", + "options": [], + "module": "system", + "hidden": 1, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 5, + "plid": 0, + "link_path": "node/%", + "router_path": "node/%", + "link_title": "", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 62, + "plid": 5, + "link_path": "node/%/view", + "router_path": "node/%/view", + "link_title": "View", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": -10, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 41, + "plid": 5, + "link_path": "node/%/edit", + "router_path": "node/%/edit", + "link_title": "Edit", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 38, + "plid": 5, + "link_path": "node/%/delete", + "router_path": "node/%/delete", + "link_title": "Delete", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 1, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 52, + "plid": 5, + "link_path": "node/%/revisions", + "router_path": "node/%/revisions", + "link_title": "Revisions", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 2, + "depth": 2, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 146, + "plid": 52, + "link_path": "node/%/revisions/%/delete", + "router_path": "node/%/revisions/%/delete", + "link_title": "Delete earlier revision", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 3, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 147, + "plid": 52, + "link_path": "node/%/revisions/%/revert", + "router_path": "node/%/revisions/%/revert", + "link_title": "Revert to earlier revision", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 3, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 148, + "plid": 52, + "link_path": "node/%/revisions/%/view", + "router_path": "node/%/revisions/%/view", + "link_title": "Revisions", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 3, + "node_target": null, + "children": [] + } + ] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 6, + "plid": 0, + "link_path": "node/add", + "router_path": "node/add", + "link_title": "Add content", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 219, + "plid": 6, + "link_path": "node/add/article", + "router_path": "node/add/article", + "link_title": "Article", + "options": { + "attributes": { + "title": "Use articles for time-sensitive content like news, press releases or blog posts." + } + }, + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 220, + "plid": 6, + "link_path": "node/add/page", + "router_path": "node/add/page", + "link_title": "Basic page", + "options": { + "attributes": { + "title": "Use basic pages for your static content, such as an 'About us' page." + } + }, + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 17, + "plid": 0, + "link_path": "user/%", + "router_path": "user/%", + "link_title": "My account", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 63, + "plid": 17, + "link_path": "user/%/view", + "router_path": "user/%/view", + "link_title": "View", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": -10, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 31, + "plid": 17, + "link_path": "user/%/cancel", + "router_path": "user/%/cancel", + "link_title": "Cancel account", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 156, + "plid": 31, + "link_path": "user/%/cancel/confirm/%/%", + "router_path": "user/%/cancel/confirm/%/%", + "link_title": "Confirm account cancellation", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 3, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 40, + "plid": 17, + "link_path": "user/%/edit", + "router_path": "user/%/edit", + "link_title": "Edit", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 126, + "plid": 40, + "link_path": "user/%/edit/account", + "router_path": "user/%/edit/account", + "link_title": "Account", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 3, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 191, + "plid": 17, + "link_path": "user/%/shortcuts", + "router_path": "user/%/shortcuts", + "link_title": "Shortcuts", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 23, + "plid": 0, + "link_path": "comment/reply/%", + "router_path": "comment/reply/%", + "link_title": "Add new comment", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 27, + "plid": 0, + "link_path": "taxonomy/term/%", + "router_path": "taxonomy/term/%", + "link_title": "Taxonomy term", + "options": [], + "module": "system", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 88, + "plid": 27, + "link_path": "taxonomy/term/%/view", + "router_path": "taxonomy/term/%/view", + "link_title": "View", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [] + }, + { + "menu_name": "navigation", + "mlid": 87, + "plid": 27, + "link_path": "taxonomy/term/%/edit", + "router_path": "taxonomy/term/%/edit", + "link_title": "Edit", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 10, + "depth": 2, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 187, + "plid": 0, + "link_path": "search", + "router_path": "search", + "link_title": "Search", + "options": [], + "module": "system", + "hidden": 1, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 188, + "plid": 187, + "link_path": "search/node", + "router_path": "search/node", + "link_title": "Content", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": -10, + "depth": 2, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 190, + "plid": 188, + "link_path": "search/node/%", + "router_path": "search/node/%", + "link_title": "Content", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 3, + "node_target": null, + "children": [] + } + ] + }, + { + "menu_name": "navigation", + "mlid": 189, + "plid": 187, + "link_path": "search/user", + "router_path": "search/user", + "link_title": "Users", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 2, + "node_target": null, + "children": [ + { + "menu_name": "navigation", + "mlid": 193, + "plid": 189, + "link_path": "search/user/%", + "router_path": "search/user/%", + "link_title": "Users", + "options": [], + "module": "system", + "hidden": -1, + "external": 0, + "weight": 0, + "depth": 3, + "node_target": null, + "children": [] + } + ] + } + ] + } + ], + "shortcut-set-1": [ + { + "menu_name": "shortcut-set-1", + "mlid": 216, + "plid": 0, + "link_path": "node/add", + "router_path": "node/add", + "link_title": "Add content", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": -50, + "depth": 1, + "node_target": null, + "children": [] + }, + { + "menu_name": "shortcut-set-1", + "mlid": 217, + "plid": 0, + "link_path": "admin/content", + "router_path": "admin/content", + "link_title": "Find content", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": -49, + "depth": 1, + "node_target": null, + "children": [] + }, + { + "menu_name": "shortcut-set-1", + "mlid": 412, + "plid": 0, + "link_path": "node/3", + "router_path": "node/%", + "link_title": "People", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": -48, + "depth": 1, + "node_target": { + "nid": 3, + "title": "People" + }, + "children": [] + } + ], + "main-menu": [ + { + "menu_name": "main-menu", + "mlid": 396, + "plid": 0, + "link_path": "node/9", + "router_path": "node/%", + "link_title": "Home", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": -50, + "depth": 1, + "node_target": { + "nid": 9, + "title": "Home" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 525, + "plid": 0, + "link_path": "node/45", + "router_path": "node/%", + "link_title": "Tutorials", + "options": { + "attributes": [] + }, + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 0, + "depth": 1, + "node_target": { + "nid": 45, + "title": "Tutorials" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 395, + "plid": 0, + "link_path": "node/3", + "router_path": "node/%", + "link_title": "People", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 1, + "depth": 1, + "node_target": { + "nid": 3, + "title": "People" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 397, + "plid": 0, + "link_path": "node/10", + "router_path": "node/%", + "link_title": "Publications", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 2, + "depth": 1, + "node_target": { + "nid": 10, + "title": "Publications" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 398, + "plid": 0, + "link_path": "node/11", + "router_path": "node/%", + "link_title": "Videos", + "options": { + "attributes": [] + }, + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 3, + "depth": 1, + "node_target": { + "nid": 11, + "title": "Videos" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 399, + "plid": 0, + "link_path": "node/12", + "router_path": "node/%", + "link_title": "Robots", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 4, + "depth": 1, + "node_target": { + "nid": 12, + "title": "Robots" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 417, + "plid": 0, + "link_path": "node/32", + "router_path": "node/%", + "link_title": "Software", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 5, + "depth": 1, + "node_target": { + "nid": 32, + "title": "Software" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 418, + "plid": 0, + "link_path": "node/33", + "router_path": "node/%", + "link_title": "Files", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 6, + "depth": 1, + "node_target": { + "nid": 33, + "title": " " + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 415, + "plid": 0, + "link_path": "node/30", + "router_path": "node/%", + "link_title": "Contact", + "options": { + "attributes": [] + }, + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 8, + "depth": 1, + "node_target": { + "nid": 30, + "title": "Contact" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 513, + "plid": 0, + "link_path": "node/44", + "router_path": "node/%", + "link_title": "Calender", + "options": [], + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 8, + "depth": 1, + "node_target": { + "nid": 44, + "title": "Calendar" + }, + "children": [] + }, + { + "menu_name": "main-menu", + "mlid": 416, + "plid": 0, + "link_path": "node/31", + "router_path": "node/%", + "link_title": "Login", + "options": { + "attributes": { + "title": "" + } + }, + "module": "menu", + "hidden": 0, + "external": 0, + "weight": 50, + "depth": 1, + "node_target": { + "nid": 31, + "title": "Login" + }, + "children": [] + } + ] +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0003-people.html b/static/archive/legacy-drupal/content/pages/0003-people.html new file mode 100644 index 0000000..7f30043 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0003-people.html @@ -0,0 +1,61 @@ + ++
+
Haojie "Tony" Zhang
+ + ++
Lab Cookout (Summer 2011)
+
+
The group goes to Kennywood (Summer 2012)
+
\r\n
\r\n
Haojie "Tony" Zhang
\r\n\r\n\r\n\r\n
Lab Cookout (Summer 2011)
\r\n![\"\"](\"../../media/images/DSC00420.JPG\")
\r\n
The group goes to Kennywood (Summer 2012)
\r\n![\"\"](\"../../media/images/andrew-mike-kenny.jpg\")
![\"\"](\"../../media/images/matt-ed-jon-kenny.jpg\")
![\"\"](\"../../media/images/brian-kenny-shooped.jpg\")
\r\n
\r\n
Haojie "Tony" Zhang
\r\n\r\n\r\n\r\n
Lab Cookout (Summer 2011)
\r\n![\"\"](\"/shared/Images/DSC00420.JPG\")
\r\n
The group goes to Kennywood (Summer 2012)
\r\n![\"\"](\"/shared/Images/andrew-mike-kenny.jpg\")
![\"\"](\"/shared/Images/matt-ed-jon-kenny.jpg\")
![\"\"](\"/shared/Images/brian-kenny-shooped.jpg\")
Search-based Planning Laboratory researches methodologies and algorithms that enable autonomous systems to act fast, intelligently and robustly. Our research concentrates mostly on developing novel planning approaches, coming up with novel heuristic searches and investigating how planning can be combined with machine learning. Our work spans graph theory, algorithms, data structures, machine learning and of course robotics. We use our algorithms to build real-time planners for complex robotic systems operating in real world and performing challenging tasks ranging from autonomous navigation and autonomous flight to multi-agent systems and to full-body mobile manipulation.
+
+ In a bit more details, we study such problems as high-dimensional motion planning, task planning, planning under uncertainty and multi-agent planning. Our goal is to develop planners that work in real-time and deal with complex real-world environments. We are also actively pursuing planning approaches that "learn from experience". In all of our work, we strive to develop methods that come with rigorous analytical guarantees on performance such as completeness and bounds on sub-optimality. Such guarantees help dramatically users to analyze and anticipate the behavior of autonomous systems which is crucial for safe autonomy alongside people. The lab is home to several robots including PR2 robot, segbot robot, hexarotor aerial vehicle, quadrotor aerial vehicles and few other smaller aerial vehicles. In addition, we build planners for a number of large-scale robotic systems such as humanoid robots and full-scale helicopter.
New! Please join the sbpl-users mailing list by signing up here.
++
Project Birdhouse! Autonomous Assembly
+ + ++
+ + +
April 23, 2013: Autonomous Hexarotor Avoids a Person
+ ++ + diff --git a/static/archive/legacy-drupal/content/pages/0009-home.json b/static/archive/legacy-drupal/content/pages/0009-home.json new file mode 100644 index 0000000..5ee3482 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0009-home.json @@ -0,0 +1,27 @@ +{ + "nid": 9, + "vid": 9, + "type": "page", + "language": "und", + "title": "Home", + "slug": "home", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 1, + "comment": 1, + "created": 1340166841, + "changed": 1434546172, + "url_aliases": [ + "Home" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "
Search-based Planning Laboratory researches methodologies and algorithms that enable autonomous systems to act fast, intelligently and robustly. Our research concentrates mostly on developing novel planning approaches, coming up with novel heuristic searches and investigating how planning can be combined with machine learning. Our work spans graph theory, algorithms, data structures, machine learning and of course robotics. We use our algorithms to build real-time planners for complex robotic systems operating in real world and performing challenging tasks ranging from autonomous navigation and autonomous flight to multi-agent systems and to full-body mobile manipulation.
\r\n\t
\r\n\tIn a bit more details, we study such problems as high-dimensional motion planning, task planning, planning under uncertainty and multi-agent planning. Our goal is to develop planners that work in real-time and deal with complex real-world environments. We are also actively pursuing planning approaches that "learn from experience". In all of our work, we strive to develop methods that come with rigorous analytical guarantees on performance such as completeness and bounds on sub-optimality. Such guarantees help dramatically users to analyze and anticipate the behavior of autonomous systems which is crucial for safe autonomy alongside people. The lab is home to several robots including PR2 robot, segbot robot, hexarotor aerial vehicle, quadrotor aerial vehicles and few other smaller aerial vehicles. In addition, we build planners for a number of large-scale robotic systems such as humanoid robots and full-scale helicopter.
New! Please join the sbpl-users mailing list by signing up here.
\r\n\r\n
Project Birdhouse! Autonomous Assembly
\r\n\r\n\r\n\r\n
\r\n\r\n\r\n
April 23, 2013: Autonomous Hexarotor Avoids a Person
\r\n\r\n\r\n", + "body_markdown": "Search-based Planning Laboratory researches methodologies and algorithms that enable autonomous systems to act fast, intelligently and robustly. Our research concentrates mostly on developing novel planning approaches, coming up with novel heuristic searches and investigating how planning can be combined with machine learning. Our work spans graph theory, algorithms, data structures, machine learning and of course robotics. We use our algorithms to build real-time planners for complex robotic systems operating in real world and performing challenging tasks ranging from autonomous navigation and autonomous flight to multi-agent systems and to full-body mobile manipulation.\n\n In a bit more details, we study such problems as high-dimensional motion planning, task planning, planning under uncertainty and multi-agent planning. Our goal is to develop planners that work in real-time and deal with complex real-world environments. We are also actively pursuing planning approaches that \"learn from experience\". In all of our work, we strive to develop methods that come with rigorous analytical guarantees on performance such as completeness and bounds on sub-optimality. Such guarantees help dramatically users to analyze and anticipate the behavior of autonomous systems which is crucial for safe autonomy alongside people. The lab is home to several robots including PR2 robot, segbot robot, hexarotor aerial vehicle, quadrotor aerial vehicles and few other smaller aerial vehicles. In addition, we build planners for a number of large-scale robotic systems such as humanoid robots and full-scale helicopter.\n\n**New!** Please join the *sbpl-users *mailing list by signing up [here](https://groups.google.com/forum/#!forum/sbpl-users).\n\n***Project Birdhouse! Autonomous Assembly***\n\n***April 23, 2013: ****Autonomous Hexarotor Avoids a Person***\n", + "body_html_raw": "
Search-based Planning Laboratory researches methodologies and algorithms that enable autonomous systems to act fast, intelligently and robustly. Our research concentrates mostly on developing novel planning approaches, coming up with novel heuristic searches and investigating how planning can be combined with machine learning. Our work spans graph theory, algorithms, data structures, machine learning and of course robotics. We use our algorithms to build real-time planners for complex robotic systems operating in real world and performing challenging tasks ranging from autonomous navigation and autonomous flight to multi-agent systems and to full-body mobile manipulation.
\r\n\t
\r\n\tIn a bit more details, we study such problems as high-dimensional motion planning, task planning, planning under uncertainty and multi-agent planning. Our goal is to develop planners that work in real-time and deal with complex real-world environments. We are also actively pursuing planning approaches that "learn from experience". In all of our work, we strive to develop methods that come with rigorous analytical guarantees on performance such as completeness and bounds on sub-optimality. Such guarantees help dramatically users to analyze and anticipate the behavior of autonomous systems which is crucial for safe autonomy alongside people. The lab is home to several robots including PR2 robot, segbot robot, hexarotor aerial vehicle, quadrotor aerial vehicles and few other smaller aerial vehicles. In addition, we build planners for a number of large-scale robotic systems such as humanoid robots and full-scale helicopter.
New! Please join the sbpl-users mailing list by signing up here.
\r\n\r\n
Project Birdhouse! Autonomous Assembly
\r\n\r\n\r\n\r\n
\r\n\r\n\r\n
April 23, 2013: Autonomous Hexarotor Avoids a Person
\r\n\r\n\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0009-home.md b/static/archive/legacy-drupal/content/pages/0009-home.md new file mode 100644 index 0000000..8e39b97 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0009-home.md @@ -0,0 +1,11 @@ +# Home + +Search-based Planning Laboratory researches methodologies and algorithms that enable autonomous systems to act fast, intelligently and robustly. Our research concentrates mostly on developing novel planning approaches, coming up with novel heuristic searches and investigating how planning can be combined with machine learning. Our work spans graph theory, algorithms, data structures, machine learning and of course robotics. We use our algorithms to build real-time planners for complex robotic systems operating in real world and performing challenging tasks ranging from autonomous navigation and autonomous flight to multi-agent systems and to full-body mobile manipulation. + + In a bit more details, we study such problems as high-dimensional motion planning, task planning, planning under uncertainty and multi-agent planning. Our goal is to develop planners that work in real-time and deal with complex real-world environments. We are also actively pursuing planning approaches that "learn from experience". In all of our work, we strive to develop methods that come with rigorous analytical guarantees on performance such as completeness and bounds on sub-optimality. Such guarantees help dramatically users to analyze and anticipate the behavior of autonomous systems which is crucial for safe autonomy alongside people. The lab is home to several robots including PR2 robot, segbot robot, hexarotor aerial vehicle, quadrotor aerial vehicles and few other smaller aerial vehicles. In addition, we build planners for a number of large-scale robotic systems such as humanoid robots and full-scale helicopter. + +**New!** Please join the *sbpl-users *mailing list by signing up [here](https://groups.google.com/forum/#!forum/sbpl-users). + +***Project Birdhouse! Autonomous Assembly*** + +***April 23, 2013: ****Autonomous Hexarotor Avoids a Person*** diff --git a/static/archive/legacy-drupal/content/pages/0010-publications.html b/static/archive/legacy-drupal/content/pages/0010-publications.html new file mode 100644 index 0000000..fa11652 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0010-publications.html @@ -0,0 +1,7 @@ + +
Mobile Manipulation Videos
+
Manipulation Videos
+
Navigation Videos
+
Dynamic Environment Videos
+
Hexacopter Videos
+
Mobile Manipulation Videos
\r\n![](\"http://img.youtube.com/vi/lpNbt7btxgg/1.jpg\")
Manipulation Videos
\r\n![](\"http://img.youtube.com/vi/KrMsyDVWo8A/1.jpg\")
![](\"http://img.youtube.com/vi/GreYnmUfCnU/1.jpg\")
![](\"http://img.youtube.com/vi/AmpbvymDQwk/1.jpg\")
![](\"http://img.youtube.com/vi/nZoVGzQPSQI/1.jpg\")
![](\"http://img.youtube.com/vi/Zlt6EJVdUN8/1.jpg\")
Navigation Videos
\r\n![](\"http://img.youtube.com/vi/D3jkj8KSIQk/1.jpg\")
![](\"http://img.youtube.com/vi/NnfJUPz6__M/1.jpg\")
![](\"http://img.youtube.com/vi/WeXdCmEpRW0/1.jpg\")
![](\"http://img.youtube.com/vi/NMKhf3B5968/1.jpg\")
![](\"http://img.youtube.com/vi/Y1TZMQTEahs/1.jpg\")
Dynamic Environment Videos
\r\n![](\"http://img.youtube.com/vi/khzJUVnN4rw/1.jpg\")
![](\"http://img.youtube.com/vi/RZ4lEXjg5fQ/1.jpg\")
![](\"http://img.youtube.com/vi/kdaeQMo5Khk/1.jpg\")
Hexacopter Videos
\r\n![](\"http://img.youtube.com/vi/-abpnZ960kY/1.jpg\")
![](\"http://img.youtube.com/vi/UlxYl625tu0/3.jpg\")
![](\"http://img.youtube.com/vi/twFoHp5CGMo/1.jpg\")
Mobile Manipulation Videos
\r\nManipulation Videos
\r\nNavigation Videos
\r\nDynamic Environment Videos
\r\nHexacopter Videos
\r\n
Allen the PR2 is a mobile manipulation platform developed by Willow Garage (http://www.willowgarage.com/pages/pr2/overview). The robot has two 7 degree of freedom arms for manipulating objects and an omni-directional base for navigation. The robot has an array of sensors including two Hokuyo laser range finders and seven cameras for building 3D maps of its surroundings and identifying objects. In our lab we use Allen to test a variety of planners including single-arm, dual-arm, navigation (in position and orientation), and full-body mobile manipulation.
++
Man-Hack the Hexacopter is our lab unmanned aerial vehicle (UAV). The base is a Mikrokopter Hexa XL frame with a custom-made carbon fiber computer carrier and blade guard. The onboard processing is performed by an i7 COM Express module running ROS allowing the Hexacopter to operate without any offboard connectitivity. Similar to Melvin, the hexacopter uses two orthogonally mounted Hokuyo laser range finders as the primary localization sensors augmented by GPS and two wide-angle camera systems. Total system weight is approximately 4.3kg with over 15 minutes of flight time.
+
+ The hexacopter is used for 3-D planning research including planning under uncertainty, planning in the presence of 3-D dynamic obstacles, and visual servoing in conjunction with planning.
+
+
Melvin the Segbot is based on a Segway RMP 200 platform with a custom made rear trailer allowing it to operate in a variety of environments both indoors and outdoors. The custom computer system consists of an 8-core server and a 2-core controller giving Melvin the highest computational capability of any of our lab robots. Like all of our robots, Melvin uses the ROS operating system running on Kubuntu for the software infrastructure. For sensing the environment, Melvin relies on two Hokuyo laser range finders which can be supplemented by GPS or vision systems when required.
+
+ Melvin is used primarily for ground navigation research including research in exploration, planning in the presense of dynamic obstacles, and multi-robot planning.
![\"pr2\"](\"../../media/uploads/site/all/images/pr2_grasp.png\")
Allen the PR2 is a mobile manipulation platform developed by Willow Garage (http://www.willowgarage.com/pages/pr2/overview). The robot has two 7 degree of freedom arms for manipulating objects and an omni-directional base for navigation. The robot has an array of sensors including two Hokuyo laser range finders and seven cameras for building 3D maps of its surroundings and identifying objects. In our lab we use Allen to test a variety of planners including single-arm, dual-arm, navigation (in position and orientation), and full-body mobile manipulation.
\r\n\r\n
![\"hexabot\"](\"../../media/uploads/site/all/images/hexarotor.png\")
![\"\"](\"../../media/images/IMG_2895_small.jpeg\")
![\"\"](\"../../media/images/MC-UAV-1-2_small.jpeg\")
Man-Hack the Hexacopter is our lab unmanned aerial vehicle (UAV). The base is a Mikrokopter Hexa XL frame with a custom-made carbon fiber computer carrier and blade guard. The onboard processing is performed by an i7 COM Express module running ROS allowing the Hexacopter to operate without any offboard connectitivity. Similar to Melvin, the hexacopter uses two orthogonally mounted Hokuyo laser range finders as the primary localization sensors augmented by GPS and two wide-angle camera systems. Total system weight is approximately 4.3kg with over 15 minutes of flight time.
\r\n\t
\r\n\tThe hexacopter is used for 3-D planning research including planning under uncertainty, planning in the presence of 3-D dynamic obstacles, and visual servoing in conjunction with planning.
\r\n
\r\n
![\"segbot\"](\"../../media/images/segbot_small.png\")
![\"\"](\"../../media/images/IMG_2896_small.jpeg\")
![\"\"](\"../../media/images/IMG_2897_small.jpeg\")
Melvin the Segbot is based on a Segway RMP 200 platform with a custom made rear trailer allowing it to operate in a variety of environments both indoors and outdoors. The custom computer system consists of an 8-core server and a 2-core controller giving Melvin the highest computational capability of any of our lab robots. Like all of our robots, Melvin uses the ROS operating system running on Kubuntu for the software infrastructure. For sensing the environment, Melvin relies on two Hokuyo laser range finders which can be supplemented by GPS or vision systems when required.
\r\n\t
\r\n\tMelvin is used primarily for ground navigation research including research in exploration, planning in the presense of dynamic obstacles, and multi-robot planning.
![\"pr2\"](\"/sites/default/files/site/all/images/pr2_grasp.png\")
Allen the PR2 is a mobile manipulation platform developed by Willow Garage (http://www.willowgarage.com/pages/pr2/overview). The robot has two 7 degree of freedom arms for manipulating objects and an omni-directional base for navigation. The robot has an array of sensors including two Hokuyo laser range finders and seven cameras for building 3D maps of its surroundings and identifying objects. In our lab we use Allen to test a variety of planners including single-arm, dual-arm, navigation (in position and orientation), and full-body mobile manipulation.
\r\n\r\n
![\"hexabot\"](\"/sites/default/files/site/all/images/hexarotor.png\")
![\"\"](\"/shared/Images/IMG_2895_small.jpeg\")
![\"\"](\"/shared/Images/MC-UAV-1-2_small.jpeg\")
Man-Hack the Hexacopter is our lab unmanned aerial vehicle (UAV). The base is a Mikrokopter Hexa XL frame with a custom-made carbon fiber computer carrier and blade guard. The onboard processing is performed by an i7 COM Express module running ROS allowing the Hexacopter to operate without any offboard connectitivity. Similar to Melvin, the hexacopter uses two orthogonally mounted Hokuyo laser range finders as the primary localization sensors augmented by GPS and two wide-angle camera systems. Total system weight is approximately 4.3kg with over 15 minutes of flight time.
\r\n\t
\r\n\tThe hexacopter is used for 3-D planning research including planning under uncertainty, planning in the presence of 3-D dynamic obstacles, and visual servoing in conjunction with planning.
\r\n
\r\n
![\"segbot\"](\"/shared/Images/segbot_small.png\")
![\"\"](\"/shared/Images/IMG_2896_small.jpeg\")
![\"\"](\"/shared/Images/IMG_2897_small.jpeg\")
Melvin the Segbot is based on a Segway RMP 200 platform with a custom made rear trailer allowing it to operate in a variety of environments both indoors and outdoors. The custom computer system consists of an 8-core server and a 2-core controller giving Melvin the highest computational capability of any of our lab robots. Like all of our robots, Melvin uses the ROS operating system running on Kubuntu for the software infrastructure. For sensing the environment, Melvin relies on two Hokuyo laser range finders which can be supplemented by GPS or vision systems when required.
\r\n\t
\r\n\tMelvin is used primarily for ground navigation research including research in exploration, planning in the presense of dynamic obstacles, and multi-robot planning.
PhD student in CIS, UPenn
+ + diff --git a/static/archive/legacy-drupal/content/pages/0013-ben-cohen.json b/static/archive/legacy-drupal/content/pages/0013-ben-cohen.json new file mode 100644 index 0000000..c579d04 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0013-ben-cohen.json @@ -0,0 +1,27 @@ +{ + "nid": 13, + "vid": 13, + "type": "page", + "language": "und", + "title": "Ben Cohen", + "slug": "ben-cohen", + "uid": 11, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599028, + "changed": 1344290038, + "url_aliases": [ + "BenCohen" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in CIS, UPenn
\r\n", + "body_markdown": "PhD student in CIS, UPenn\n", + "body_html_raw": "PhD student in CIS, UPenn
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0013-ben-cohen.md b/static/archive/legacy-drupal/content/pages/0013-ben-cohen.md new file mode 100644 index 0000000..e9f2ff6 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0013-ben-cohen.md @@ -0,0 +1,3 @@ +# Ben Cohen + +PhD student in CIS, UPenn diff --git a/static/archive/legacy-drupal/content/pages/0014-brian-macallister.html b/static/archive/legacy-drupal/content/pages/0014-brian-macallister.html new file mode 100644 index 0000000..a6c9180 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0014-brian-macallister.html @@ -0,0 +1,9 @@ + +Brian MacAllister
+
Me: a research staff member, CMU.
+ + diff --git a/static/archive/legacy-drupal/content/pages/0014-brian-macallister.json b/static/archive/legacy-drupal/content/pages/0014-brian-macallister.json new file mode 100644 index 0000000..4515856 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0014-brian-macallister.json @@ -0,0 +1,27 @@ +{ + "nid": 14, + "vid": 14, + "type": "page", + "language": "und", + "title": "Brian MacAllister", + "slug": "brian-macallister", + "uid": 13, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599070, + "changed": 1344388676, + "url_aliases": [ + "BrianMacAllister" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "
Brian MacAllister
\r\n![\"\"](\"../../media/images/brian.jpg\")
Me: a research staff member, CMU.
\r\n", + "body_markdown": "**Brian MacAllister**\n\n Me: a research staff member, CMU.\n", + "body_html_raw": "
Brian MacAllister
\r\n![\"\"](\"/shared/Images/brian.jpg\")
Me: a research staff member, CMU.
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0014-brian-macallister.md b/static/archive/legacy-drupal/content/pages/0014-brian-macallister.md new file mode 100644 index 0000000..57d9c32 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0014-brian-macallister.md @@ -0,0 +1,5 @@ +# Brian MacAllister + +**Brian MacAllister** + + Me: a research staff member, CMU. diff --git a/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.html b/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.html new file mode 100644 index 0000000..bb3a6b1 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.html @@ -0,0 +1,7 @@ + +
Reasearch Staff
+ + diff --git a/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.json b/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.json new file mode 100644 index 0000000..fdb30cf --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.json @@ -0,0 +1,27 @@ +{ + "nid": 15, + "vid": 15, + "type": "page", + "language": "und", + "title": "Andrew Dornbush", + "slug": "andrew-dornbush", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599102, + "changed": 1344135530, + "url_aliases": [ + "AndrewDornbush" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "Reasearch Staff
\r\n", + "body_markdown": "Reasearch Staff\n", + "body_html_raw": "Reasearch Staff
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.md b/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.md new file mode 100644 index 0000000..eb1acc5 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0015-andrew-dornbush.md @@ -0,0 +1,3 @@ +# Andrew Dornbush + +Reasearch Staff diff --git a/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.html b/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.html new file mode 100644 index 0000000..501c749 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.html @@ -0,0 +1,7 @@ + +PhD student in MEAM, UPenn, co-advised with V. Kumar
+ + diff --git a/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.json b/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.json new file mode 100644 index 0000000..c2f0e1b --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.json @@ -0,0 +1,27 @@ +{ + "nid": 16, + "vid": 16, + "type": "page", + "language": "und", + "title": "Subhrajit Bhattacharya", + "slug": "subhrajit-bhattacharya", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599156, + "changed": 1344135548, + "url_aliases": [ + "SubhrajitBhattacharya" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in MEAM, UPenn, co-advised with V. Kumar
\r\n", + "body_markdown": "PhD student in MEAM, UPenn, co-advised with V. Kumar\n", + "body_html_raw": "PhD student in MEAM, UPenn, co-advised with V. Kumar
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.md b/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.md new file mode 100644 index 0000000..ebd6edf --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0016-subhrajit-bhattacharya.md @@ -0,0 +1,3 @@ +# Subhrajit Bhattacharya + +PhD student in MEAM, UPenn, co-advised with V. Kumar diff --git a/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.html b/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.html new file mode 100644 index 0000000..699dafc --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.html @@ -0,0 +1,59 @@ + +I am currently (as of Spring 2015) a PhD student in the SBP Lab here at CMU. My interests are in Robot Design, System Integration, Path Planning, Exploration, Navigation, and High-level Control.
+I am also looking for a job...
+19 years as a Navy Officer - qualified and served as a Ship's Engineer for a Fast-Attack Nuclear Submarine (USS OKLAHOMA CITY, SSN-723) and division officer (USS TOLEDO, SSN-769).
+Taught undergrad Logic Design Lab and Intro to Robotics courses.
+Designed and constructed the frame, computer case, stabilization system and other mechanical components, and the electrical distribution and storage systems, .
+Modified existing UAV kit to add sensors and additional computational devices to the UAV. Wrote the drivers, controllers, and high-level logic control nodes for the system. Performed all flight testing and design verifications testing.
+ +www.jbutzke.com
+ + diff --git a/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.json b/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.json new file mode 100644 index 0000000..d658f7e --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.json @@ -0,0 +1,27 @@ +{ + "nid": 17, + "vid": 17, + "type": "page", + "language": "und", + "title": "Jonathan Butzke", + "slug": "jonathan-butzke", + "uid": 32, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599235, + "changed": 1425152701, + "url_aliases": [ + "JonathanButzke" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "I am currently (as of Spring 2015) a PhD student in the SBP Lab here at CMU. My interests are in Robot Design, System Integration, Path Planning, Exploration, Navigation, and High-level Control.
\r\nI am also looking for a job...
\r\n19 years as a Navy Officer - qualified and served as a Ship's Engineer for a Fast-Attack Nuclear Submarine (USS OKLAHOMA CITY, SSN-723) and division officer (USS TOLEDO, SSN-769).
\r\nTaught undergrad Logic Design Lab and Intro to Robotics courses.
\r\nDesigned and constructed the frame, computer case, stabilization system and other mechanical components, and the electrical distribution and storage systems, .
\r\nModified existing UAV kit to add sensors and additional computational devices to the UAV. Wrote the drivers, controllers, and high-level logic control nodes for the system. Performed all flight testing and design verifications testing.
\r\n\r\nwww.jbutzke.com
\r\n", + "body_markdown": "# Current Status\n\nI am currently (as of Spring 2015) a PhD student in the SBP Lab here at CMU. My interests are in Robot Design, System Integration, Path Planning, Exploration, Navigation, and High-level Control.\n\nI am also looking for a job...\n\n# Previous Experience\n\n19 years as a Navy Officer - qualified and served as a Ship's Engineer for a Fast-Attack Nuclear Submarine (USS OKLAHOMA CITY, SSN-723) and division officer (USS TOLEDO, SSN-769).\n\nTaught undergrad Logic Design Lab and Intro to Robotics courses.\n\n## Skills:\n\n- Mechanical\n\n - Tools - Mill, Lathe, Brake, Press, just about every hand tool known to mankind\n - Past Projects - automotive engine rebuild, ground robot design & construction, UAV design & construction\n\n- Electrical\n\n - Residential construction, digital circuit design, SMD soldering, PCB layout\n\n- Computer\n\n - Software - C, C++, 6800 series assembly, Matlab, Solidworks, Linux, ROS\n - Hardware - Arduino, COM Express, TTL, SMD\n\n## Past Robotics Projects\n\n### Segbot\n\nDesigned and constructed the frame, computer case, stabilization system and other mechanical components, and the electrical distribution and storage systems, .\n\n### Hexacopter\n\nModified existing UAV kit to add sensors and additional computational devices to the UAV. Wrote the drivers, controllers, and high-level logic control nodes for the system. Performed all flight testing and design verifications testing.\n\n## Website:\n\nwww.jbutzke.com\n", + "body_html_raw": "I am currently (as of Spring 2015) a PhD student in the SBP Lab here at CMU. My interests are in Robot Design, System Integration, Path Planning, Exploration, Navigation, and High-level Control.
\r\nI am also looking for a job...
\r\n19 years as a Navy Officer - qualified and served as a Ship's Engineer for a Fast-Attack Nuclear Submarine (USS OKLAHOMA CITY, SSN-723) and division officer (USS TOLEDO, SSN-769).
\r\nTaught undergrad Logic Design Lab and Intro to Robotics courses.
\r\nDesigned and constructed the frame, computer case, stabilization system and other mechanical components, and the electrical distribution and storage systems, .
\r\nModified existing UAV kit to add sensors and additional computational devices to the UAV. Wrote the drivers, controllers, and high-level logic control nodes for the system. Performed all flight testing and design verifications testing.
\r\n\r\nwww.jbutzke.com
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.md b/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.md new file mode 100644 index 0000000..4d7f6ed --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0017-jonathan-butzke.md @@ -0,0 +1,43 @@ +# Jonathan Butzke + +# Current Status + +I am currently (as of Spring 2015) a PhD student in the SBP Lab here at CMU. My interests are in Robot Design, System Integration, Path Planning, Exploration, Navigation, and High-level Control. + +I am also looking for a job... + +# Previous Experience + +19 years as a Navy Officer - qualified and served as a Ship's Engineer for a Fast-Attack Nuclear Submarine (USS OKLAHOMA CITY, SSN-723) and division officer (USS TOLEDO, SSN-769). + +Taught undergrad Logic Design Lab and Intro to Robotics courses. + +## Skills: + +- Mechanical + + - Tools - Mill, Lathe, Brake, Press, just about every hand tool known to mankind + - Past Projects - automotive engine rebuild, ground robot design & construction, UAV design & construction + +- Electrical + + - Residential construction, digital circuit design, SMD soldering, PCB layout + +- Computer + + - Software - C, C++, 6800 series assembly, Matlab, Solidworks, Linux, ROS + - Hardware - Arduino, COM Express, TTL, SMD + +## Past Robotics Projects + +### Segbot + +Designed and constructed the frame, computer case, stabilization system and other mechanical components, and the electrical distribution and storage systems, . + +### Hexacopter + +Modified existing UAV kit to add sensors and additional computational devices to the UAV. Wrote the drivers, controllers, and high-level logic control nodes for the system. Performed all flight testing and design verifications testing. + +## Website: + +www.jbutzke.com diff --git a/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.html b/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.html new file mode 100644 index 0000000..599cc70 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.html @@ -0,0 +1,7 @@ + +PhD student in CIS, UPenn, co-advised with B. Taskar
+ + diff --git a/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.json b/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.json new file mode 100644 index 0000000..12d2282 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.json @@ -0,0 +1,27 @@ +{ + "nid": 18, + "vid": 18, + "type": "page", + "language": "und", + "title": "Chris Clingerman", + "slug": "chris-clingerman", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599421, + "changed": 1344135561, + "url_aliases": [ + "ChrisClingerman" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in CIS, UPenn, co-advised with B. Taskar
\r\n", + "body_markdown": "PhD student in CIS, UPenn, co-advised with B. Taskar\n", + "body_html_raw": "PhD student in CIS, UPenn, co-advised with B. Taskar
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.md b/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.md new file mode 100644 index 0000000..18e0a2d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0018-chris-clingerman.md @@ -0,0 +1,3 @@ +# Chris Clingerman + +PhD student in CIS, UPenn, co-advised with B. Taskar diff --git a/static/archive/legacy-drupal/content/pages/0019-john-drake.html b/static/archive/legacy-drupal/content/pages/0019-john-drake.html new file mode 100644 index 0000000..4b25553 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0019-john-drake.html @@ -0,0 +1,7 @@ + +PhD student in CIS, UPenn, co-advised with A. Safonova
+ + diff --git a/static/archive/legacy-drupal/content/pages/0019-john-drake.json b/static/archive/legacy-drupal/content/pages/0019-john-drake.json new file mode 100644 index 0000000..6af1f7f --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0019-john-drake.json @@ -0,0 +1,27 @@ +{ + "nid": 19, + "vid": 19, + "type": "page", + "language": "und", + "title": "John Drake", + "slug": "john-drake", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599446, + "changed": 1344135568, + "url_aliases": [ + "JohnDrake" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in CIS, UPenn, co-advised with A. Safonova
\r\n", + "body_markdown": "PhD student in CIS, UPenn, co-advised with A. Safonova\n", + "body_html_raw": "PhD student in CIS, UPenn, co-advised with A. Safonova
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0019-john-drake.md b/static/archive/legacy-drupal/content/pages/0019-john-drake.md new file mode 100644 index 0000000..8f3f6bd --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0019-john-drake.md @@ -0,0 +1,3 @@ +# John Drake + +PhD student in CIS, UPenn, co-advised with A. Safonova diff --git a/static/archive/legacy-drupal/content/pages/0020-steven-gray.html b/static/archive/legacy-drupal/content/pages/0020-steven-gray.html new file mode 100644 index 0000000..02c502b --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0020-steven-gray.html @@ -0,0 +1,7 @@ + +PhD student in MEAM, UPenn, co-advised with V. Kumar
+ + diff --git a/static/archive/legacy-drupal/content/pages/0020-steven-gray.json b/static/archive/legacy-drupal/content/pages/0020-steven-gray.json new file mode 100644 index 0000000..db27ede --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0020-steven-gray.json @@ -0,0 +1,27 @@ +{ + "nid": 20, + "vid": 20, + "type": "page", + "language": "und", + "title": "Steven Gray", + "slug": "steven-gray", + "uid": 31, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599474, + "changed": 1344452675, + "url_aliases": [ + "StevenGray" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in MEAM, UPenn, co-advised with V. Kumar
\r\n", + "body_markdown": "PhD student in MEAM, UPenn, co-advised with V. Kumar\n", + "body_html_raw": "PhD student in MEAM, UPenn, co-advised with V. Kumar
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0020-steven-gray.md b/static/archive/legacy-drupal/content/pages/0020-steven-gray.md new file mode 100644 index 0000000..d09c448 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0020-steven-gray.md @@ -0,0 +1,3 @@ +# Steven Gray + +PhD student in MEAM, UPenn, co-advised with V. Kumar diff --git a/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.html b/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.html new file mode 100644 index 0000000..4d31dcf --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.html @@ -0,0 +1,7 @@ + +PhD student in CIS, UPenn
+ + diff --git a/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.json b/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.json new file mode 100644 index 0000000..e44e7a0 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.json @@ -0,0 +1,27 @@ +{ + "nid": 21, + "vid": 21, + "type": "page", + "language": "und", + "title": "Kalin Gochev", + "slug": "kalin-gochev", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599493, + "changed": 1344135581, + "url_aliases": [ + "KalinGochev" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in CIS, UPenn
\r\n", + "body_markdown": "PhD student in CIS, UPenn\n", + "body_html_raw": "PhD student in CIS, UPenn
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.md b/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.md new file mode 100644 index 0000000..a1cb1b0 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0021-kalin-gochev.md @@ -0,0 +1,3 @@ +# Kalin Gochev + +PhD student in CIS, UPenn diff --git a/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.html b/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.html new file mode 100644 index 0000000..c95cc3a --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.html @@ -0,0 +1,8 @@ + +PhD student in Robotics, CMU, co-advised with A. Stentz
+Currently on leave of absence
+ + diff --git a/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.json b/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.json new file mode 100644 index 0000000..151564c --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.json @@ -0,0 +1,27 @@ +{ + "nid": 22, + "vid": 22, + "type": "page", + "language": "und", + "title": "Bradford Neuman", + "slug": "bradford-neuman", + "uid": 33, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599525, + "changed": 1344493624, + "url_aliases": [ + "BradfordNeuman" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in Robotics, CMU, co-advised with A. Stentz
\r\nCurrently on leave of absence
\r\n", + "body_markdown": "PhD student in Robotics, CMU, co-advised with A. Stentz\n\nCurrently on leave of absence\n", + "body_html_raw": "PhD student in Robotics, CMU, co-advised with A. Stentz
\r\nCurrently on leave of absence
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.md b/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.md new file mode 100644 index 0000000..d89a775 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0022-bradford-neuman.md @@ -0,0 +1,5 @@ +# Bradford Neuman + +PhD student in Robotics, CMU, co-advised with A. Stentz + +Currently on leave of absence diff --git a/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.html b/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.html new file mode 100644 index 0000000..d0ad7ec --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.html @@ -0,0 +1,7 @@ + +PhD student in CIS, UPenn, co-advised with A. Safonova
+ + diff --git a/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.json b/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.json new file mode 100644 index 0000000..19fdd12 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.json @@ -0,0 +1,27 @@ +{ + "nid": 23, + "vid": 23, + "type": "page", + "language": "und", + "title": "Aline Normoyle", + "slug": "aline-normoyle", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599547, + "changed": 1344135596, + "url_aliases": [ + "AlineNormoyle" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in CIS, UPenn, co-advised with A. Safonova
\r\n", + "body_markdown": "PhD student in CIS, UPenn, co-advised with A. Safonova\n", + "body_html_raw": "PhD student in CIS, UPenn, co-advised with A. Safonova
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.md b/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.md new file mode 100644 index 0000000..2ccb9cb --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0023-aline-normoyle.md @@ -0,0 +1,3 @@ +# Aline Normoyle + +PhD student in CIS, UPenn, co-advised with A. Safonova diff --git a/static/archive/legacy-drupal/content/pages/0024-mike-phillips.html b/static/archive/legacy-drupal/content/pages/0024-mike-phillips.html new file mode 100644 index 0000000..77a9a55 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0024-mike-phillips.html @@ -0,0 +1,7 @@ + +PhD student in Robotics, CMU
+ + diff --git a/static/archive/legacy-drupal/content/pages/0024-mike-phillips.json b/static/archive/legacy-drupal/content/pages/0024-mike-phillips.json new file mode 100644 index 0000000..aeb1c20 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0024-mike-phillips.json @@ -0,0 +1,27 @@ +{ + "nid": 24, + "vid": 24, + "type": "page", + "language": "und", + "title": "Mike Phillips", + "slug": "mike-phillips", + "uid": 27, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599574, + "changed": 1345840108, + "url_aliases": [ + "MikePhillips" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "PhD student in Robotics, CMU
\r\n", + "body_markdown": "PhD student in Robotics, CMU\n", + "body_html_raw": "PhD student in Robotics, CMU
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0024-mike-phillips.md b/static/archive/legacy-drupal/content/pages/0024-mike-phillips.md new file mode 100644 index 0000000..ac46861 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0024-mike-phillips.md @@ -0,0 +1,3 @@ +# Mike Phillips + +PhD student in Robotics, CMU diff --git a/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.html b/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.html new file mode 100644 index 0000000..fe9660d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.html @@ -0,0 +1,7 @@ + +Masters student in Robotics, CMU
+ + diff --git a/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.json b/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.json new file mode 100644 index 0000000..7cb9834 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.json @@ -0,0 +1,27 @@ +{ + "nid": 25, + "vid": 25, + "type": "page", + "language": "und", + "title": "Venkatraman Narayanan", + "slug": "venkatraman-narayanan", + "uid": 34, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599594, + "changed": 1344545585, + "url_aliases": [ + "VenkatramanNarayanan" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "Masters student in Robotics, CMU
\r\n", + "body_markdown": "Masters student in Robotics, CMU\n", + "body_html_raw": "Masters student in Robotics, CMU
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.md b/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.md new file mode 100644 index 0000000..3dab78d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0025-venkatraman-narayanan.md @@ -0,0 +1,3 @@ +# Venkatraman Narayanan + +Masters student in Robotics, CMU diff --git a/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.html b/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.html new file mode 100644 index 0000000..ff0085c --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.html @@ -0,0 +1,7 @@ + +Reasearch Staff
+ + diff --git a/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.json b/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.json new file mode 100644 index 0000000..ee72841 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.json @@ -0,0 +1,27 @@ +{ + "nid": 26, + "vid": 26, + "type": "page", + "language": "und", + "title": "Alex Kushleyev", + "slug": "alex-kushleyev", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599726, + "changed": 1344135537, + "url_aliases": [ + "AlexKushleyev" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "Reasearch Staff
\r\n", + "body_markdown": "Reasearch Staff\n", + "body_html_raw": "Reasearch Staff
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.md b/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.md new file mode 100644 index 0000000..0b9c018 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0026-alex-kushleyev.md @@ -0,0 +1,3 @@ +# Alex Kushleyev + +Reasearch Staff diff --git a/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.html b/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.html new file mode 100644 index 0000000..e3f2af8 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.html @@ -0,0 +1,7 @@ + +Summer Intern
+ + diff --git a/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.json b/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.json new file mode 100644 index 0000000..5baed09 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.json @@ -0,0 +1,27 @@ +{ + "nid": 27, + "vid": 27, + "type": "page", + "language": "und", + "title": "Harsh Pandey", + "slug": "harsh-pandey", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599759, + "changed": 1344135614, + "url_aliases": [ + "HarshPandey" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "Summer Intern
\r\n", + "body_markdown": "Summer Intern\n", + "body_html_raw": "Summer Intern
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.md b/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.md new file mode 100644 index 0000000..4a1a5aa --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0027-harsh-pandey.md @@ -0,0 +1,3 @@ +# Harsh Pandey + +Summer Intern diff --git a/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.html b/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.html new file mode 100644 index 0000000..5b8d0d3 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.html @@ -0,0 +1,7 @@ + +Summer Intern
+ + diff --git a/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.json b/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.json new file mode 100644 index 0000000..8110d39 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.json @@ -0,0 +1,27 @@ +{ + "nid": 28, + "vid": 28, + "type": "page", + "language": "und", + "title": "Kavan McEachern", + "slug": "kavan-mceachern", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599780, + "changed": 1344135621, + "url_aliases": [ + "KavanMcEachern" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "Summer Intern
\r\n", + "body_markdown": "Summer Intern\n", + "body_html_raw": "Summer Intern
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.md b/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.md new file mode 100644 index 0000000..503dbda --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0028-kavan-mceachern.md @@ -0,0 +1,3 @@ +# Kavan McEachern + +Summer Intern diff --git a/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.html b/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.html new file mode 100644 index 0000000..31d9e20 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.html @@ -0,0 +1,7 @@ + +Summer Intern 2012
+ + diff --git a/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.json b/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.json new file mode 100644 index 0000000..67100cb --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.json @@ -0,0 +1,27 @@ +{ + "nid": 29, + "vid": 29, + "type": "page", + "language": "und", + "title": "Matthew Mac Allister", + "slug": "matthew-mac-allister", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1341599803, + "changed": 1370637730, + "url_aliases": [ + "MatthewMacAllister" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "Summer Intern 2012
\r\n", + "body_markdown": "Summer Intern 2012\n", + "body_html_raw": "Summer Intern 2012
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.md b/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.md new file mode 100644 index 0000000..f6b96dd --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0029-matthew-mac-allister.md @@ -0,0 +1,3 @@ +# Matthew Mac Allister + +Summer Intern 2012 diff --git a/static/archive/legacy-drupal/content/pages/0030-contact.html b/static/archive/legacy-drupal/content/pages/0030-contact.html new file mode 100644 index 0000000..5c3c610 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0030-contact.html @@ -0,0 +1,22 @@ + +Physical Address:
+ 1612 Newell Simon Hall
+ Carnegie Mellon University
+ Pittsburgh, PA 15217
+
+ Mailing Address:
+ Maxim Likhachev
+ Carnegie Mellon University - Robotics Institute
+ 5000 Forbes Ave
+ Pittsburgh, PA, 15217
Email any comments to us at: a*************h@gmail.com
+ + + diff --git a/static/archive/legacy-drupal/content/pages/0030-contact.json b/static/archive/legacy-drupal/content/pages/0030-contact.json new file mode 100644 index 0000000..257fc9b --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0030-contact.json @@ -0,0 +1,27 @@ +{ + "nid": 30, + "vid": 30, + "type": "page", + "language": "und", + "title": "Contact", + "slug": "contact", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 1, + "comment": 1, + "created": 1341860373, + "changed": 1407243685, + "url_aliases": [ + "Contact" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "Physical Address:
\r\n\t1612 Newell Simon Hall
\r\n\tCarnegie Mellon University
\r\n\tPittsburgh, PA 15217
\r\n\t
\r\n\tMailing Address:
\r\n\tMaxim Likhachev
\r\n\tCarnegie Mellon University - Robotics Institute
\r\n\t5000 Forbes Ave
\r\n\tPittsburgh, PA, 15217
Email any comments to us at: a*************h@gmail.com
\r\n\r\n", + "body_markdown": "Physical Address:\n 1612 Newell Simon Hall\n Carnegie Mellon University\n Pittsburgh, PA 15217\n\n Mailing Address:\n Maxim Likhachev\n Carnegie Mellon University - Robotics Institute\n 5000 Forbes Ave\n Pittsburgh, PA, 15217\n\n To get updates and announcements, please join the* sbpl-users* mailing list by signing up [here](https://groups.google.com/forum/#!forum/sbpl-users).\n\nEmail any comments to us at: a*************h@gmail.com\n", + "body_html_raw": "Physical Address:
\r\n\t1612 Newell Simon Hall
\r\n\tCarnegie Mellon University
\r\n\tPittsburgh, PA 15217
\r\n\t
\r\n\tMailing Address:
\r\n\tMaxim Likhachev
\r\n\tCarnegie Mellon University - Robotics Institute
\r\n\t5000 Forbes Ave
\r\n\tPittsburgh, PA, 15217
Email any comments to us at: a*************h@gmail.com
\r\n\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0030-contact.md b/static/archive/legacy-drupal/content/pages/0030-contact.md new file mode 100644 index 0000000..498e3c0 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0030-contact.md @@ -0,0 +1,16 @@ +# Contact + +Physical Address: + 1612 Newell Simon Hall + Carnegie Mellon University + Pittsburgh, PA 15217 + + Mailing Address: + Maxim Likhachev + Carnegie Mellon University - Robotics Institute + 5000 Forbes Ave + Pittsburgh, PA, 15217 + + To get updates and announcements, please join the* sbpl-users* mailing list by signing up [here](https://groups.google.com/forum/#!forum/sbpl-users). + +Email any comments to us at: a*************h@gmail.com diff --git a/static/archive/legacy-drupal/content/pages/0031-login.html b/static/archive/legacy-drupal/content/pages/0031-login.html new file mode 100644 index 0000000..b847380 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0031-login.html @@ -0,0 +1,6 @@ + +For additional help running our software please see the tutorials page.
+
+ + Projects+ |
+
+ + Description+ |
+
+ + Software+ |
+
+ + Documentation+ |
+
|
+ SBPL + |
+
+ no dependencies! + |
+
+ Repo (git) + |
+ + ROS Wiki | +
|
+ SBPL MoveIt! Plugin + |
+
+ Generic Plugin for MoveIt! + |
+
+ SBPL Geometry Utilities (git) +Leatherman Utilities (git) +SBPL Manipulation Package (git) +Core Repository (git) + + |
+ + | +
|
+ 3D Navigation with Full Body Collision Checking + |
+
+ global planner for move_base, +PR2 Only ++ |
+
+ ROS Electric (git) + |
+ + ROS Wiki | +
|
+ 3D Navigation +(“Lattice Planner”) + |
+
+ global planner for move_base + |
+
+ ROS Diamondback, Electric (hg) +ROS Fuerte, Groovy (hg) + + + |
+ + + + | +
|
+ Single Arm Planning + |
+
+ can be used with arm_navigation stack (move_arm), +PR2 Only +Any Robot (experimental, Groovy only) + |
+
+ + + |
+ + + + + | +
|
+ Dual Arm Planning + |
+
+ PR2 Only + |
+
+ ROS Diamondback (svn) + |
+ + + | +
|
+ Navigation in Dynamic Environment + |
+
+ + |
+
+ ROS Diamondback (svn) + |
+ + + + + | +
| + Cart Planning | ++ | ++ svn | ++ ROS WIKI | +
| + Door Planning | ++ | ++ svn | ++ | +
| + Experience Graphs | ++ E-Graphs are built from experience (previously planned paths or user demonstrations). The planner is able to reuse parts of these prior paths to plan faster. | +
+ E-Graphs git (branch v3) +PR2 fully body planning integration git (branch v3) +Arm and navigation integration git (branch v3) + |
+
+
+ Full body planning documentation + + + + |
+
+
+
+ + Utilities+ |
+
+ + Description+ |
+
+ + Repository+ |
+
+ + Documentation+ |
+
|
+ PViz + |
+
+ PR2 Visualization Library - With one function call, you can visualize the PR2 in RViz with any joint configuration. The original meshes are drawn in as visualization markers. +Note: Currently, the robot is drawn without a head :) + |
+
+ ROS Electric (svn) +ROS Fuerte (git) + |
+ + none...but it's pretty simple to use | +
+ + diff --git a/static/archive/legacy-drupal/content/pages/0032-software.json b/static/archive/legacy-drupal/content/pages/0032-software.json new file mode 100644 index 0000000..ef24b30 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0032-software.json @@ -0,0 +1,27 @@ +{ + "nid": 32, + "vid": 32, + "type": "page", + "language": "und", + "title": "Software", + "slug": "software", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 1, + "comment": 1, + "created": 1341862175, + "changed": 1452290132, + "url_aliases": [ + "Software" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "
For additional help running our software please see the tutorials page.
\r\n\r\n \r\n Projects\r\n | \r\n \r\n \r\n Description\r\n | \r\n \r\n \r\n Software\r\n | \r\n \r\n \r\n Documentation\r\n | \r\n
| \r\n SBPL \r\n | \r\n \r\n no dependencies! \r\n | \r\n \r\n Repo (git) \r\n | \r\n \r\n ROS Wiki | \r\n
| \r\n SBPL MoveIt! Plugin \r\n | \r\n \r\n Generic Plugin for MoveIt! \r\n | \r\n \r\n SBPL Geometry Utilities (git) \r\nLeatherman Utilities (git) \r\nSBPL Manipulation Package (git) \r\nCore Repository (git) \r\n \r\n | \r\n \r\n | \r\n
| \r\n 3D Navigation with Full Body Collision Checking \r\n | \r\n \r\n global planner for move_base, \r\nPR2 Only \r\n\r\n | \r\n \r\n ROS Electric (git) \r\n | \r\n \r\n ROS Wiki | \r\n
| \r\n 3D Navigation \r\n(“Lattice Planner”) \r\n | \r\n \r\n global planner for move_base \r\n | \r\n \r\n ROS Diamondback, Electric (hg) \r\nROS Fuerte, Groovy (hg) \r\n \r\n \r\n | \r\n \r\n \r\n \r\n | \r\n
| \r\n Single Arm Planning \r\n | \r\n \r\n can be used with arm_navigation stack (move_arm), \r\nPR2 Only \r\nAny Robot (experimental, Groovy only) \r\n | \r\n \r\n \r\n \r\n | \r\n \r\n \r\n \r\n \r\n | \r\n
| \r\n Dual Arm Planning \r\n | \r\n \r\n PR2 Only \r\n | \r\n \r\n ROS Diamondback (svn) \r\n | \r\n \r\n \r\n | \r\n
| \r\n Navigation in Dynamic Environment \r\n | \r\n \r\n \r\n | \r\n \r\n ROS Diamondback (svn) \r\n | \r\n \r\n \r\n \r\n \r\n | \r\n
| \r\n Cart Planning | \r\n\r\n | \r\n\r\n svn | \r\n\r\n ROS WIKI | \r\n
| \r\n Door Planning | \r\n\r\n | \r\n\r\n svn | \r\n\r\n | \r\n
| \r\n Experience Graphs | \r\n\r\n E-Graphs are built from experience (previously planned paths or user demonstrations). The planner is able to reuse parts of these prior paths to plan faster. | \r\n\r\n E-Graphs git (branch v3) \r\nPR2 fully body planning integration git (branch v3) \r\nArm and navigation integration git (branch v3) \r\n | \r\n \r\n \r\n Full body planning documentation \r\n \r\n \r\n \r\n | \r\n
\r\n
\r\n
\r\n \r\n Utilities\r\n | \r\n \r\n \r\n Description\r\n | \r\n \r\n \r\n Repository\r\n | \r\n \r\n \r\n Documentation\r\n | \r\n
| \r\n PViz \r\n | \r\n \r\n PR2 Visualization Library - With one function call, you can visualize the PR2 in RViz with any joint configuration. The original meshes are drawn in as visualization markers. \r\nNote: Currently, the robot is drawn without a head :) \r\n | \r\n \r\n ROS Electric (svn) \r\nROS Fuerte (git) \r\n | \r\n \r\n none...but it's pretty simple to use | \r\n
\r\n", + "body_markdown": "For additional help running our software please see the [tutorials](http://sbpl.net/node/45) page.\n\n
\r\n \r\n Projects\r\n | \r\n \r\n \r\n Description\r\n | \r\n \r\n \r\n Software\r\n | \r\n \r\n \r\n Documentation\r\n | \r\n
| \r\n SBPL \r\n | \r\n \r\n no dependencies! \r\n | \r\n \r\n Repo (git) \r\n | \r\n \r\n ROS Wiki | \r\n
| \r\n SBPL MoveIt! Plugin \r\n | \r\n \r\n Generic Plugin for MoveIt! \r\n | \r\n \r\n SBPL Geometry Utilities (git) \r\nLeatherman Utilities (git) \r\nSBPL Manipulation Package (git) \r\nCore Repository (git) \r\n \r\n | \r\n \r\n | \r\n
| \r\n 3D Navigation with Full Body Collision Checking \r\n | \r\n \r\n global planner for move_base, \r\nPR2 Only \r\n\r\n | \r\n \r\n ROS Electric (git) \r\n | \r\n \r\n ROS Wiki | \r\n
| \r\n 3D Navigation \r\n(“Lattice Planner”) \r\n | \r\n \r\n global planner for move_base \r\n | \r\n \r\n ROS Diamondback, Electric (hg) \r\nROS Fuerte, Groovy (hg) \r\n \r\n \r\n | \r\n \r\n \r\n \r\n | \r\n
| \r\n Single Arm Planning \r\n | \r\n \r\n can be used with arm_navigation stack (move_arm), \r\nPR2 Only \r\nAny Robot (experimental, Groovy only) \r\n | \r\n \r\n \r\n \r\n | \r\n \r\n \r\n \r\n \r\n | \r\n
| \r\n Dual Arm Planning \r\n | \r\n \r\n PR2 Only \r\n | \r\n \r\n ROS Diamondback (svn) \r\n | \r\n \r\n \r\n | \r\n
| \r\n Navigation in Dynamic Environment \r\n | \r\n \r\n \r\n | \r\n \r\n ROS Diamondback (svn) \r\n | \r\n \r\n \r\n \r\n \r\n | \r\n
| \r\n Cart Planning | \r\n\r\n | \r\n\r\n svn | \r\n\r\n ROS WIKI | \r\n
| \r\n Door Planning | \r\n\r\n | \r\n\r\n svn | \r\n\r\n | \r\n
| \r\n Experience Graphs | \r\n\r\n E-Graphs are built from experience (previously planned paths or user demonstrations). The planner is able to reuse parts of these prior paths to plan faster. | \r\n\r\n E-Graphs git (branch v3) \r\nPR2 fully body planning integration git (branch v3) \r\nArm and navigation integration git (branch v3) \r\n | \r\n \r\n \r\n Full body planning documentation \r\n \r\n \r\n \r\n | \r\n
\r\n \r\n Utilities\r\n | \r\n \r\n \r\n Description\r\n | \r\n \r\n \r\n Repository\r\n | \r\n \r\n \r\n Documentation\r\n | \r\n
| \r\n PViz \r\n | \r\n \r\n PR2 Visualization Library - With one function call, you can visualize the PR2 in RViz with any joint configuration. The original meshes are drawn in as visualization markers. \r\nNote: Currently, the robot is drawn without a head :) \r\n | \r\n \r\n ROS Electric (svn) \r\nROS Fuerte (git) \r\n | \r\n \r\n none...but it's pretty simple to use | \r\n
For additional help running our software please see the tutorials page.
\r\n\r\n \r\n Projects\r\n | \r\n \r\n \r\n Description\r\n | \r\n \r\n \r\n Software\r\n | \r\n \r\n \r\n Documentation\r\n | \r\n
| \r\n SBPL \r\n | \r\n \r\n no dependencies! \r\n | \r\n \r\n Repo (git) \r\n | \r\n \r\n ROS Wiki | \r\n
| \r\n SBPL MoveIt! Plugin \r\n | \r\n \r\n Generic Plugin for MoveIt! \r\n | \r\n \r\n SBPL Geometry Utilities (git) \r\nLeatherman Utilities (git) \r\nSBPL Manipulation Package (git) \r\nCore Repository (git) \r\n \r\n | \r\n \r\n | \r\n
| \r\n 3D Navigation with Full Body Collision Checking \r\n | \r\n \r\n global planner for move_base, \r\nPR2 Only \r\n\r\n | \r\n \r\n ROS Electric (git) \r\n | \r\n \r\n ROS Wiki | \r\n
| \r\n 3D Navigation \r\n(“Lattice Planner”) \r\n | \r\n \r\n global planner for move_base \r\n | \r\n \r\n ROS Diamondback, Electric (hg) \r\nROS Fuerte, Groovy (hg) \r\n \r\n \r\n | \r\n \r\n \r\n \r\n | \r\n
| \r\n Single Arm Planning \r\n | \r\n \r\n can be used with arm_navigation stack (move_arm), \r\nPR2 Only \r\nAny Robot (experimental, Groovy only) \r\n | \r\n \r\n \r\n \r\n | \r\n \r\n \r\n \r\n \r\n | \r\n
| \r\n Dual Arm Planning \r\n | \r\n \r\n PR2 Only \r\n | \r\n \r\n ROS Diamondback (svn) \r\n | \r\n \r\n \r\n | \r\n
| \r\n Navigation in Dynamic Environment \r\n | \r\n \r\n \r\n | \r\n \r\n ROS Diamondback (svn) \r\n | \r\n \r\n \r\n \r\n \r\n | \r\n
| \r\n Cart Planning | \r\n\r\n | \r\n\r\n svn | \r\n\r\n ROS WIKI | \r\n
| \r\n Door Planning | \r\n\r\n | \r\n\r\n svn | \r\n\r\n | \r\n
| \r\n Experience Graphs | \r\n\r\n E-Graphs are built from experience (previously planned paths or user demonstrations). The planner is able to reuse parts of these prior paths to plan faster. | \r\n\r\n E-Graphs git (branch v3) \r\nPR2 fully body planning integration git (branch v3) \r\nArm and navigation integration git (branch v3) \r\n | \r\n \r\n \r\n Full body planning documentation \r\n \r\n \r\n \r\n | \r\n
\r\n
\r\n
\r\n \r\n Utilities\r\n | \r\n \r\n \r\n Description\r\n | \r\n \r\n \r\n Repository\r\n | \r\n \r\n \r\n Documentation\r\n | \r\n
| \r\n PViz \r\n | \r\n \r\n PR2 Visualization Library - With one function call, you can visualize the PR2 in RViz with any joint configuration. The original meshes are drawn in as visualization markers. \r\nNote: Currently, the robot is drawn without a head :) \r\n | \r\n \r\n ROS Electric (svn) \r\nROS Fuerte (git) \r\n | \r\n \r\n none...but it's pretty simple to use | \r\n
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0032-software.md b/static/archive/legacy-drupal/content/pages/0032-software.md new file mode 100644 index 0000000..fbca60e --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0032-software.md @@ -0,0 +1,222 @@ +# Software + +For additional help running our software please see the [tutorials](http://sbpl.net/node/45) page. + +
+ + Projects+ |
+
+ + Description+ |
+
+ + Software+ |
+
+ + Documentation+ |
+
|
+ SBPL + |
+
+ no dependencies! + |
+
+ Repo (git) + |
+ + ROS Wiki | +
|
+ SBPL MoveIt! Plugin + |
+
+ Generic Plugin for MoveIt! + |
+
+ SBPL Geometry Utilities (git) +Leatherman Utilities (git) +SBPL Manipulation Package (git) +Core Repository (git) + + |
+ + | +
|
+ 3D Navigation with Full Body Collision Checking + |
+
+ global planner for move_base, +PR2 Only ++ |
+
+ ROS Electric (git) + |
+ + ROS Wiki | +
|
+ 3D Navigation +(“Lattice Planner”) + |
+
+ global planner for move_base + |
+
+ ROS Diamondback, Electric (hg) +ROS Fuerte, Groovy (hg) + + + |
+ + + + | +
|
+ Single Arm Planning + |
+
+ can be used with arm_navigation stack (move_arm), +PR2 Only +Any Robot (experimental, Groovy only) + |
+
+ + + |
+ + + + + | +
|
+ Dual Arm Planning + |
+
+ PR2 Only + |
+
+ ROS Diamondback (svn) + |
+ + + | +
|
+ Navigation in Dynamic Environment + |
+
+ + |
+
+ ROS Diamondback (svn) + |
+ + + + + | +
| + Cart Planning | ++ | ++ svn | ++ ROS WIKI | +
| + Door Planning | ++ | ++ svn | ++ | +
| + Experience Graphs | ++ E-Graphs are built from experience (previously planned paths or user demonstrations). The planner is able to reuse parts of these prior paths to plan faster. | +
+ E-Graphs git (branch v3) +PR2 fully body planning integration git (branch v3) +Arm and navigation integration git (branch v3) + |
+
+
+ Full body planning documentation + + + + |
+
+ + Utilities+ |
+
+ + Description+ |
+
+ + Repository+ |
+
+ + Documentation+ |
+
|
+ PViz + |
+
+ PR2 Visualization Library - With one function call, you can visualize the PR2 in RViz with any joint configuration. The original meshes are drawn in as visualization markers. +Note: Currently, the robot is drawn without a head :) + |
+
+ ROS Electric (svn) +ROS Fuerte (git) + |
+ + none...but it's pretty simple to use | +
Summer Intern
+ + diff --git a/static/archive/legacy-drupal/content/pages/0039-eduardo-barrera.json b/static/archive/legacy-drupal/content/pages/0039-eduardo-barrera.json new file mode 100644 index 0000000..2c954bb --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0039-eduardo-barrera.json @@ -0,0 +1,27 @@ +{ + "nid": 39, + "vid": 39, + "type": "page", + "language": "und", + "title": "Eduardo Barrera", + "slug": "eduardo-barrera", + "uid": 28, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1344136653, + "changed": 1344184701, + "url_aliases": [ + "EduardoBarrera" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "Summer Intern
\r\n", + "body_markdown": "Summer Intern\n", + "body_html_raw": "Summer Intern
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0039-eduardo-barrera.md b/static/archive/legacy-drupal/content/pages/0039-eduardo-barrera.md new file mode 100644 index 0000000..480f358 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0039-eduardo-barrera.md @@ -0,0 +1,3 @@ +# Eduardo Barrera + +Summer Intern diff --git a/static/archive/legacy-drupal/content/pages/0042-old-software.html b/static/archive/legacy-drupal/content/pages/0042-old-software.html new file mode 100644 index 0000000..d7afb6c --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0042-old-software.html @@ -0,0 +1,60 @@ + +sandip needs to add text here
+ + diff --git a/static/archive/legacy-drupal/content/pages/0043-sandip-aine.json b/static/archive/legacy-drupal/content/pages/0043-sandip-aine.json new file mode 100644 index 0000000..249d9ad --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0043-sandip-aine.json @@ -0,0 +1,27 @@ +{ + "nid": 43, + "vid": 43, + "type": "page", + "language": "und", + "title": "Sandip Aine", + "slug": "sandip-aine", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1344546132, + "changed": 1344546132, + "url_aliases": [ + "SandipAine" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "sandip needs to add text here
\r\n", + "body_markdown": "sandip needs to add text here\n", + "body_html_raw": "sandip needs to add text here
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0043-sandip-aine.md b/static/archive/legacy-drupal/content/pages/0043-sandip-aine.md new file mode 100644 index 0000000..fb160d2 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0043-sandip-aine.md @@ -0,0 +1,3 @@ +# Sandip Aine + +sandip needs to add text here diff --git a/static/archive/legacy-drupal/content/pages/0044-calendar.html b/static/archive/legacy-drupal/content/pages/0044-calendar.html new file mode 100644 index 0000000..5a5203d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0044-calendar.html @@ -0,0 +1,7 @@ + +Learn the basic theory behind graph search and SBPL.
+This has a brief overview of how SBPL is organized.
+This has example code for planning with a 2d footprint of a robot in X, Y, and theta dimensions.
+This builds on the previous tutorial to handle exploring an unknown environment.
+An introduction to how kinematic constraints are dealt with in SBPL.
+How to use the Matlab scripts in SBPL to generate custom motion primitives.
+Learn the basic theory behind graph search and SBPL.
\r\nThis has a brief overview of how SBPL is organized.
\r\nThis has example code for planning with a 2d footprint of a robot in X, Y, and theta dimensions.
\r\nThis builds on the previous tutorial to handle exploring an unknown environment.
\r\nAn introduction to how kinematic constraints are dealt with in SBPL.
\r\nHow to use the Matlab scripts in SBPL to generate custom motion primitives.
\r\nLearn the basic theory behind graph search and SBPL.
\r\nThis has a brief overview of how SBPL is organized.
\r\nThis has example code for planning with a 2d footprint of a robot in X, Y, and theta dimensions.
\r\nThis builds on the previous tutorial to handle exploring an unknown environment.
\r\nAn introduction to how kinematic constraints are dealt with in SBPL.
\r\nHow to use the Matlab scripts in SBPL to generate custom motion primitives.
\r\nIn the previous article, we showed how to plan on a static map. In the context of robot navigation, we don't have the luxury of a static map. Instead, the map of the environment updates as the robot moves towards its goal. In this article, we'll show a few code snippets on how to change the previous example to react to an updating environment with two different kinds of planners: ARA* (anytime planning) and AD* (incremental planning).
+In the sbpl/src/test/main.cpp file, there is a section of code in the planandnavigatexythetalat function that simulates an updating environment. It's not necessary to understand this code - it is simply a framework for generating an unknown environment. The important portions of this code are the ones that inform the planners about the changed environment.
+In the example, simulating the environment is rather contrived - an empty environment is create and uses the real map as its "sensors" (let's call this the sim_environment). Basically, the true values of the map are slowly fed into this duplicated environment.
+ +In the snippet above, we look at the newly sensed cells and determine which ones have changed. Since sim_environment has empty cells for areas it doesn't know about, there will be a difference in the costs for a particular cell once it has "sensed" new information about it. In the loop, we inform the environment to update its map using the UpdateCost function. We also push all cells that have been changed into the changedcellsV vector.
+Once the vector is built, we inform the planner about the cells that have been changed. For the ARA* planner, we use costs_changed() to inform the planner that the environment has updated.
+For the AD* planner, we have to do a little more work in order to update the internal search tree. AD* needs more information than just the changed cells to update. To do this, we feed the changed cells into GetPredsofChangedEdges. The output of this is then fed into update_preds_of_changededges.
+With those steps completed, the planner will now compute paths with the updated environment.
+ + diff --git a/static/archive/legacy-drupal/content/pages/0046-navigation-with-sbpl-in-x-y-theta.json b/static/archive/legacy-drupal/content/pages/0046-navigation-with-sbpl-in-x-y-theta.json new file mode 100644 index 0000000..ba94c09 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0046-navigation-with-sbpl-in-x-y-theta.json @@ -0,0 +1,25 @@ +{ + "nid": 46, + "vid": 46, + "type": "page", + "language": "und", + "title": "Navigation with SBPL (in X, Y, Theta)", + "slug": "navigation-with-sbpl-in-x-y-theta", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1367353102, + "changed": 1373331954, + "url_aliases": [], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "In the previous article, we showed how to plan on a static map. In the context of robot navigation, we don't have the luxury of a static map. Instead, the map of the environment updates as the robot moves towards its goal. In this article, we'll show a few code snippets on how to change the previous example to react to an updating environment with two different kinds of planners: ARA* (anytime planning) and AD* (incremental planning).
\r\nIn the sbpl/src/test/main.cpp file, there is a section of code in the planandnavigatexythetalat function that simulates an updating environment. It's not necessary to understand this code - it is simply a framework for generating an unknown environment. The important portions of this code are the ones that inform the planners about the changed environment.
\r\nIn the example, simulating the environment is rather contrived - an empty environment is create and uses the real map as its "sensors" (let's call this the sim_environment). Basically, the true values of the map are slowly fed into this duplicated environment.
\r\n\r\nIn the snippet above, we look at the newly sensed cells and determine which ones have changed. Since sim_environment has empty cells for areas it doesn't know about, there will be a difference in the costs for a particular cell once it has "sensed" new information about it. In the loop, we inform the environment to update its map using the UpdateCost function. We also push all cells that have been changed into the changedcellsV vector.
\r\nOnce the vector is built, we inform the planner about the cells that have been changed. For the ARA* planner, we use costs_changed() to inform the planner that the environment has updated.
\r\nFor the AD* planner, we have to do a little more work in order to update the internal search tree. AD* needs more information than just the changed cells to update. To do this, we feed the changed cells into GetPredsofChangedEdges. The output of this is then fed into update_preds_of_changededges.
\r\nWith those steps completed, the planner will now compute paths with the updated environment.
\r\n", + "body_markdown": "In the [previous article](http://sbpl.net/node/51), we showed how to plan on a static map. In the context of robot navigation, we don't have the luxury of a static map. Instead, the map of the environment updates as the robot moves towards its goal. In this article, we'll show a few code snippets on how to change the previous example to react to an updating environment with two different kinds of planners: ARA* (anytime planning) and AD* (incremental planning).\n\nIn the sbpl/src/test/main.cpp file, there is a section of code in the planandnavigatexythetalat function that simulates an updating environment. It's not necessary to understand this code - it is simply a framework for generating an unknown environment. The important portions of this code are the ones that inform the planners about the changed environment.\n\nIn the example, simulating the environment is rather contrived - an empty environment is create and uses the real map as its \"sensors\" (let's call this the sim_environment). Basically, the true values of the map are slowly fed into this duplicated environment.\n\nIn the snippet above, we look at the newly sensed cells and determine which ones have changed. Since sim_environment has empty cells for areas it doesn't know about, there will be a difference in the costs for a particular cell once it has \"sensed\" new information about it. In the loop, we inform the environment to update its map using the *UpdateCost* function. We also push all cells that have been changed into the *changedcellsV* vector.\n\nOnce the vector is built, we inform the planner about the cells that have been changed. For the ARA* planner, we use *costs_changed()* to inform the planner that the environment has updated.\n\nFor the AD* planner, we have to do a little more work in order to update the internal search tree. AD* needs more information than just the changed cells to update. To do this, we feed the changed cells into *GetPredsofChangedEdges*. The output of this is then fed into *update_preds_of_changededges*.\n\nWith those steps completed, the planner will now compute paths with the updated environment.\n", + "body_html_raw": "In the previous article, we showed how to plan on a static map. In the context of robot navigation, we don't have the luxury of a static map. Instead, the map of the environment updates as the robot moves towards its goal. In this article, we'll show a few code snippets on how to change the previous example to react to an updating environment with two different kinds of planners: ARA* (anytime planning) and AD* (incremental planning).
\r\nIn the sbpl/src/test/main.cpp file, there is a section of code in the planandnavigatexythetalat function that simulates an updating environment. It's not necessary to understand this code - it is simply a framework for generating an unknown environment. The important portions of this code are the ones that inform the planners about the changed environment.
\r\nIn the example, simulating the environment is rather contrived - an empty environment is create and uses the real map as its "sensors" (let's call this the sim_environment). Basically, the true values of the map are slowly fed into this duplicated environment.
\r\n\r\nIn the snippet above, we look at the newly sensed cells and determine which ones have changed. Since sim_environment has empty cells for areas it doesn't know about, there will be a difference in the costs for a particular cell once it has "sensed" new information about it. In the loop, we inform the environment to update its map using the UpdateCost function. We also push all cells that have been changed into the changedcellsV vector.
\r\nOnce the vector is built, we inform the planner about the cells that have been changed. For the ARA* planner, we use costs_changed() to inform the planner that the environment has updated.
\r\nFor the AD* planner, we have to do a little more work in order to update the internal search tree. AD* needs more information than just the changed cells to update. To do this, we feed the changed cells into GetPredsofChangedEdges. The output of this is then fed into update_preds_of_changededges.
\r\nWith those steps completed, the planner will now compute paths with the updated environment.
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0046-navigation-with-sbpl-in-x-y-theta.md b/static/archive/legacy-drupal/content/pages/0046-navigation-with-sbpl-in-x-y-theta.md new file mode 100644 index 0000000..d551632 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0046-navigation-with-sbpl-in-x-y-theta.md @@ -0,0 +1,15 @@ +# Navigation with SBPL (in X, Y, Theta) + +In the [previous article](http://sbpl.net/node/51), we showed how to plan on a static map. In the context of robot navigation, we don't have the luxury of a static map. Instead, the map of the environment updates as the robot moves towards its goal. In this article, we'll show a few code snippets on how to change the previous example to react to an updating environment with two different kinds of planners: ARA* (anytime planning) and AD* (incremental planning). + +In the sbpl/src/test/main.cpp file, there is a section of code in the planandnavigatexythetalat function that simulates an updating environment. It's not necessary to understand this code - it is simply a framework for generating an unknown environment. The important portions of this code are the ones that inform the planners about the changed environment. + +In the example, simulating the environment is rather contrived - an empty environment is create and uses the real map as its "sensors" (let's call this the sim_environment). Basically, the true values of the map are slowly fed into this duplicated environment. + +In the snippet above, we look at the newly sensed cells and determine which ones have changed. Since sim_environment has empty cells for areas it doesn't know about, there will be a difference in the costs for a particular cell once it has "sensed" new information about it. In the loop, we inform the environment to update its map using the *UpdateCost* function. We also push all cells that have been changed into the *changedcellsV* vector. + +Once the vector is built, we inform the planner about the cells that have been changed. For the ARA* planner, we use *costs_changed()* to inform the planner that the environment has updated. + +For the AD* planner, we have to do a little more work in order to update the internal search tree. AD* needs more information than just the changed cells to update. To do this, we feed the changed cells into *GetPredsofChangedEdges*. The output of this is then fed into *update_preds_of_changededges*. + +With those steps completed, the planner will now compute paths with the updated environment. diff --git a/static/archive/legacy-drupal/content/pages/0047-sbpl-overview.html b/static/archive/legacy-drupal/content/pages/0047-sbpl-overview.html new file mode 100644 index 0000000..1541c53 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0047-sbpl-overview.html @@ -0,0 +1,32 @@ + +This tutorial will describe how SBPL is set up. For background information, click here.
+Environments
+As described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. Unless you're fiddling with the actual graph search algorithm, the environment object will be the thing you interact most with.
+In a nutshell, the environment handles domain specific details and translates them into a generic form for the planner to handle. For example, the environment handles the translation between the (x, y, theta) position of a robot into a graph composed of generic state IDs. The planner then solves the graph without having to know about the domain. (This doesn't actually happen in one step - the graph is generated on demand by the planner. As a result, the planner often calls the environment object to retrieve information on demand).
+The environment also implements the heuristic computation. This is domain dependent, since the heuristic for guiding a robotic arm to an object will be different from navigating a car close to its goal.
+There already exists many environments and planners in SBPL, but they might not cover a custom scenario. In this case, you will have to implement your own environment (a very involved topic that might be covered in the future).
+These can all be found in sbpl/src/discrete_space_information.
+Other environments that have successfully been implemented (but not included in SBPL):
+Planners
+There are a number of planners that are available in sbpl/src/planners
+This tutorial will describe how SBPL is set up. For background information, click here.
\r\nEnvironments
\r\nAs described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. Unless you're fiddling with the actual graph search algorithm, the environment object will be the thing you interact most with.
\r\nIn a nutshell, the environment handles domain specific details and translates them into a generic form for the planner to handle. For example, the environment handles the translation between the (x, y, theta) position of a robot into a graph composed of generic state IDs. The planner then solves the graph without having to know about the domain. (This doesn't actually happen in one step - the graph is generated on demand by the planner. As a result, the planner often calls the environment object to retrieve information on demand).
\r\nThe environment also implements the heuristic computation. This is domain dependent, since the heuristic for guiding a robotic arm to an object will be different from navigating a car close to its goal.
\r\nThere already exists many environments and planners in SBPL, but they might not cover a custom scenario. In this case, you will have to implement your own environment (a very involved topic that might be covered in the future).
\r\nThese can all be found in sbpl/src/discrete_space_information.
\r\nOther environments that have successfully been implemented (but not included in SBPL):
\r\nPlanners
\r\nThere are a number of planners that are available in sbpl/src/planners
\r\nThis tutorial will describe how SBPL is set up. For background information, click here.
\r\nEnvironments
\r\nAs described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. Unless you're fiddling with the actual graph search algorithm, the environment object will be the thing you interact most with.
\r\nIn a nutshell, the environment handles domain specific details and translates them into a generic form for the planner to handle. For example, the environment handles the translation between the (x, y, theta) position of a robot into a graph composed of generic state IDs. The planner then solves the graph without having to know about the domain. (This doesn't actually happen in one step - the graph is generated on demand by the planner. As a result, the planner often calls the environment object to retrieve information on demand).
\r\nThe environment also implements the heuristic computation. This is domain dependent, since the heuristic for guiding a robotic arm to an object will be different from navigating a car close to its goal.
\r\nThere already exists many environments and planners in SBPL, but they might not cover a custom scenario. In this case, you will have to implement your own environment (a very involved topic that might be covered in the future).
\r\nThese can all be found in sbpl/src/discrete_space_information.
\r\nOther environments that have successfully been implemented (but not included in SBPL):
\r\nPlanners
\r\nThere are a number of planners that are available in sbpl/src/planners
\r\nIn the last article, we showed how a graph can represent states of the robot. We defined a trajectory or path as a series of adjacent states in a graph. But adjacent states don't reflect the kinodynamic constraints of the robot. For example, let's say a car is facing north at x, y location (2,2). Our path tells us to move from (2,2) to (1,2). While the states are adjacent, our car cannot move sideways to achieve this transition. We could improve this by introducing a theta component, making the state space (x, y, theta). This doesn't entirely fix the problem because the resulting paths might not be smooth (imagine if the theta changed every step of the path). Instead, SBPL uses lattice-based graphs that are constructed using motion primitives. Motion primitives are pre-computed motions that the robot can take.
+
By superimposing this on the graph at the robot's position, our adjacent states (or what are usually called successors) are not necessarily spatially adjacent. Instead, they represent what the robot can smoothly transition to. The image below shows what this might look like for a robotic car - the motion primitives follow typical car-like motions. Valid successors of a given state are states that can be reached with these motions while not colliding with anything else.
+
Motion primitives allow us to encode the kinematic constraints of the robot into any environment that the robot is planning in. They also allow for different costs associated with each motion - for example, if we want to avoid reversing the car, we might assign a high cost to that particular motion primitive. SBPL has Matlab tools to build motion primitives for different types of vehicles.
+Instructions for how to do this can be found here. For more information on lattice planning, see here.
+ + diff --git a/static/archive/legacy-drupal/content/pages/0048-kinematic-constraints-and-motion-primitives.json b/static/archive/legacy-drupal/content/pages/0048-kinematic-constraints-and-motion-primitives.json new file mode 100644 index 0000000..f825852 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0048-kinematic-constraints-and-motion-primitives.json @@ -0,0 +1,25 @@ +{ + "nid": 48, + "vid": 48, + "type": "page", + "language": "und", + "title": "Kinematic Constraints and Motion Primitives", + "slug": "kinematic-constraints-and-motion-primitives", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1367353663, + "changed": 1373332005, + "url_aliases": [], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "In the last article, we showed how a graph can represent states of the robot. We defined a trajectory or path as a series of adjacent states in a graph. But adjacent states don't reflect the kinodynamic constraints of the robot. For example, let's say a car is facing north at x, y location (2,2). Our path tells us to move from (2,2) to (1,2). While the states are adjacent, our car cannot move sideways to achieve this transition. We could improve this by introducing a theta component, making the state space (x, y, theta). This doesn't entirely fix the problem because the resulting paths might not be smooth (imagine if the theta changed every step of the path). Instead, SBPL uses lattice-based graphs that are constructed using motion primitives. Motion primitives are pre-computed motions that the robot can take.
\r\n![\"\"](\"../../media/images/tumblr_inline_mkp8yrkzjm1qz4rgp.png\")
By superimposing this on the graph at the robot's position, our adjacent states (or what are usually called successors) are not necessarily spatially adjacent. Instead, they represent what the robot can smoothly transition to. The image below shows what this might look like for a robotic car - the motion primitives follow typical car-like motions. Valid successors of a given state are states that can be reached with these motions while not colliding with anything else.
\r\n![\"\"](\"../../media/images/kin2.png\")
Motion primitives allow us to encode the kinematic constraints of the robot into any environment that the robot is planning in. They also allow for different costs associated with each motion - for example, if we want to avoid reversing the car, we might assign a high cost to that particular motion primitive. SBPL has Matlab tools to build motion primitives for different types of vehicles.
\r\nInstructions for how to do this can be found here. For more information on lattice planning, see here.
\r\n", + "body_markdown": "In the [last article](http://sbpl.net/node/50), we showed how a graph can represent states of the robot. We defined a trajectory or path as a series of adjacent states in a graph. But adjacent states don't reflect the kinodynamic constraints of the robot. For example, let's say a car is facing north at x, y location (2,2). Our path tells us to move from (2,2) to (1,2). While the states are adjacent, our car cannot move sideways to achieve this transition. We could improve this by introducing a theta component, making the state space (x, y, theta). This doesn't entirely fix the problem because the resulting paths might not be smooth (imagine if the theta changed every step of the path). Instead, SBPL uses lattice-based graphs that are constructed using motion primitives. Motion primitives are pre-computed motions that the robot can take.\n\n\n\nBy superimposing this on the graph at the robot's position, our adjacent states (or what are usually called successors) are not necessarily spatially adjacent. Instead, they represent what the robot can smoothly transition to. The image below shows what this might look like for a robotic car - the motion primitives follow typical car-like motions. Valid successors of a given state are states that can be reached with these motions while not colliding with anything else.\n\n\n\nMotion primitives allow us to encode the kinematic constraints of the robot into any environment that the robot is planning in. They also allow for different costs associated with each motion - for example, if we want to avoid reversing the car, we might assign a high cost to that particular motion primitive. SBPL has Matlab tools to build motion primitives for different types of vehicles.\n\nInstructions for how to do this can be found [here](http://sbpl.net/node/52). For more information on lattice planning, see [here](http://www.cs.cmu.edu/~maxim/files/planlongdynfeasmotions_rss08.pdf).\n", + "body_html_raw": "In the last article, we showed how a graph can represent states of the robot. We defined a trajectory or path as a series of adjacent states in a graph. But adjacent states don't reflect the kinodynamic constraints of the robot. For example, let's say a car is facing north at x, y location (2,2). Our path tells us to move from (2,2) to (1,2). While the states are adjacent, our car cannot move sideways to achieve this transition. We could improve this by introducing a theta component, making the state space (x, y, theta). This doesn't entirely fix the problem because the resulting paths might not be smooth (imagine if the theta changed every step of the path). Instead, SBPL uses lattice-based graphs that are constructed using motion primitives. Motion primitives are pre-computed motions that the robot can take.
\r\n![\"\"](\"/shared/Images/tumblr_inline_mkp8yrkzjm1qz4rgp.png\")
By superimposing this on the graph at the robot's position, our adjacent states (or what are usually called successors) are not necessarily spatially adjacent. Instead, they represent what the robot can smoothly transition to. The image below shows what this might look like for a robotic car - the motion primitives follow typical car-like motions. Valid successors of a given state are states that can be reached with these motions while not colliding with anything else.
\r\n![\"\"](\"/shared/Images/kin2.png\")
Motion primitives allow us to encode the kinematic constraints of the robot into any environment that the robot is planning in. They also allow for different costs associated with each motion - for example, if we want to avoid reversing the car, we might assign a high cost to that particular motion primitive. SBPL has Matlab tools to build motion primitives for different types of vehicles.
\r\nInstructions for how to do this can be found here. For more information on lattice planning, see here.
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0048-kinematic-constraints-and-motion-primitives.md b/static/archive/legacy-drupal/content/pages/0048-kinematic-constraints-and-motion-primitives.md new file mode 100644 index 0000000..7441e06 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0048-kinematic-constraints-and-motion-primitives.md @@ -0,0 +1,13 @@ +# Kinematic Constraints and Motion Primitives + +In the [last article](http://sbpl.net/node/50), we showed how a graph can represent states of the robot. We defined a trajectory or path as a series of adjacent states in a graph. But adjacent states don't reflect the kinodynamic constraints of the robot. For example, let's say a car is facing north at x, y location (2,2). Our path tells us to move from (2,2) to (1,2). While the states are adjacent, our car cannot move sideways to achieve this transition. We could improve this by introducing a theta component, making the state space (x, y, theta). This doesn't entirely fix the problem because the resulting paths might not be smooth (imagine if the theta changed every step of the path). Instead, SBPL uses lattice-based graphs that are constructed using motion primitives. Motion primitives are pre-computed motions that the robot can take. + + + +By superimposing this on the graph at the robot's position, our adjacent states (or what are usually called successors) are not necessarily spatially adjacent. Instead, they represent what the robot can smoothly transition to. The image below shows what this might look like for a robotic car - the motion primitives follow typical car-like motions. Valid successors of a given state are states that can be reached with these motions while not colliding with anything else. + + + +Motion primitives allow us to encode the kinematic constraints of the robot into any environment that the robot is planning in. They also allow for different costs associated with each motion - for example, if we want to avoid reversing the car, we might assign a high cost to that particular motion primitive. SBPL has Matlab tools to build motion primitives for different types of vehicles. + +Instructions for how to do this can be found [here](http://sbpl.net/node/52). For more information on lattice planning, see [here](http://www.cs.cmu.edu/~maxim/files/planlongdynfeasmotions_rss08.pdf). diff --git a/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.html b/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.html new file mode 100644 index 0000000..afbba90 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.html @@ -0,0 +1,48 @@ + +This article aims to give a very brief overview of the concepts behind SBPL. See this wiki article for an intro to motion planning.
++
Search-based Planning
++
Search-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. This is in contrast to sample-based planning methods, which is described very well in the OMPL primer. Search-based methods provides guarantees on path quality and are used in scenarios which demand low cost paths (e.g. robot navigation).
++
First we talk about how the environment of the problem is discretized, then we describe how planning is done.
++
Environments (or discrete representation of a planning problem)
++
In order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z position in the world. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of these states is defined as the state space.
++
The image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).
+
+The graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the Kinematic Constraints and Motion Primitives section for more details.)
++
Since the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.
++
State Validity and Collision Checking
++
One important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.
++
Looking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).
++
More constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.
++
Before moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.
++
Planners
++
Now that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.
++
This parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.
+
+
The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. Weighted A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.
++
With the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.
++
[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]
++
So what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.
+ + diff --git a/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.json b/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.json new file mode 100644 index 0000000..233ce2d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.json @@ -0,0 +1,25 @@ +{ + "nid": 49, + "vid": 49, + "type": "page", + "language": "und", + "title": "Primer to the Search-Based Planning Library (SBPL)", + "slug": "primer-to-the-search-based-planning-library-sbpl", + "uid": 1, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1367356916, + "changed": 1367357394, + "url_aliases": [], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "This article aims to give a very brief overview of the concepts behind SBPL. See this wiki article for an intro to motion planning.
\r\n\r\n
Search-based Planning
\r\n\r\n
Search-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. This is in contrast to sample-based planning methods, which is described very well in the OMPL primer. Search-based methods provides guarantees on path quality and are used in scenarios which demand low cost paths (e.g. robot navigation).
\r\n\r\n
First we talk about how the environment of the problem is discretized, then we describe how planning is done.
\r\n\r\n
Environments (or discrete representation of a planning problem)
\r\n\r\n
In order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z position in the world. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of these states is defined as the state space.
\r\n\r\n
The image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).
\r\n![\"A](\"../../media/images/primer1.png\")
\r\nThe graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the Kinematic Constraints and Motion Primitives section for more details.)
\r\n\r\n
Since the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.
\r\n\r\n
State Validity and Collision Checking
\r\n\r\n
One important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.
\r\n\r\n
Looking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).
\r\n\r\n
More constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.
\r\n\r\n
Before moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.
\r\n\r\n
Planners
\r\n\r\n
Now that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.
\r\n\r\n
This parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.
\r\n![\"image\"](\"http://upload.wikimedia.org/wikipedia/commons/2/23/Dijkstras_progress_animation.gif\")
![\"image\"](\"http://upload.wikimedia.org/wikipedia/commons/5/5d/Astar_progress_animation.gif\")
![\"image\"](\"http://upload.wikimedia.org/wikipedia/commons/8/85/Weighted_A_star_with_eps_5.gif\")
\r\n
The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. Weighted A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.
\r\n\r\n
With the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.
\r\n\r\n
[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]
\r\n\r\n
So what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.
\r\n", + "body_markdown": "This article aims to give a very brief overview of the concepts behind SBPL. See [this wiki article](http://en.wikipedia.org/wiki/Motion_planning) for an intro to motion planning.\n\n**Search-based Planning**\n\nSearch-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. This is in contrast to sample-based planning methods, which is described very well in the [OMPL primer](http://ompl.kavrakilab.org/OMPL_Primer.pdf). Search-based methods provides guarantees on path quality and are used in scenarios which demand low cost paths (e.g. robot navigation).\n\nFirst we talk about how the environment of the problem is discretized, then we describe how planning is done.\n\n**Environments (or discrete representation of a planning problem)**\n\nIn order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z position in the world. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of these states is defined as the state space.\n\nThe image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).\n\n \n\nThe graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the [Kinematic Constraints and Motion Primitives](http://victor.hwanger.com/post/47052754092/kinematic-constraints-and-motion-primitives) section for more details.)\n\nSince the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.\n\n**State Validity and Collision Checking**\n\nOne important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.\n\nLooking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).\n\nMore constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.\n\nBefore moving on to searching this graph, it's important to note that the translation between the \"real world\" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.\n\n**Planners**\n\nNow that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.\n\nThis parameter of \"good enough\" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.\n\n \n\nThe three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. Weighted A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.\n\nWith the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.\n\n[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]\n\nSo what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.\n", + "body_html_raw": "This article aims to give a very brief overview of the concepts behind SBPL. See this wiki article for an intro to motion planning.
\r\n\r\n
Search-based Planning
\r\n\r\n
Search-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. This is in contrast to sample-based planning methods, which is described very well in the OMPL primer. Search-based methods provides guarantees on path quality and are used in scenarios which demand low cost paths (e.g. robot navigation).
\r\n\r\n
First we talk about how the environment of the problem is discretized, then we describe how planning is done.
\r\n\r\n
Environments (or discrete representation of a planning problem)
\r\n\r\n
In order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z position in the world. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of these states is defined as the state space.
\r\n\r\n
The image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).
\r\n![\"A](\"/shared/Images/primer1.png\")
\r\nThe graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the Kinematic Constraints and Motion Primitives section for more details.)
\r\n\r\n
Since the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.
\r\n\r\n
State Validity and Collision Checking
\r\n\r\n
One important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.
\r\n\r\n
Looking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).
\r\n\r\n
More constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.
\r\n\r\n
Before moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.
\r\n\r\n
Planners
\r\n\r\n
Now that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.
\r\n\r\n
This parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.
\r\n
\r\n
The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. Weighted A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.
\r\n\r\n
With the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.
\r\n\r\n
[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]
\r\n\r\n
So what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.md b/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.md new file mode 100644 index 0000000..6420067 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0049-primer-to-the-search-based-planning-library-sbpl.md @@ -0,0 +1,47 @@ +# Primer to the Search-Based Planning Library (SBPL) + +This article aims to give a very brief overview of the concepts behind SBPL. See [this wiki article](http://en.wikipedia.org/wiki/Motion_planning) for an intro to motion planning. + +**Search-based Planning** + +Search-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. This is in contrast to sample-based planning methods, which is described very well in the [OMPL primer](http://ompl.kavrakilab.org/OMPL_Primer.pdf). Search-based methods provides guarantees on path quality and are used in scenarios which demand low cost paths (e.g. robot navigation). + +First we talk about how the environment of the problem is discretized, then we describe how planning is done. + +**Environments (or discrete representation of a planning problem)** + +In order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z position in the world. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of these states is defined as the state space. + +The image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1). + +  + +The graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the [Kinematic Constraints and Motion Primitives](http://victor.hwanger.com/post/47052754092/kinematic-constraints-and-motion-primitives) section for more details.) + +Since the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph. + +**State Validity and Collision Checking** + +One important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent. + +Looking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid). + +More constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid. + +Before moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph. + +**Planners** + +Now that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*. + +This parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work. + +  + +The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. Weighted A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution. + +With the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time. + +[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.] + +So what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run. diff --git a/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.html b/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.html new file mode 100644 index 0000000..e86f2ae --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.html @@ -0,0 +1,30 @@ + +This article aims to give a very brief overview of the concepts behind SBPL. See this wiki article for an intro to motion planning.
+Search-based Planning
+Search-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. Because a graph is inherently discrete, all graph-search algorithms require this discrete representation. Search-based planning can then be seen as two problems: how to turn the problem into a graph, and how to search the graph to find the best solution.
+This is in contrast to sample-based planning methods, which are able to solve problems in continuous space without a graph representation (though certain sampling-based methods do discretize the space). While the pros and cons between the two methods can be debated for many hours, the most apparent difference between the two methods are speed and optimality: graph-search methods can guarantee how "efficient" a solution is (defined more later), but, in general, does so at the expense of computation time. Sampling based planners run fast, but can result in unusual looking and possibly inefficient paths.
+First we talk about how the environment of the problem is discretized, then we describe how planning is done.
+Environments (or discrete representation of a planning problem)
+In order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z, roll, pitch, and yaw. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of all possible states is defined as the state space. For the car example, if we have a 50x50 grid of locations it could be in while forcing the car to be in 1 of 4 orientations at all times, we would have a state space of size 50*50*4=10000.
+The image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).
+
The graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the Kinematic Constraints and Motion Primitives section for more details.)
+Since the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.
+State Validity and Collision Checking
+One important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.
+Looking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).
+More constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.
+Before moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.
+Planners
+Now that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.
+This parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.
+
The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. The vanilla A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.
+With the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.
+[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]
+So what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.
+ + diff --git a/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.json b/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.json new file mode 100644 index 0000000..8c74d96 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.json @@ -0,0 +1,25 @@ +{ + "nid": 50, + "vid": 50, + "type": "page", + "language": "und", + "title": "Primer to Search-Based Motion Planning", + "slug": "primer-to-search-based-motion-planning", + "uid": 648, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1370992592, + "changed": 1373331899, + "url_aliases": [], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "This article aims to give a very brief overview of the concepts behind SBPL. See this wiki article for an intro to motion planning.
\r\nSearch-based Planning
\r\nSearch-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. Because a graph is inherently discrete, all graph-search algorithms require this discrete representation. Search-based planning can then be seen as two problems: how to turn the problem into a graph, and how to search the graph to find the best solution.
\r\nThis is in contrast to sample-based planning methods, which are able to solve problems in continuous space without a graph representation (though certain sampling-based methods do discretize the space). While the pros and cons between the two methods can be debated for many hours, the most apparent difference between the two methods are speed and optimality: graph-search methods can guarantee how "efficient" a solution is (defined more later), but, in general, does so at the expense of computation time. Sampling based planners run fast, but can result in unusual looking and possibly inefficient paths.
\r\nFirst we talk about how the environment of the problem is discretized, then we describe how planning is done.
\r\nEnvironments (or discrete representation of a planning problem)
\r\nIn order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z, roll, pitch, and yaw. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of all possible states is defined as the state space. For the car example, if we have a 50x50 grid of locations it could be in while forcing the car to be in 1 of 4 orientations at all times, we would have a state space of size 50*50*4=10000.
\r\nThe image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).
\r\n
The graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the Kinematic Constraints and Motion Primitives section for more details.)
\r\nSince the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.
\r\nState Validity and Collision Checking
\r\nOne important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.
\r\nLooking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).
\r\nMore constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.
\r\nBefore moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.
\r\nPlanners
\r\nNow that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.
\r\nThis parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.
\r\n
The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. The vanilla A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.
\r\nWith the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.
\r\n[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]
\r\nSo what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.
\r\n", + "body_markdown": "This article aims to give a very brief overview of the concepts behind SBPL. See [this wiki article](http://en.wikipedia.org/wiki/Motion_planning) for an intro to motion planning.\n\n**Search-based Planning**\n\nSearch-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. Because a graph is inherently discrete, all graph-search algorithms require this discrete representation. Search-based planning can then be seen as two problems: how to turn the problem into a graph, and how to search the graph to find the best solution.\n\nThis is in contrast to sample-based planning methods, which are able to solve problems in continuous space without a graph representation (though certain sampling-based methods do discretize the space). While the pros and cons between the two methods can be debated for many hours, the most apparent difference between the two methods are speed and optimality: graph-search methods can guarantee how \"efficient\" a solution is (defined more later), but, in general, does so at the expense of computation time. Sampling based planners run fast, but can result in unusual looking and possibly inefficient paths.\n\nFirst we talk about how the environment of the problem is discretized, then we describe how planning is done.\n\n**Environments (or discrete representation of a planning problem)**\n\nIn order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z, roll, pitch, and yaw. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of all possible states is defined as the state space. For the car example, if we have a 50x50 grid of locations it could be in while forcing the car to be in 1 of 4 orientations at all times, we would have a state space of size 50*50*4=10000.\n\nThe image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).\n\n\n\nThe graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the [Kinematic Constraints and Motion Primitives](http://sbpl.net/node/48) section for more details.)\n\nSince the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.\n\n**State Validity and Collision Checking**\n\nOne important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.\n\nLooking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).\n\nMore constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.\n\nBefore moving on to searching this graph, it's important to note that the translation between the \"real world\" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.\n\n**Planners**\n\nNow that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.\n\nThis parameter of \"good enough\" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.\n\n \n\nThe three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. The vanilla A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.\n\nWith the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.\n\n[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]\n\nSo what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.\n", + "body_html_raw": "This article aims to give a very brief overview of the concepts behind SBPL. See this wiki article for an intro to motion planning.
\r\nSearch-based Planning
\r\nSearch-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. Because a graph is inherently discrete, all graph-search algorithms require this discrete representation. Search-based planning can then be seen as two problems: how to turn the problem into a graph, and how to search the graph to find the best solution.
\r\nThis is in contrast to sample-based planning methods, which are able to solve problems in continuous space without a graph representation (though certain sampling-based methods do discretize the space). While the pros and cons between the two methods can be debated for many hours, the most apparent difference between the two methods are speed and optimality: graph-search methods can guarantee how "efficient" a solution is (defined more later), but, in general, does so at the expense of computation time. Sampling based planners run fast, but can result in unusual looking and possibly inefficient paths.
\r\nFirst we talk about how the environment of the problem is discretized, then we describe how planning is done.
\r\nEnvironments (or discrete representation of a planning problem)
\r\nIn order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z, roll, pitch, and yaw. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of all possible states is defined as the state space. For the car example, if we have a 50x50 grid of locations it could be in while forcing the car to be in 1 of 4 orientations at all times, we would have a state space of size 50*50*4=10000.
\r\nThe image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1).
\r\n
The graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the Kinematic Constraints and Motion Primitives section for more details.)
\r\nSince the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph.
\r\nState Validity and Collision Checking
\r\nOne important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent.
\r\nLooking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid).
\r\nMore constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid.
\r\nBefore moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph.
\r\nPlanners
\r\nNow that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*.
\r\nThis parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work.
\r\n
The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. The vanilla A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution.
\r\nWith the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time.
\r\n[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.]
\r\nSo what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run.
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.md b/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.md new file mode 100644 index 0000000..2694cfd --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0050-primer-to-search-based-motion-planning.md @@ -0,0 +1,49 @@ +# Primer to Search-Based Motion Planning + +This article aims to give a very brief overview of the concepts behind SBPL. See [this wiki article](http://en.wikipedia.org/wiki/Motion_planning) for an intro to motion planning. + +**Search-based Planning** + +Search-based planning is a motion planning method which uses graph search methods to compute paths or trajectories over a discrete representation of the problem. Because a graph is inherently discrete, all graph-search algorithms require this discrete representation. Search-based planning can then be seen as two problems: how to turn the problem into a graph, and how to search the graph to find the best solution. + +This is in contrast to sample-based planning methods, which are able to solve problems in continuous space without a graph representation (though certain sampling-based methods do discretize the space). While the pros and cons between the two methods can be debated for many hours, the most apparent difference between the two methods are speed and optimality: graph-search methods can guarantee how "efficient" a solution is (defined more later), but, in general, does so at the expense of computation time. Sampling based planners run fast, but can result in unusual looking and possibly inefficient paths. + +First we talk about how the environment of the problem is discretized, then we describe how planning is done. + +**Environments (or discrete representation of a planning problem)** + +In order to properly represent the problem with a graph, we first discretize all possible states so that there are a finite number of states a robot could be in. Here, the definition of state varies depending on the application. For a car, you might only be concerned with the x, y, and orientation. For a helicopter, it might be the x, y, z, roll, pitch, and yaw. For a robotic arm, it would be the values of each joint in the arm (joint1, joint2, joint3, joint4). The collection of all possible states is defined as the state space. For the car example, if we have a 50x50 grid of locations it could be in while forcing the car to be in 1 of 4 orientations at all times, we would have a state space of size 50*50*4=10000. + +The image below shows a small portion of the state space. Here, each possible (x,y) position that a robot could be in is represented as a node with a state ID (S1, S2, etc). A path for a robot in this state space would then be moving through a series of adjacent states (for example S6, S4, S1). + + + +The graph representation then comes naturally - valid transitions between adjacent states (also called the successors of the state) are represented by edges between the nodes. For now, we assume that any two adjacent states will have a valid transition between them (this is a bit oversimplifying, but it's good enough for now - see the [Kinematic Constraints and Motion Primitives](http://sbpl.net/node/48) section for more details.) + +Since the state ID is just a number, environments of nearly any dimension can be discretely represented as a graph. + +**State Validity and Collision Checking** + +One important notion about the state space is the validity of states. When computing a trajectory, we need all states in the trajectory to be valid. Obviously, the definition of valid becomes very domain dependent. + +Looking at the above figure, which represents the 2D environment, we see that there are states that are invalid - if the blacked out regions are buildings, we certainly wouldn't want to be traveling through them. In this case, those states are obviously invalid. More specifically, the robot would be in collision with the building. The same idea occurs in the robotic arm domain - given a particular set of joint angles for an arm, does it collide with anything in the environment? In both cases, we need logic that takes in knowledge about the robot's surrounding environment and a given state. It then returns a value telling us whether we are in collision or not (or synonymously, if the state is valid). + +More constraints can be added as needed to the requirements of a valid state. Let's take the case where we have a robotic arm with the same joints and joint limitations as a human arm. We need to make an extra state validity check beyond just seeing if we collide with anything in the environment. If we had a list of states with the elbow joint going from 0 degrees to 270 degrees, many of those states would be invalid - elbows only have a 180 degree range (or have a joint limit of 180 degrees). Therefore, states specifying an elbow angle from 181-270 would be deemed invalid. + +Before moving on to searching this graph, it's important to note that the translation between the "real world" context and what the graph looks like is completely decoupled from how the problem is solved. Because each state is encoded into a single identifying number (state IDs), the graph searching algorithm doesn't need to know what the original domain was - all it needs are these state IDs. This decoupling of the environment from the graph allows the graph search algorithm to operate on any problem that can be represented as a graph. + +**Planners** + +Now that we have a basic concept of what the graph represents, we can look at methods for solving the motion planning problem. The simplest approaches to this would be using Dijkstra's or the A* algorithm, which returns the shortest possible path between a given start and goal. However, this can be slow and memory expensive. Instead, we can find a suboptimal solution, or a path from the start to goal that isn't necessarily the best one. In most cases, we don't need to have the best path - we just need one that's good enough. This relaxes the conditions on the graph search and allows us to find a good-enough solution in much less time with much less memory. One algorithm that does this is weighted A*. + +This parameter of "good enough" is often denoted as epsilon of the best solution. If we allow an epsilon of 5, this means that the weighted A* algorithm will return a path that is no worse than 5 times the cost of the optimal solution. This concept of suboptimality is fundamental to how SBPL planners work. + +  + +The three animations here depict a Dijkstra search, an A* search, and a weighted A* search. The speed and memory usage (in terms of number of nodes that are expanded) of each can easily be seen. Dijkstra's is the slowest and expands the most number of states. The vanilla A* is a bit better, and computes an optimal path as well (though in this case, it's not the same as Dijkstra's because there is more than one optimal path). Weighted A* runs the fastest, but does not return the best solution. + +With the ARA* algorithm, we can have the best of both worlds - a suboptimal solution can be returned very quickly (high epsilon), and then ARA* can continue working to return a lower epsilon solution for a user specified amount of time. + +[SBPL also implements a number of different algorithms (ARA*, AD*, R*, D* Lite, etc) that produce paths with user-specified epsilons. The differences between the algorithms are described in this future article.] + +So what does SBPL actually do? SBPL computes the exact motion path for a robot to follow in order to get from point A to point B. Furthermore, SBPL allows us to trade off how good the path is versus how long it takes to compute. If we care about computation time (like if our robot car is driving really fast), we reduce the optimality of the path. If the car's driving slowly, and we'd like shorter paths, then we can allot more time for the planner to run. diff --git a/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.html b/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.html new file mode 100644 index 0000000..47077d6 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.html @@ -0,0 +1,63 @@ + +This tutorial will go through a simple example of loading in an environment (the Willow Garage floorplan), then generating a plan from a specified start and goal.
+As described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. The code below shows the initialization of an environment in the (x, y, theta) state space. We'll then use the ARA* planner to produce our paths.
+Initializing the environment
+We'll be using an environment file (specific to EnvironmentXYTHETALAT) that already contains values for all the parameters we need, so you can load them right in. But here's the breakdown of what the XYTheta environment requires.
++
The Code
+You can find the entire file at this GIST. We'll step through the planxythetalat function.
+ +Perimeter of robot
+This function defines a vector of points that describe the perimeter of the robot. The (0,0) point of the robot is the reference location that the planner uses. In this example, the robot is a .01m by .01m robot, with its center at (0,0).
+Initializing the environment
+This initializes our environment with the information from the environment file, perimeter description, and motion primitive file. There are also functions available to initialize an environment without a file, but this requires a lot of parameters to be passed into the initialization function.
+Specifying start and goal state
+This sets the desired start and goal states to plan between. A very important detail here is that start_id and goal_id get filled in to be used later. BOTH the environment and planner must have their start and goal set. The environment takes in the continuous coordinate for the start and goal, and the planner takes in the state IDs for the start and goal.
+Initializing the planner
+Here, we specify the initial epsilon. By default, this will decrement the epsilon by .2 after every solved plan. The search mode of the planner denotes if it quits after the first solution (search_mode = true) or if it continues to try and improve its solution quality until it's out of time (search_mode = false). One other parameter here is the bsearch, which sets whether it is a forward or backward search (searching from start to goal or from goal to start).
+Planning
+The planner takes in an double limiting how long it has to plan. It returns a vector containing the state IDs for the path. It then prints out some stats that shows how long it took to plan, the solution cost, and the final epsilon it reached.
+Writing out solution
+While the planner returned a vector of state IDs, this is not what you would feed to a controller - it must be converted back into continuous coordinates. The writeSolution function spits out a text file containing both the discrete and continuous paths. You'll notice that the continuous path has many more points than the discrete path. This is because each motion primitive is composed of many waypoints that are expanded for the continuous path.
+Running the code
+Once you compile the code, you can run it with
++$ ./xytheta [location of willow cfg file] [location of motion primitives file]+
In the standard SBPL install, use these files
+
+env_examples/nav3d/willow-25mm-inflated-env.cfg
+matlab/mprim/pr2.mprim
+
+(By default, the willow cfg comes as a zip, so you have to unzip it first). This will produce two solution files sol.txt and sol.txt.discrete
+This is the planned path plotted using this python code (depends on matplotlib and numpy). You can run this code with
+python visualize.py willow-25mm-inflated-env.cfg sol.txt.discrete+
+
+ + diff --git a/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.json b/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.json new file mode 100644 index 0000000..ab8e5ab --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.json @@ -0,0 +1,25 @@ +{ + "nid": 51, + "vid": 51, + "type": "page", + "language": "und", + "title": "Planning with SBPL: Example in X, Y, Theta State Space", + "slug": "planning-with-sbpl-example-in-x-y-theta-state-space", + "uid": 648, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1370993106, + "changed": 1386260017, + "url_aliases": [], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "
This tutorial will go through a simple example of loading in an environment (the Willow Garage floorplan), then generating a plan from a specified start and goal.
\r\nAs described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. The code below shows the initialization of an environment in the (x, y, theta) state space. We'll then use the ARA* planner to produce our paths.
\r\nInitializing the environment
\r\nWe'll be using an environment file (specific to EnvironmentXYTHETALAT) that already contains values for all the parameters we need, so you can load them right in. But here's the breakdown of what the XYTheta environment requires.
\r\n\r\n
The Code
\r\nYou can find the entire file at this GIST. We'll step through the planxythetalat function.
\r\n\r\nPerimeter of robot
\r\nThis function defines a vector of points that describe the perimeter of the robot. The (0,0) point of the robot is the reference location that the planner uses. In this example, the robot is a .01m by .01m robot, with its center at (0,0).
\r\nInitializing the environment
\r\nThis initializes our environment with the information from the environment file, perimeter description, and motion primitive file. There are also functions available to initialize an environment without a file, but this requires a lot of parameters to be passed into the initialization function.
\r\nSpecifying start and goal state
\r\nThis sets the desired start and goal states to plan between. A very important detail here is that start_id and goal_id get filled in to be used later. BOTH the environment and planner must have their start and goal set. The environment takes in the continuous coordinate for the start and goal, and the planner takes in the state IDs for the start and goal.
\r\nInitializing the planner
\r\nHere, we specify the initial epsilon. By default, this will decrement the epsilon by .2 after every solved plan. The search mode of the planner denotes if it quits after the first solution (search_mode = true) or if it continues to try and improve its solution quality until it's out of time (search_mode = false). One other parameter here is the bsearch, which sets whether it is a forward or backward search (searching from start to goal or from goal to start).
\r\nPlanning
\r\nThe planner takes in an double limiting how long it has to plan. It returns a vector containing the state IDs for the path. It then prints out some stats that shows how long it took to plan, the solution cost, and the final epsilon it reached.
\r\nWriting out solution
\r\nWhile the planner returned a vector of state IDs, this is not what you would feed to a controller - it must be converted back into continuous coordinates. The writeSolution function spits out a text file containing both the discrete and continuous paths. You'll notice that the continuous path has many more points than the discrete path. This is because each motion primitive is composed of many waypoints that are expanded for the continuous path.
\r\nRunning the code
\r\nOnce you compile the code, you can run it with
\r\n\r\n$ ./xytheta [location of willow cfg file] [location of motion primitives file]\r\n
In the standard SBPL install, use these files
\r\n\r\nenv_examples/nav3d/willow-25mm-inflated-env.cfg\r\nmatlab/mprim/pr2.mprim\r\n\r\n(By default, the willow cfg comes as a zip, so you have to unzip it first). This will produce two solution files sol.txt and sol.txt.discrete
\r\nThis is the planned path plotted using this python code (depends on matplotlib and numpy). You can run this code with
\r\npython visualize.py willow-25mm-inflated-env.cfg sol.txt.discrete\r\n
![\"image\"](\"http://media.tumblr.com/60a4d48268e40b016df3f6933c71065d/tumblr_inline_mkp51c2BGn1qz4rgp.png\")
\r\n
\r\n", + "body_markdown": "This tutorial will go through a simple example of loading in an environment (the Willow Garage floorplan), then generating a plan from a specified start and goal.\n\nAs described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. The code below shows the initialization of an environment in the (x, y, theta) state space. We'll then use the ARA* planner to produce our paths.\n\n**Initializing the environment**\n\nWe'll be using an environment file (specific to EnvironmentXYTHETALAT) that already contains values for all the parameters we need, so you can load them right in. But here's the breakdown of what the XYTheta environment requires.\n\n- discretization(cells): this describes how many cells the environment is descretized into.\n- Obsthresh: equivalent to cost_lethal (see [section 1.5 of the ROS Wiki](http://www.ros.org/wiki/costmap_2d))\n- Cost_inscribed_thresh: (see [section 1.5 of the ROS Wiki](http://www.ros.org/wiki/costmap_2d))\n- Cost_possibly_circumscribed_thresh: (see [section 1.5 of the ROS Wiki](http://www.ros.org/wiki/costmap_2d))\n- Cellsize(meters): the length of one edge of a square cell. Multipyling each value in the discretization(cell) line should yield the size of your actual map.\n- nominalvel(mpersecs): speed of translational movement\n- timetoturn45degsinplace(secs): speed of rotational movement\n- start(meters,rads): the start x, y, and theta position\n- end(meters,rads): the end x, y, and theta position\n- environment: a map of the environment.\n\n**The Code**\n\nYou can find the entire file at [this GIST](https://gist.github.com/vhwanger/5304396). We'll step through the planxythetalat function.\n\n**Perimeter of robot**\n\nThis function defines a vector of points that describe the perimeter of the robot. The (0,0) point of the robot is the reference location that the planner uses. In this example, the robot is a .01m by .01m robot, with its center at (0,0).\n\n**Initializing the environment**\n\nThis initializes our environment with the information from the environment file, perimeter description, and motion primitive file. There are also functions available to initialize an environment without a file, but this requires a lot of parameters to be passed into the initialization function.\n\n**Specifying start and goal state**\n\nThis sets the desired start and goal states to plan between. A very important detail here is that start_id and goal_id get filled in to be used later. BOTH the environment and planner must have their start and goal set. The environment takes in the continuous coordinate for the start and goal, and the planner takes in the state IDs for the start and goal.\n\n**Initializing the planner**\n\nHere, we specify the initial epsilon. By default, this will decrement the epsilon by .2 after every solved plan. The search mode of the planner denotes if it quits after the first solution (search_mode = true) or if it continues to try and improve its solution quality until it's out of time (search_mode = false). One other parameter here is the bsearch, which sets whether it is a forward or backward search (searching from start to goal or from goal to start).\n\n**Planning**\n\nThe planner takes in an double limiting how long it has to plan. It returns a vector containing the state IDs for the path. It then prints out some stats that shows how long it took to plan, the solution cost, and the final epsilon it reached.\n\n**Writing out solution**\n\nWhile the planner returned a vector of state IDs, this is not what you would feed to a controller - it must be converted back into continuous coordinates. The writeSolution function spits out a text file containing both the discrete and continuous paths. You'll notice that the continuous path has many more points than the discrete path. This is because each motion primitive is composed of many waypoints that are expanded for the continuous path.\n\n**Running the code**\n\nOnce you compile the code, you can run it with\n\n```\n\r\n$ ./xytheta [location of willow cfg file] [location of motion primitives file]\n```\n\nIn the standard SBPL install, use these files\n\n```\n\r\nenv_examples/nav3d/willow-25mm-inflated-env.cfg\r\nmatlab/mprim/pr2.mprim\r\n\n```\n\n(By default, the willow cfg comes as a zip, so you have to unzip it first). This will produce two solution files sol.txt and sol.txt.discrete\n\nThis is the planned path plotted using [this python code](https://gist.github.com/vhwanger/5304953) (depends on matplotlib and numpy). You can run this code with\n\n```\npython visualize.py willow-25mm-inflated-env.cfg sol.txt.discrete\n```\n\n\n", + "body_html_raw": "
This tutorial will go through a simple example of loading in an environment (the Willow Garage floorplan), then generating a plan from a specified start and goal.
\r\nAs described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. The code below shows the initialization of an environment in the (x, y, theta) state space. We'll then use the ARA* planner to produce our paths.
\r\nInitializing the environment
\r\nWe'll be using an environment file (specific to EnvironmentXYTHETALAT) that already contains values for all the parameters we need, so you can load them right in. But here's the breakdown of what the XYTheta environment requires.
\r\n\r\n
The Code
\r\nYou can find the entire file at this GIST. We'll step through the planxythetalat function.
\r\n\r\nPerimeter of robot
\r\nThis function defines a vector of points that describe the perimeter of the robot. The (0,0) point of the robot is the reference location that the planner uses. In this example, the robot is a .01m by .01m robot, with its center at (0,0).
\r\nInitializing the environment
\r\nThis initializes our environment with the information from the environment file, perimeter description, and motion primitive file. There are also functions available to initialize an environment without a file, but this requires a lot of parameters to be passed into the initialization function.
\r\nSpecifying start and goal state
\r\nThis sets the desired start and goal states to plan between. A very important detail here is that start_id and goal_id get filled in to be used later. BOTH the environment and planner must have their start and goal set. The environment takes in the continuous coordinate for the start and goal, and the planner takes in the state IDs for the start and goal.
\r\nInitializing the planner
\r\nHere, we specify the initial epsilon. By default, this will decrement the epsilon by .2 after every solved plan. The search mode of the planner denotes if it quits after the first solution (search_mode = true) or if it continues to try and improve its solution quality until it's out of time (search_mode = false). One other parameter here is the bsearch, which sets whether it is a forward or backward search (searching from start to goal or from goal to start).
\r\nPlanning
\r\nThe planner takes in an double limiting how long it has to plan. It returns a vector containing the state IDs for the path. It then prints out some stats that shows how long it took to plan, the solution cost, and the final epsilon it reached.
\r\nWriting out solution
\r\nWhile the planner returned a vector of state IDs, this is not what you would feed to a controller - it must be converted back into continuous coordinates. The writeSolution function spits out a text file containing both the discrete and continuous paths. You'll notice that the continuous path has many more points than the discrete path. This is because each motion primitive is composed of many waypoints that are expanded for the continuous path.
\r\nRunning the code
\r\nOnce you compile the code, you can run it with
\r\n\r\n$ ./xytheta [location of willow cfg file] [location of motion primitives file]\r\n
In the standard SBPL install, use these files
\r\n\r\nenv_examples/nav3d/willow-25mm-inflated-env.cfg\r\nmatlab/mprim/pr2.mprim\r\n\r\n(By default, the willow cfg comes as a zip, so you have to unzip it first). This will produce two solution files sol.txt and sol.txt.discrete
\r\nThis is the planned path plotted using this python code (depends on matplotlib and numpy). You can run this code with
\r\npython visualize.py willow-25mm-inflated-env.cfg sol.txt.discrete\r\n
\r\n
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.md b/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.md new file mode 100644 index 0000000..44b1d96 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.md @@ -0,0 +1,76 @@ +# Planning with SBPL: Example in X, Y, Theta State Space + +This tutorial will go through a simple example of loading in an environment (the Willow Garage floorplan), then generating a plan from a specified start and goal. + +As described in the previous tutorial, planning with search-based methods have two parts - representing the problem as a graph, then solving the graph with graph-search methods. SBPL has two objects it uses for these two roles - the environment and the planner. The code below shows the initialization of an environment in the (x, y, theta) state space. We'll then use the ARA* planner to produce our paths. + +**Initializing the environment** + +We'll be using an environment file (specific to EnvironmentXYTHETALAT) that already contains values for all the parameters we need, so you can load them right in. But here's the breakdown of what the XYTheta environment requires. + +- discretization(cells): this describes how many cells the environment is descretized into. +- Obsthresh: equivalent to cost_lethal (see [section 1.5 of the ROS Wiki](http://www.ros.org/wiki/costmap_2d)) +- Cost_inscribed_thresh: (see [section 1.5 of the ROS Wiki](http://www.ros.org/wiki/costmap_2d)) +- Cost_possibly_circumscribed_thresh: (see [section 1.5 of the ROS Wiki](http://www.ros.org/wiki/costmap_2d)) +- Cellsize(meters): the length of one edge of a square cell. Multipyling each value in the discretization(cell) line should yield the size of your actual map. +- nominalvel(mpersecs): speed of translational movement +- timetoturn45degsinplace(secs): speed of rotational movement +- start(meters,rads): the start x, y, and theta position +- end(meters,rads): the end x, y, and theta position +- environment: a map of the environment. + +**The Code** + +You can find the entire file at [this GIST](https://gist.github.com/vhwanger/5304396). We'll step through the planxythetalat function. + +**Perimeter of robot** + +This function defines a vector of points that describe the perimeter of the robot. The (0,0) point of the robot is the reference location that the planner uses. In this example, the robot is a .01m by .01m robot, with its center at (0,0). + +**Initializing the environment** + +This initializes our environment with the information from the environment file, perimeter description, and motion primitive file. There are also functions available to initialize an environment without a file, but this requires a lot of parameters to be passed into the initialization function. + +**Specifying start and goal state** + +This sets the desired start and goal states to plan between. A very important detail here is that start_id and goal_id get filled in to be used later. BOTH the environment and planner must have their start and goal set. The environment takes in the continuous coordinate for the start and goal, and the planner takes in the state IDs for the start and goal. + +**Initializing the planner** + +Here, we specify the initial epsilon. By default, this will decrement the epsilon by .2 after every solved plan. The search mode of the planner denotes if it quits after the first solution (search_mode = true) or if it continues to try and improve its solution quality until it's out of time (search_mode = false). One other parameter here is the bsearch, which sets whether it is a forward or backward search (searching from start to goal or from goal to start). + +**Planning** + +The planner takes in an double limiting how long it has to plan. It returns a vector containing the state IDs for the path. It then prints out some stats that shows how long it took to plan, the solution cost, and the final epsilon it reached. + +**Writing out solution** + +While the planner returned a vector of state IDs, this is not what you would feed to a controller - it must be converted back into continuous coordinates. The writeSolution function spits out a text file containing both the discrete and continuous paths. You'll notice that the continuous path has many more points than the discrete path. This is because each motion primitive is composed of many waypoints that are expanded for the continuous path. + +**Running the code** + +Once you compile the code, you can run it with + +``` + +$ ./xytheta [location of willow cfg file] [location of motion primitives file] +``` + +In the standard SBPL install, use these files + +``` + +env_examples/nav3d/willow-25mm-inflated-env.cfg +matlab/mprim/pr2.mprim + +``` + +(By default, the willow cfg comes as a zip, so you have to unzip it first). This will produce two solution files sol.txt and sol.txt.discrete + +This is the planned path plotted using [this python code](https://gist.github.com/vhwanger/5304953) (depends on matplotlib and numpy). You can run this code with + +``` +python visualize.py willow-25mm-inflated-env.cfg sol.txt.discrete +``` + + diff --git a/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.html b/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.html new file mode 100644 index 0000000..6e513dc --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.html @@ -0,0 +1,109 @@ + +
In this article, we'll talk about how to generate motion primitves that SBPL uses for its lattice planning. For an introduction to motion primitives, see this article.
+Visualizing motion primitives
+In the
++matlab/mprim/+
folder of sbpl, you'll find numerous files of the form
++genmprim_*+
These files generate different sets of motion primitives a robot could use. To start, open up matlab and run one of these:
++ >>> genmprim output.mprim+
A window similar to the one shown below should appear which shows the motion primitives for a variety of angles. If you hit <enter> in the matlab window, you'll see the visualizations increment. As your keep on hitting <enter>, you'll see all the primitives that are generated.
+Decoding the genmprim.m script
+At the top of the script, you'll see the following declarations:
++if UNICYCLE_MPRIM_16DEGS == 1 + resolution = 0.025; + numberofangles = 16; %preferably a power of 2, definitely multiple of 8 + numberofprimsperangle = 9; ++
Resolution denotes the resolution of your map.
+numberofangles denotes how many discrete states a full 360 degree rotation should be discretized into.
+numberofprimsperangle denotes how many different motions the robot can take for a given discretized angle.
+
To put these parameters into perspective, let's look at the labeled image above. The image shows motion primitives for 1 of the 16 discretized angles (angle = 0). There are 9 different paths the robot can take for a given angle, which are organized into the following categories: forward, forward and turn, sidestep, backward, and turn in place. Note that there are actually two turn in place actions (clockwise and counter clockwise), but this does not show up well in the image. Also, we have two motion primitives for moving forward: one that moves 1 unit, and another that moves 8 units (this tends to speed up the search if chosen well). Since the rotation is discretized into 16 states with 9 primitives for each, the robot will have a total of 144 motion primitives.
+Multipliers
++ %multipliers (multiplier is used as costmult*cost) + forwardcostmult = 1; + backwardcostmult = 5; + forwardandturncostmult = 1; + sidestepcostmult = 50; + turninplacecostmult = 50; ++
The multipliers allow the user to define preferred actions. For example, if the robot is slow to move backwards, one would raise the cost multiplier on the backwards cost.
+Motion Vectors
+In order to define the actual motions, we use delta position vectors. The below is taken from genmprim_unicycleplussideways.
++ %note, what is shown x,y,theta *changes* (that is, dx,dy,dtheta and not absolute numbers) + + %0 degreees + basemprimendpts0_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult + %angles are positive counterclockwise + %0 theta change + basemprimendpts0_c(1,:) = [1 0 0 forwardcostmult]; + basemprimendpts0_c(2,:) = [8 0 0 forwardcostmult]; + basemprimendpts0_c(3,:) = [-1 0 0 backwardcostmult]; + %1/16 theta change + basemprimendpts0_c(4,:) = [8 1 1 forwardandturncostmult]; + basemprimendpts0_c(5,:) = [8 -1 -1 forwardandturncostmult]; + %turn in place + basemprimendpts0_c(6,:) = [0 0 1 turninplacecostmult]; + basemprimendpts0_c(7,:) = [0 0 -1 turninplacecostmult]; + %sideways maintaining the same heading + basemprimendpts0_c(8,:) = [0 1 0 sidestepcostmult]; + basemprimendpts0_c(9,:) = [0 -1 0 sidestepcostmult]; + + %45 degrees + basemprimendpts45_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult (multiplier is used as costmult*cost) + %angles are positive counterclockwise + %0 theta change + basemprimendpts45_c(1,:) = [1 1 0 forwardcostmult]; + basemprimendpts45_c(2,:) = [6 6 0 forwardcostmult]; + basemprimendpts45_c(3,:) = [-1 -1 0 backwardcostmult]; + %1/16 theta change + basemprimendpts45_c(4,:) = [5 7 1 forwardandturncostmult]; + basemprimendpts45_c(5,:) = [7 5 -1 forwardandturncostmult]; + %turn in place + basemprimendpts45_c(6,:) = [0 0 1 turninplacecostmult]; + basemprimendpts45_c(7,:) = [0 0 -1 turninplacecostmult]; + %sideways maintaining the same heading + basemprimendpts45_c(8,:) = [-1 1 0 sidestepcostmult]; + basemprimendpts45_c(9,:) = [1 -1 0 sidestepcostmult]; + + %22.5 degrees + basemprimendpts22p5_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult (multiplier is used as costmult*cost) + %angles are positive counterclockwise + %0 theta change + basemprimendpts22p5_c(1,:) = [2 1 0 forwardcostmult]; + basemprimendpts22p5_c(2,:) = [6 3 0 forwardcostmult]; + basemprimendpts22p5_c(3,:) = [-2 -1 0 backwardcostmult]; + %1/16 theta change + basemprimendpts22p5_c(4,:) = [5 4 1 forwardandturncostmult]; + basemprimendpts22p5_c(5,:) = [7 2 -1 forwardandturncostmult]; + %turn in place + basemprimendpts22p5_c(6,:) = [0 0 1 turninplacecostmult]; + basemprimendpts22p5_c(7,:) = [0 0 -1 turninplacecostmult]; + %sideways maintaining the same heading + basemprimendpts22p5_c(8,:) = [-1 2 0 sidestepcostmult]; + basemprimendpts22p5_c(9,:) = [1 -2 0 sidestepcostmult]; + ++
Defining the motion primitives is a little bit tricky due to discretization problems. Intuitively, we'd expect to only define 9 motion primitives that would be used for all 16 of our discrete angles. However, due to angle discretization error, a motion primitive defined for a robot oriented at 0 degrees may not be the best motion primitive for a robot oriented at 22.5 degrees. We'll address why this is in a bit.
+In order to combat this, we define each angle (for one quadrant) explicitly. Since we have a total of 16 discretized angles, we can get away with defining 4 of the angles for quadrant one, and then duplicating the motions for the other three quadrants. Thus, we only need to define motion primitives for 4 angles: 0, 22.5, 45, and 67.5. We can take advantage of symmetry again and say that angles 22.5 and 67.5 can use the same set of motion primitives (as their discretization errors will be the same). In this code, we define motion primitives for 22.5 degrees.
+Now, we only have to define motion primitives for 3 angles: 0, 22.5, and 45. With 9 motion primitives for each, this means we must define 27 motion primitives. Looking above, we see that there are indeed 27 definitions. Let's look at the definition for moving forward 8 units when the robot is oriented at 0 degrees:
++basemprimendpts0_c(2,:) = [8 0 0 forwardcostmult];+
The format for this vector is [dx dy dtheta multiplier]. Since we're facing down the positive x-axis, we want dx=8, and everything else 0. For the same motion when the robot is oriented at 45 degrees, we use:
++basemprimendpts45_c(2,:) = [6 6 0 forwardcostmult];+
Notice that the distance traversed is actually more than 8 (8.48). This is to counteract the previously described discretization error. This extra distance ensure that we land in the center of the discretized cell, rather than off to one corner. When designing your own motion primitives, it's important to make sure your motions land you in the centers of cells to avoid discontinuous paths. The image below depicts what happens when your motion primitives don't land in the middle of the cell - even though it's valid in discrete space, the continuous path is invalid (thanks Andrew Dornbush).
+
Once you've defined your set of motion primitives, use the matlab visualization to ensure that the motions are correct. The generated file (usually ending with .mprim) is now ready for use by the SBPL planner!
+ + diff --git a/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.json b/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.json new file mode 100644 index 0000000..8665fcf --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.json @@ -0,0 +1,25 @@ +{ + "nid": 52, + "vid": 52, + "type": "page", + "language": "und", + "title": "Generating Motion Primitives with SBPL", + "slug": "generating-motion-primitives-with-sbpl", + "uid": 648, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1373327335, + "changed": 1373331662, + "url_aliases": [], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "In this article, we'll talk about how to generate motion primitves that SBPL uses for its lattice planning. For an introduction to motion primitives, see this article.
\r\nVisualizing motion primitives
\r\nIn the
\r\n\r\nmatlab/mprim/\r\n
folder of sbpl, you'll find numerous files of the form
\r\n\r\ngenmprim_*\r\n
These files generate different sets of motion primitives a robot could use. To start, open up matlab and run one of these:
\r\n\r\n >>> genmprim output.mprim\r\n
A window similar to the one shown below should appear which shows the motion primitives for a variety of angles. If you hit <enter> in the matlab window, you'll see the visualizations increment. As your keep on hitting <enter>, you'll see all the primitives that are generated.
\r\nDecoding the genmprim.m script
\r\nAt the top of the script, you'll see the following declarations:
\r\n\r\nif UNICYCLE_MPRIM_16DEGS == 1\r\n resolution = 0.025;\r\n numberofangles = 16; %preferably a power of 2, definitely multiple of 8\r\n numberofprimsperangle = 9;\r\n\r\n
Resolution denotes the resolution of your map.
\r\nnumberofangles denotes how many discrete states a full 360 degree rotation should be discretized into.
\r\nnumberofprimsperangle denotes how many different motions the robot can take for a given discretized angle.
\r\n![\"\"](\"../../media/images/mprims.png\")
To put these parameters into perspective, let's look at the labeled image above. The image shows motion primitives for 1 of the 16 discretized angles (angle = 0). There are 9 different paths the robot can take for a given angle, which are organized into the following categories: forward, forward and turn, sidestep, backward, and turn in place. Note that there are actually two turn in place actions (clockwise and counter clockwise), but this does not show up well in the image. Also, we have two motion primitives for moving forward: one that moves 1 unit, and another that moves 8 units (this tends to speed up the search if chosen well). Since the rotation is discretized into 16 states with 9 primitives for each, the robot will have a total of 144 motion primitives.
\r\nMultipliers
\r\n\r\n %multipliers (multiplier is used as costmult*cost)\r\n forwardcostmult = 1;\r\n backwardcostmult = 5;\r\n forwardandturncostmult = 1;\r\n sidestepcostmult = 50;\r\n turninplacecostmult = 50;\r\n\r\n
The multipliers allow the user to define preferred actions. For example, if the robot is slow to move backwards, one would raise the cost multiplier on the backwards cost.
\r\nMotion Vectors
\r\nIn order to define the actual motions, we use delta position vectors. The below is taken from genmprim_unicycleplussideways.
\r\n\r\n %note, what is shown x,y,theta *changes* (that is, dx,dy,dtheta and not absolute numbers)\r\n\r\n %0 degreees\r\n basemprimendpts0_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult\r\n %angles are positive counterclockwise\r\n %0 theta change\r\n basemprimendpts0_c(1,:) = [1 0 0 forwardcostmult];\r\n basemprimendpts0_c(2,:) = [8 0 0 forwardcostmult];\r\n basemprimendpts0_c(3,:) = [-1 0 0 backwardcostmult];\r\n %1/16 theta change\r\n basemprimendpts0_c(4,:) = [8 1 1 forwardandturncostmult];\r\n basemprimendpts0_c(5,:) = [8 -1 -1 forwardandturncostmult];\r\n %turn in place\r\n basemprimendpts0_c(6,:) = [0 0 1 turninplacecostmult];\r\n basemprimendpts0_c(7,:) = [0 0 -1 turninplacecostmult];\r\n %sideways maintaining the same heading\r\n basemprimendpts0_c(8,:) = [0 1 0 sidestepcostmult];\r\n basemprimendpts0_c(9,:) = [0 -1 0 sidestepcostmult];\r\n\r\n %45 degrees\r\n basemprimendpts45_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult (multiplier is used as costmult*cost)\r\n %angles are positive counterclockwise\r\n %0 theta change\r\n basemprimendpts45_c(1,:) = [1 1 0 forwardcostmult];\r\n basemprimendpts45_c(2,:) = [6 6 0 forwardcostmult];\r\n basemprimendpts45_c(3,:) = [-1 -1 0 backwardcostmult];\r\n %1/16 theta change\r\n basemprimendpts45_c(4,:) = [5 7 1 forwardandturncostmult];\r\n basemprimendpts45_c(5,:) = [7 5 -1 forwardandturncostmult];\r\n %turn in place\r\n basemprimendpts45_c(6,:) = [0 0 1 turninplacecostmult];\r\n basemprimendpts45_c(7,:) = [0 0 -1 turninplacecostmult];\r\n %sideways maintaining the same heading\r\n basemprimendpts45_c(8,:) = [-1 1 0 sidestepcostmult];\r\n basemprimendpts45_c(9,:) = [1 -1 0 sidestepcostmult];\r\n\r\n %22.5 degrees\r\n basemprimendpts22p5_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult (multiplier is used as costmult*cost)\r\n %angles are positive counterclockwise\r\n %0 theta change\r\n basemprimendpts22p5_c(1,:) = [2 1 0 forwardcostmult];\r\n basemprimendpts22p5_c(2,:) = [6 3 0 forwardcostmult];\r\n basemprimendpts22p5_c(3,:) = [-2 -1 0 backwardcostmult];\r\n %1/16 theta change\r\n basemprimendpts22p5_c(4,:) = [5 4 1 forwardandturncostmult];\r\n basemprimendpts22p5_c(5,:) = [7 2 -1 forwardandturncostmult];\r\n %turn in place\r\n basemprimendpts22p5_c(6,:) = [0 0 1 turninplacecostmult];\r\n basemprimendpts22p5_c(7,:) = [0 0 -1 turninplacecostmult];\r\n %sideways maintaining the same heading\r\n basemprimendpts22p5_c(8,:) = [-1 2 0 sidestepcostmult];\r\n basemprimendpts22p5_c(9,:) = [1 -2 0 sidestepcostmult];\r\n\r\n\r\n
Defining the motion primitives is a little bit tricky due to discretization problems. Intuitively, we'd expect to only define 9 motion primitives that would be used for all 16 of our discrete angles. However, due to angle discretization error, a motion primitive defined for a robot oriented at 0 degrees may not be the best motion primitive for a robot oriented at 22.5 degrees. We'll address why this is in a bit.
\r\nIn order to combat this, we define each angle (for one quadrant) explicitly. Since we have a total of 16 discretized angles, we can get away with defining 4 of the angles for quadrant one, and then duplicating the motions for the other three quadrants. Thus, we only need to define motion primitives for 4 angles: 0, 22.5, 45, and 67.5. We can take advantage of symmetry again and say that angles 22.5 and 67.5 can use the same set of motion primitives (as their discretization errors will be the same). In this code, we define motion primitives for 22.5 degrees.
\r\nNow, we only have to define motion primitives for 3 angles: 0, 22.5, and 45. With 9 motion primitives for each, this means we must define 27 motion primitives. Looking above, we see that there are indeed 27 definitions. Let's look at the definition for moving forward 8 units when the robot is oriented at 0 degrees:
\r\n\r\nbasemprimendpts0_c(2,:) = [8 0 0 forwardcostmult];\r\n
The format for this vector is [dx dy dtheta multiplier]. Since we're facing down the positive x-axis, we want dx=8, and everything else 0. For the same motion when the robot is oriented at 45 degrees, we use:
\r\n\r\nbasemprimendpts45_c(2,:) = [6 6 0 forwardcostmult];\r\n
Notice that the distance traversed is actually more than 8 (8.48). This is to counteract the previously described discretization error. This extra distance ensure that we land in the center of the discretized cell, rather than off to one corner. When designing your own motion primitives, it's important to make sure your motions land you in the centers of cells to avoid discontinuous paths. The image below depicts what happens when your motion primitives don't land in the middle of the cell - even though it's valid in discrete space, the continuous path is invalid (thanks Andrew Dornbush).
\r\n![\"\"](\"../../media/images/unaligned_mprims.png\")
Once you've defined your set of motion primitives, use the matlab visualization to ensure that the motions are correct. The generated file (usually ending with .mprim) is now ready for use by the SBPL planner!
\r\n", + "body_markdown": "In this article, we'll talk about how to generate motion primitves that SBPL uses for its lattice planning. For an introduction to motion primitives, see [this article](http://sbpl.net/node/48).\n\n**Visualizing motion primitives**\n\nIn the\n\n```\n\r\nmatlab/mprim/\n```\n\nfolder of sbpl, you'll find numerous files of the form\n\n```\n\r\ngenmprim_*\n```\n\nThese files generate different sets of motion primitives a robot could use. To start, open up matlab and run one of these:\n\n```\n\r\n >>> genmprim output.mprim\n```\n\nA window similar to the one shown below should appear which shows the motion primitives for a variety of angles. If you hitIn this article, we'll talk about how to generate motion primitves that SBPL uses for its lattice planning. For an introduction to motion primitives, see this article.
\r\nVisualizing motion primitives
\r\nIn the
\r\n\r\nmatlab/mprim/\r\n
folder of sbpl, you'll find numerous files of the form
\r\n\r\ngenmprim_*\r\n
These files generate different sets of motion primitives a robot could use. To start, open up matlab and run one of these:
\r\n\r\n >>> genmprim output.mprim\r\n
A window similar to the one shown below should appear which shows the motion primitives for a variety of angles. If you hit <enter> in the matlab window, you'll see the visualizations increment. As your keep on hitting <enter>, you'll see all the primitives that are generated.
\r\nDecoding the genmprim.m script
\r\nAt the top of the script, you'll see the following declarations:
\r\n\r\nif UNICYCLE_MPRIM_16DEGS == 1\r\n resolution = 0.025;\r\n numberofangles = 16; %preferably a power of 2, definitely multiple of 8\r\n numberofprimsperangle = 9;\r\n\r\n
Resolution denotes the resolution of your map.
\r\nnumberofangles denotes how many discrete states a full 360 degree rotation should be discretized into.
\r\nnumberofprimsperangle denotes how many different motions the robot can take for a given discretized angle.
\r\n![\"\"](\"/shared/Images/mprims.png\")
To put these parameters into perspective, let's look at the labeled image above. The image shows motion primitives for 1 of the 16 discretized angles (angle = 0). There are 9 different paths the robot can take for a given angle, which are organized into the following categories: forward, forward and turn, sidestep, backward, and turn in place. Note that there are actually two turn in place actions (clockwise and counter clockwise), but this does not show up well in the image. Also, we have two motion primitives for moving forward: one that moves 1 unit, and another that moves 8 units (this tends to speed up the search if chosen well). Since the rotation is discretized into 16 states with 9 primitives for each, the robot will have a total of 144 motion primitives.
\r\nMultipliers
\r\n\r\n %multipliers (multiplier is used as costmult*cost)\r\n forwardcostmult = 1;\r\n backwardcostmult = 5;\r\n forwardandturncostmult = 1;\r\n sidestepcostmult = 50;\r\n turninplacecostmult = 50;\r\n\r\n
The multipliers allow the user to define preferred actions. For example, if the robot is slow to move backwards, one would raise the cost multiplier on the backwards cost.
\r\nMotion Vectors
\r\nIn order to define the actual motions, we use delta position vectors. The below is taken from genmprim_unicycleplussideways.
\r\n\r\n %note, what is shown x,y,theta *changes* (that is, dx,dy,dtheta and not absolute numbers)\r\n\r\n %0 degreees\r\n basemprimendpts0_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult\r\n %angles are positive counterclockwise\r\n %0 theta change\r\n basemprimendpts0_c(1,:) = [1 0 0 forwardcostmult];\r\n basemprimendpts0_c(2,:) = [8 0 0 forwardcostmult];\r\n basemprimendpts0_c(3,:) = [-1 0 0 backwardcostmult];\r\n %1/16 theta change\r\n basemprimendpts0_c(4,:) = [8 1 1 forwardandturncostmult];\r\n basemprimendpts0_c(5,:) = [8 -1 -1 forwardandturncostmult];\r\n %turn in place\r\n basemprimendpts0_c(6,:) = [0 0 1 turninplacecostmult];\r\n basemprimendpts0_c(7,:) = [0 0 -1 turninplacecostmult];\r\n %sideways maintaining the same heading\r\n basemprimendpts0_c(8,:) = [0 1 0 sidestepcostmult];\r\n basemprimendpts0_c(9,:) = [0 -1 0 sidestepcostmult];\r\n\r\n %45 degrees\r\n basemprimendpts45_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult (multiplier is used as costmult*cost)\r\n %angles are positive counterclockwise\r\n %0 theta change\r\n basemprimendpts45_c(1,:) = [1 1 0 forwardcostmult];\r\n basemprimendpts45_c(2,:) = [6 6 0 forwardcostmult];\r\n basemprimendpts45_c(3,:) = [-1 -1 0 backwardcostmult];\r\n %1/16 theta change\r\n basemprimendpts45_c(4,:) = [5 7 1 forwardandturncostmult];\r\n basemprimendpts45_c(5,:) = [7 5 -1 forwardandturncostmult];\r\n %turn in place\r\n basemprimendpts45_c(6,:) = [0 0 1 turninplacecostmult];\r\n basemprimendpts45_c(7,:) = [0 0 -1 turninplacecostmult];\r\n %sideways maintaining the same heading\r\n basemprimendpts45_c(8,:) = [-1 1 0 sidestepcostmult];\r\n basemprimendpts45_c(9,:) = [1 -1 0 sidestepcostmult];\r\n\r\n %22.5 degrees\r\n basemprimendpts22p5_c = zeros(numberofprimsperangle, 4); %x,y,theta,costmult (multiplier is used as costmult*cost)\r\n %angles are positive counterclockwise\r\n %0 theta change\r\n basemprimendpts22p5_c(1,:) = [2 1 0 forwardcostmult];\r\n basemprimendpts22p5_c(2,:) = [6 3 0 forwardcostmult];\r\n basemprimendpts22p5_c(3,:) = [-2 -1 0 backwardcostmult];\r\n %1/16 theta change\r\n basemprimendpts22p5_c(4,:) = [5 4 1 forwardandturncostmult];\r\n basemprimendpts22p5_c(5,:) = [7 2 -1 forwardandturncostmult];\r\n %turn in place\r\n basemprimendpts22p5_c(6,:) = [0 0 1 turninplacecostmult];\r\n basemprimendpts22p5_c(7,:) = [0 0 -1 turninplacecostmult];\r\n %sideways maintaining the same heading\r\n basemprimendpts22p5_c(8,:) = [-1 2 0 sidestepcostmult];\r\n basemprimendpts22p5_c(9,:) = [1 -2 0 sidestepcostmult];\r\n\r\n\r\n
Defining the motion primitives is a little bit tricky due to discretization problems. Intuitively, we'd expect to only define 9 motion primitives that would be used for all 16 of our discrete angles. However, due to angle discretization error, a motion primitive defined for a robot oriented at 0 degrees may not be the best motion primitive for a robot oriented at 22.5 degrees. We'll address why this is in a bit.
\r\nIn order to combat this, we define each angle (for one quadrant) explicitly. Since we have a total of 16 discretized angles, we can get away with defining 4 of the angles for quadrant one, and then duplicating the motions for the other three quadrants. Thus, we only need to define motion primitives for 4 angles: 0, 22.5, 45, and 67.5. We can take advantage of symmetry again and say that angles 22.5 and 67.5 can use the same set of motion primitives (as their discretization errors will be the same). In this code, we define motion primitives for 22.5 degrees.
\r\nNow, we only have to define motion primitives for 3 angles: 0, 22.5, and 45. With 9 motion primitives for each, this means we must define 27 motion primitives. Looking above, we see that there are indeed 27 definitions. Let's look at the definition for moving forward 8 units when the robot is oriented at 0 degrees:
\r\n\r\nbasemprimendpts0_c(2,:) = [8 0 0 forwardcostmult];\r\n
The format for this vector is [dx dy dtheta multiplier]. Since we're facing down the positive x-axis, we want dx=8, and everything else 0. For the same motion when the robot is oriented at 45 degrees, we use:
\r\n\r\nbasemprimendpts45_c(2,:) = [6 6 0 forwardcostmult];\r\n
Notice that the distance traversed is actually more than 8 (8.48). This is to counteract the previously described discretization error. This extra distance ensure that we land in the center of the discretized cell, rather than off to one corner. When designing your own motion primitives, it's important to make sure your motions land you in the centers of cells to avoid discontinuous paths. The image below depicts what happens when your motion primitives don't land in the middle of the cell - even though it's valid in discrete space, the continuous path is invalid (thanks Andrew Dornbush).
\r\n![\"\"](\"/shared/Images/unaligned_mprims.png\")
Once you've defined your set of motion primitives, use the matlab visualization to ensure that the motions are correct. The generated file (usually ending with .mprim) is now ready for use by the SBPL planner!
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.md b/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.md new file mode 100644 index 0000000..8aa5379 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0052-generating-motion-primitives-with-sbpl.md @@ -0,0 +1,152 @@ +# Generating Motion Primitives with SBPL + +In this article, we'll talk about how to generate motion primitves that SBPL uses for its lattice planning. For an introduction to motion primitives, see [this article](http://sbpl.net/node/48). + +**Visualizing motion primitives** + +In the + +``` + +matlab/mprim/ +``` + +folder of sbpl, you'll find numerous files of the form + +``` + +genmprim_* +``` + +These files generate different sets of motion primitives a robot could use. To start, open up matlab and run one of these: + +``` + + >>> genmprim output.mprim +``` + +A window similar to the one shown below should appear which shows the motion primitives for a variety of angles. If you hit+
SBPL Lattice Planner generates a path from start to goal by combining a series of pre-defined motion primitives. SBPL provides several matlab scripts that can be used to build motion primitives for different types of vehicles. For example, the matlab script named genmprim_unicycle.m constructs forward, backward, turn-in-place, and forward-turn-arc motion primitives for a unicycle robot in the 3D state space (x,y,θ). In this tutorial we describe how the genmprim_unicycle.m script calculates the forward-turn-arc motion primitive given the start and the end poses.
+The task of the SBPL Lattice Planner is to generate a smooth kinematically feasible trajectory or path, that a robot can safely follow to reach its goal pose. This trajectory is represented as a series of connected states in a lattice-based graph constructed using motion primitives and efficient search algorithms. A lattice-based graph is a graph constructed using short motion primitives as edges that end up at the center of cells. Motion primitives are short, kinematically feasible motions which form the basis of movements that can be performed by the robot platform.
+Figure 1 shows the base set of motion primitives used by the planner (left), the lattice-based graph construction process (middle), and the final generated path (right). Each state is represented in the 3D space by a pose with two-dimensional coordinates (x,y) and orientation θ.
++
+
The genmprim_unicycle.m matlab script constructs a set of motion primitives that enable a robot to move straight forward, straight backward, turn in place by a certain angle and move forward and turn by a certain angle. The script generates primitives for a discrete set of turning angles φ, varying from 0 to 2π radians. The set of primitives generated for each turning angle φ can include two forward primitives (short and long), one backward primitive (short), two turn in place primitives (clockwise and counterclockwise) and two forward-turn-arc primitives (clockwise and counterclockwise). All motion primitives share the same starting point (x = 0, y = 0), but have different starting orientations. Motion primitives within the same set have the same starting orientation (θ = φ) equal to the turning angle of the set. Each individual motion primitive is defined by its type, its start pose, its end pose and contains a dense sequence of poses forming a trajectory in the 3D space (x,y,θ). The matlab script writes all generated primitive trajectories into a file. This file is later used by the SBPL Lattice Planner to generate trajectories.
+The matlab script uses several configurable parameters:
+
and the set of turning angles as φ = kδ, where 0 ≤ k ≤ numberofangles−1.The turning angle of the motion primitive set (φ) and the base turning angle (δ) together define the orientation (θ) of the end pose for each motion primitive in the set:
+
+  |
+ + (1) | +
The script defines a set of end poses for a subset of starting angles in the first quadrant. These form the basis for all motion primitives that are generated for a discrete set of angles.
+In the script, each of these arrays of end poses is defined as an array of four-dimensional vectors (i,j,n,costmultiplier), where i and j specify x and y coordinates of the end pose in grid units (x = i∗resolution, y = j∗resolution), n determines the orientation of the end pose (see (1)) and costmultiplier is a cost multiplier value used by the SBPL Lattice Planner to penalize certain types of motion primitives.
+It is important for each motion primitive to start and end exactly in the center of a grid cell to avoid having discontinuities in the path generated by the lattice planner. (As an implementation detail, the matlab script actually generates primitives that start and end at the corners of grid cells. The planner then shifts motion primitive trajectories by 0.5∗resolution in each direction to move their start/end points to the centers of the grid cells.)
+The rest of motion primitives are constructed as a result of symmetrical rotation of one of the base primitives around the origin by a certain angle which is a multiple of the base turning angle (δ). The disposition of the end pose relative to the origin determines the shape, the length and the turning angle of the primitive. By specifying appropriate end pose and base turning angle, we can control the kinematic feasibility of motion primitives.
+In each set, the forward and backward primitives have fixed orientation and are represented by simple straight line segments. The two turn in place primitives have (x,y) coordinates of the end pose equal to (x,y) coordinates of the start pose, and simply demonstrate change in the orientation. The two forward-turn-arc primitives have ending orientations symmetrical with respect to the forward primitive: θ1,2 = φ ± δ. Due to the requirement to reach exactly the given end pose (x,y,θ), each forward-turn-arc primitive is constructed as combination of two movements: a forward straight line segment followed by an arc of a circle. Figure 2 illustrates the base set of motion primitives for turning angle φ = 0∘. Figure 3 displays the full set of motion primitives generated by the genmprim_unicycle.m matlab script.
+The matlab scripts records information about all generated motion primitives into a file specified by outfilename. First it writes data related to all motion primitives:
+Then in a loop, the scripts outputs information applicable to each individual motion primitive:
++
+
+
+
In the following sections we describe how to build a single forward-turn-arc motion primitive. The trajectory of this motion primitive must satisfy the following requirements:
++
0 ≤
≤
g this can be achieved using the following parameter transformation: t = 
, v = 
, ω = 
, Δ = 
g −
0.To build a motion primitive, we need to determine values of l,r,v,ω and tl.
+The length of the path, traveled by the robot at any given time, is s(t) = vt. Specifically for t = tl, l = vtl.
+When following the arc, the robot’s turning angle at any given time is Δθ(t) = θ(t) − θ0 = ω(t − tl) and the length of the arc is sarc(t) = rΔθ(t) = rω(t − tl). From the latter, r = 
= 
.
Figure 4 displays the sample forward-turn-arc motion primitive trajectory.
++
+
Consider the case of when the robot follows the straight line segment of the motion primitive with the fixed velocity v and the fixed heading θ0. As shown on Figure 5, this behavior can be described by the following equations:
+
Substituting t = tl and l = vtl into (2), we get equations for the last pose of the straight line segment:
+
+
Now consider the case of when the robot follows the arc of the circle with the fixed velocity v and the fixed rotational velocity ω. Derivatives 
and 
give us components of the robot’s velocity vx (in the direction of the x-axis) and vy (in the direction of the y-axis), correspondingly. As shown on Figure 6, we have the following system of three differential equations:
+  |
+ + (4) | +
+
+
Integrating the last equation of (4), we receive:
+
+  |
+ + (5) | +
Substituting (5) into (4) gives us:
+
+  |
+ + (6) | +
Integrating (6), we receive:
+
+  |
+ + (7) | +
From (7), (3) and using r = 
, we get:
+  |
+ + (8) | +
Substituting t = tg = 1 into (8), we have:
+
+  |
+ + (9) | +
The (9) is a system of two linear equation involving variables l and r. It can be expressed in the matrix form:
+
+  |
+ + (10) | +
The system (10) has a unique solution:
+
+  |
+ + (11) | +
By definition, ω = 
. Using tl = 
and r = 
, we finally get:
+  |
+ + (12) | +
+
In the previous sections we derived formulas for all initially unknown motion parameters. Specifically using (11), we can find the length of the straight line segment (l) and the turning radius (r). From (12) we can determine both the rotational (ω) and the translational (v) velocities. Finally, using tl = 
we can calculate the time, corresponding to the end of the straight line segment.
The next step is to build the motion primitive trajectory. As defined earlier in this tutorial, the numofsamples is the given number of discrete poses required on the motion primitive trajectory. Let Δt be a time step between sequential discrete poses of the trajectory. Hence Δt = 
. To build the motion primitive trajectory, we iterate over t = iΔt, where 0 ≤ i ≤ numofsamples-1 and use an appropriate formula to calculate each discrete pose. Specifically for t ≤ tl, we use (2) to construct the straight line segment of the motion primitive, then for tl ≤ t ≤ 1, use (8) to construct the arc portion of the motion primitive.
\r\n
SBPL Lattice Planner generates a path from start to goal by combining a series of pre-defined motion primitives. SBPL provides several matlab scripts that can be used to build motion primitives for different types of vehicles. For example, the matlab script named genmprim_unicycle.m constructs forward, backward, turn-in-place, and forward-turn-arc motion primitives for a unicycle robot in the 3D state space (x,y,θ). In this tutorial we describe how the genmprim_unicycle.m script calculates the forward-turn-arc motion primitive given the start and the end poses.
\r\nThe task of the SBPL Lattice Planner is to generate a smooth kinematically feasible trajectory or path, that a robot can safely follow to reach its goal pose. This trajectory is represented as a series of connected states in a lattice-based graph constructed using motion primitives and efficient search algorithms. A lattice-based graph is a graph constructed using short motion primitives as edges that end up at the center of cells. Motion primitives are short, kinematically feasible motions which form the basis of movements that can be performed by the robot platform.
\r\nFigure 1 shows the base set of motion primitives used by the planner (left), the lattice-based graph construction process (middle), and the final generated path (right). Each state is represented in the 3D space by a pose with two-dimensional coordinates (x,y) and orientation θ.
\r\n\r\n
![\"PIC\"](\"../../media/images/PathGen.jpg\")
\r\n
The genmprim_unicycle.m matlab script constructs a set of motion primitives that enable a robot to move straight forward, straight backward, turn in place by a certain angle and move forward and turn by a certain angle. The script generates primitives for a discrete set of turning angles φ, varying from 0 to 2π radians. The set of primitives generated for each turning angle φ can include two forward primitives (short and long), one backward primitive (short), two turn in place primitives (clockwise and counterclockwise) and two forward-turn-arc primitives (clockwise and counterclockwise). All motion primitives share the same starting point (x = 0, y = 0), but have different starting orientations. Motion primitives within the same set have the same starting orientation (θ = φ) equal to the turning angle of the set. Each individual motion primitive is defined by its type, its start pose, its end pose and contains a dense sequence of poses forming a trajectory in the 3D space (x,y,θ). The matlab script writes all generated primitive trajectories into a file. This file is later used by the SBPL Lattice Planner to generate trajectories.
\r\nThe matlab script uses several configurable parameters:
\r\n![\"numbe2roπfangles\"](\"../../media/images/LatextDoc10x.png\")
and the set of turning angles as φ = kδ, where 0 ≤ k ≤ numberofangles−1.The turning angle of the motion primitive set (φ) and the base turning angle (δ) together define the orientation (θ) of the end pose for each motion primitive in the set:
\r\n\r\n\t\t\t\t![\"θ](\"../../media/images/LatextDoc11x.png\") | \r\n\t\t\t\r\n\t\t\t\t(1) | \r\n\t\t
The script defines a set of end poses for a subset of starting angles in the first quadrant. These form the basis for all motion primitives that are generated for a discrete set of angles.
\r\nIn the script, each of these arrays of end poses is defined as an array of four-dimensional vectors (i,j,n,costmultiplier), where i and j specify x and y coordinates of the end pose in grid units (x = i∗resolution, y = j∗resolution), n determines the orientation of the end pose (see (1)) and costmultiplier is a cost multiplier value used by the SBPL Lattice Planner to penalize certain types of motion primitives.
\r\nIt is important for each motion primitive to start and end exactly in the center of a grid cell to avoid having discontinuities in the path generated by the lattice planner. (As an implementation detail, the matlab script actually generates primitives that start and end at the corners of grid cells. The planner then shifts motion primitive trajectories by 0.5∗resolution in each direction to move their start/end points to the centers of the grid cells.)
\r\nThe rest of motion primitives are constructed as a result of symmetrical rotation of one of the base primitives around the origin by a certain angle which is a multiple of the base turning angle (δ). The disposition of the end pose relative to the origin determines the shape, the length and the turning angle of the primitive. By specifying appropriate end pose and base turning angle, we can control the kinematic feasibility of motion primitives.
\r\nIn each set, the forward and backward primitives have fixed orientation and are represented by simple straight line segments. The two turn in place primitives have (x,y) coordinates of the end pose equal to (x,y) coordinates of the start pose, and simply demonstrate change in the orientation. The two forward-turn-arc primitives have ending orientations symmetrical with respect to the forward primitive: θ1,2 = φ ± δ. Due to the requirement to reach exactly the given end pose (x,y,θ), each forward-turn-arc primitive is constructed as combination of two movements: a forward straight line segment followed by an arc of a circle. Figure 2 illustrates the base set of motion primitives for turning angle φ = 0∘. Figure 3 displays the full set of motion primitives generated by the genmprim_unicycle.m matlab script.
\r\nThe matlab scripts records information about all generated motion primitives into a file specified by outfilename. First it writes data related to all motion primitives:
\r\nThen in a loop, the scripts outputs information applicable to each individual motion primitive:
\r\n\r\n
![\"PIC\"](\"../../media/images/BasePrim.jpg\")
\r\n
\r\n
![\"PIC\"](\"../../media/images/MotionPrimitives.jpg\")
\r\n
In the following sections we describe how to build a single forward-turn-arc motion primitive. The trajectory of this motion primitive must satisfy the following requirements:
\r\n\r\n
![\"˜t\"](\"../../media/images/LatextDoc12x.png\")
0 ≤![\"˜t\"](\"../../media/images/LatextDoc13x.png\")
≤![\"˜t\"](\"../../media/images/LatextDoc14x.png\")
g this can be achieved using the following parameter transformation: t = ![\"˜t−˜t-Δ-0\"](\"../../media/images/LatextDoc15x.png\")
, v = ![\"vΔ˜\"](\"../../media/images/LatextDoc16x.png\")
, ω = ![\"Δ˜ω\"](\"../../media/images/LatextDoc17x.png\")
, Δ = ![\"˜t\"](\"../../media/images/LatextDoc18x.png\")
g −![\"˜t\"](\"../../media/images/LatextDoc19x.png\")
0.To build a motion primitive, we need to determine values of l,r,v,ω and tl.
\r\nThe length of the path, traveled by the robot at any given time, is s(t) = vt. Specifically for t = tl, l = vtl.
\r\nWhen following the arc, the robot’s turning angle at any given time is Δθ(t) = θ(t) − θ0 = ω(t − tl) and the length of the arc is sarc(t) = rΔθ(t) = rω(t − tl). From the latter, r = ![\"sarc(t)](\"../../media/images/LatextDoc110x.png\")
![\"1-ω\"](\"../../media/images/LatextDoc111x.png\")
= ![\"v-ω\"](\"../../media/images/LatextDoc112x.png\")
.
Figure 4 displays the sample forward-turn-arc motion primitive trajectory.
\r\n\r\n
![\"PIC\"](\"../../media/images/fig1.jpg\")
\r\n
Consider the case of when the robot follows the straight line segment of the motion primitive with the fixed velocity v and the fixed heading θ0. As shown on Figure 5, this behavior can be described by the following equations:
\r\n![\"x(t)](\"../../media/images/LatextDoc113x.png\")
Substituting t = tl and l = vtl into (2), we get equations for the last pose of the straight line segment:
\r\n![\"x](\"../../media/images/LatextDoc114x.png\")
![\"PIC\"](\"../../media/images/fig2.jpg\")
\r\n
Now consider the case of when the robot follows the arc of the circle with the fixed velocity v and the fixed rotational velocity ω. Derivatives ![\"ddxt\"](\"../../media/images/LatextDoc115x.png\")
and ![\"ddyt\"](\"../../media/images/LatextDoc116x.png\")
give us components of the robot’s velocity vx (in the direction of the x-axis) and vy (in the direction of the y-axis), correspondingly. As shown on Figure 6, we have the following system of three differential equations:
\r\n\t\t\t\t![\"dx-dt](\"../../media/images/LatextDoc117x.png\") | \r\n\t\t\t\r\n\t\t\t\t(4) | \r\n\t\t
\r\n
![\"PIC\"](\"../../media/images/fig3.jpg\")
\r\n
Integrating the last equation of (4), we receive:
\r\n\r\n\t\t\t\t![\"](\"../../media/images/LatextDoc118x.png\") | \r\n\t\t\t\r\n\t\t\t\t(5) | \r\n\t\t
Substituting (5) into (4) gives us:
\r\n\r\n\t\t\t\t![\"dx-dt](\"../../media/images/LatextDoc119x.png\") | \r\n\t\t\t\r\n\t\t\t\t(6) | \r\n\t\t
Integrating (6), we receive:
\r\n\r\n\t\t\t\t![\"](\"../../media/images/LatextDoc120x.png\") | \r\n\t\t\t\r\n\t\t\t\t(7) | \r\n\t\t
From (7), (3) and using r = ![\"v-ω\"](\"../../media/images/LatextDoc121x.png\")
, we get:
\r\n\t\t\t\t![\"x(t)](\"../../media/images/LatextDoc122x.png\") | \r\n\t\t\t\r\n\t\t\t\t(8) | \r\n\t\t
Substituting t = tg = 1 into (8), we have:
\r\n\r\n\t\t\t\t![\"xg](\"../../media/images/LatextDoc123x.png\") | \r\n\t\t\t\r\n\t\t\t\t(9) | \r\n\t\t
The (9) is a system of two linear equation involving variables l and r. It can be expressed in the matrix form:
\r\n\r\n\t\t\t\t![\"B](\"../../media/images/LatextDoc124x.png\") | \r\n\t\t\t\r\n\t\t\t\t(10) | \r\n\t\t
The system (10) has a unique solution:
\r\n\r\n\t\t\t\t![\"](\"../../media/images/LatextDoc125x.png\") | \r\n\t\t\t\r\n\t\t\t\t(11) | \r\n\t\t
By definition, ω = ![\"θg−-θ0-1−tl\"](\"../../media/images/LatextDoc126x.png\")
. Using tl = ![\"lv\"](\"../../media/images/LatextDoc127x.png\")
and r = ![\"v-ω\"](\"../../media/images/LatextDoc128x.png\")
, we finally get:
\r\n\t\t\t\t![\"](\"../../media/images/LatextDoc129x.png\") | \r\n\t\t\t\r\n\t\t\t\t(12) | \r\n\t\t
\r\n
In the previous sections we derived formulas for all initially unknown motion parameters. Specifically using (11), we can find the length of the straight line segment (l) and the turning radius (r). From (12) we can determine both the rotational (ω) and the translational (v) velocities. Finally, using tl = ![\"lv\"](\"../../media/images/LatextDoc130x.png\")
we can calculate the time, corresponding to the end of the straight line segment.
The next step is to build the motion primitive trajectory. As defined earlier in this tutorial, the numofsamples is the given number of discrete poses required on the motion primitive trajectory. Let Δt be a time step between sequential discrete poses of the trajectory. Hence Δt = ![\"-----1------numofsamples−](\"../../media/images/LatextDoc131x.png\")
. To build the motion primitive trajectory, we iterate over t = iΔt, where 0 ≤ i ≤ numofsamples-1 and use an appropriate formula to calculate each discrete pose. Specifically for t ≤ tl, we use (2) to construct the straight line segment of the motion primitive, then for tl ≤ t ≤ 1, use (8) to construct the arc portion of the motion primitive.
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(1) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(4) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(5) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(6) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(7) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(8) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(9) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(10) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(11) | \r\n\t\t
| \r\n\t\t\t\t | \r\n\t\t\t\r\n\t\t\t\t(12) | \r\n\t\t
\r\n
SBPL Lattice Planner generates a path from start to goal by combining a series of pre-defined motion primitives. SBPL provides several matlab scripts that can be used to build motion primitives for different types of vehicles. For example, the matlab script named genmprim_unicycle.m constructs forward, backward, turn-in-place, and forward-turn-arc motion primitives for a unicycle robot in the 3D state space (x,y,θ). In this tutorial we describe how the genmprim_unicycle.m script calculates the forward-turn-arc motion primitive given the start and the end poses.
\r\nThe task of the SBPL Lattice Planner is to generate a smooth kinematically feasible trajectory or path, that a robot can safely follow to reach its goal pose. This trajectory is represented as a series of connected states in a lattice-based graph constructed using motion primitives and efficient search algorithms. A lattice-based graph is a graph constructed using short motion primitives as edges that end up at the center of cells. Motion primitives are short, kinematically feasible motions which form the basis of movements that can be performed by the robot platform.
\r\nFigure 1 shows the base set of motion primitives used by the planner (left), the lattice-based graph construction process (middle), and the final generated path (right). Each state is represented in the 3D space by a pose with two-dimensional coordinates (x,y) and orientation θ.
\r\n\r\n
![\"PIC\"](\"/shared/Images/PathGen.jpg\")
\r\n
The genmprim_unicycle.m matlab script constructs a set of motion primitives that enable a robot to move straight forward, straight backward, turn in place by a certain angle and move forward and turn by a certain angle. The script generates primitives for a discrete set of turning angles φ, varying from 0 to 2π radians. The set of primitives generated for each turning angle φ can include two forward primitives (short and long), one backward primitive (short), two turn in place primitives (clockwise and counterclockwise) and two forward-turn-arc primitives (clockwise and counterclockwise). All motion primitives share the same starting point (x = 0, y = 0), but have different starting orientations. Motion primitives within the same set have the same starting orientation (θ = φ) equal to the turning angle of the set. Each individual motion primitive is defined by its type, its start pose, its end pose and contains a dense sequence of poses forming a trajectory in the 3D space (x,y,θ). The matlab script writes all generated primitive trajectories into a file. This file is later used by the SBPL Lattice Planner to generate trajectories.
\r\nThe matlab script uses several configurable parameters:
\r\n![\"numbe2roπfangles\"](\"/shared/Images/LatextDoc10x.png\")
and the set of turning angles as φ = kδ, where 0 ≤ k ≤ numberofangles−1.The turning angle of the motion primitive set (φ) and the base turning angle (δ) together define the orientation (θ) of the end pose for each motion primitive in the set:
\r\n\r\n\t\t\t\t![\"θ](\"/shared/Images/LatextDoc11x.png\") | \r\n\t\t\t\r\n\t\t\t\t(1) | \r\n\t\t
The script defines a set of end poses for a subset of starting angles in the first quadrant. These form the basis for all motion primitives that are generated for a discrete set of angles.
\r\nIn the script, each of these arrays of end poses is defined as an array of four-dimensional vectors (i,j,n,costmultiplier), where i and j specify x and y coordinates of the end pose in grid units (x = i∗resolution, y = j∗resolution), n determines the orientation of the end pose (see (1)) and costmultiplier is a cost multiplier value used by the SBPL Lattice Planner to penalize certain types of motion primitives.
\r\nIt is important for each motion primitive to start and end exactly in the center of a grid cell to avoid having discontinuities in the path generated by the lattice planner. (As an implementation detail, the matlab script actually generates primitives that start and end at the corners of grid cells. The planner then shifts motion primitive trajectories by 0.5∗resolution in each direction to move their start/end points to the centers of the grid cells.)
\r\nThe rest of motion primitives are constructed as a result of symmetrical rotation of one of the base primitives around the origin by a certain angle which is a multiple of the base turning angle (δ). The disposition of the end pose relative to the origin determines the shape, the length and the turning angle of the primitive. By specifying appropriate end pose and base turning angle, we can control the kinematic feasibility of motion primitives.
\r\nIn each set, the forward and backward primitives have fixed orientation and are represented by simple straight line segments. The two turn in place primitives have (x,y) coordinates of the end pose equal to (x,y) coordinates of the start pose, and simply demonstrate change in the orientation. The two forward-turn-arc primitives have ending orientations symmetrical with respect to the forward primitive: θ1,2 = φ ± δ. Due to the requirement to reach exactly the given end pose (x,y,θ), each forward-turn-arc primitive is constructed as combination of two movements: a forward straight line segment followed by an arc of a circle. Figure 2 illustrates the base set of motion primitives for turning angle φ = 0∘. Figure 3 displays the full set of motion primitives generated by the genmprim_unicycle.m matlab script.
\r\nThe matlab scripts records information about all generated motion primitives into a file specified by outfilename. First it writes data related to all motion primitives:
\r\nThen in a loop, the scripts outputs information applicable to each individual motion primitive:
\r\n\r\n
![\"PIC\"](\"/shared/Images/BasePrim.jpg\")
\r\n
\r\n
![\"PIC\"](\"/shared/Images/MotionPrimitives.jpg\")
\r\n
In the following sections we describe how to build a single forward-turn-arc motion primitive. The trajectory of this motion primitive must satisfy the following requirements:
\r\n\r\n
![\"˜t\"](\"/shared/Images/LatextDoc12x.png\")
0 ≤![\"˜t\"](\"/shared/Images/LatextDoc13x.png\")
≤![\"˜t\"](\"/shared/Images/LatextDoc14x.png\")
g this can be achieved using the following parameter transformation: t = ![\"˜t−˜t-Δ-0\"](\"/shared/Images/LatextDoc15x.png\")
, v = ![\"vΔ˜\"](\"/shared/Images/LatextDoc16x.png\")
, ω = ![\"Δ˜ω\"](\"/shared/Images/LatextDoc17x.png\")
, Δ = ![\"˜t\"](\"/shared/Images/LatextDoc18x.png\")
g −![\"˜t\"](\"/shared/Images/LatextDoc19x.png\")
0.To build a motion primitive, we need to determine values of l,r,v,ω and tl.
\r\nThe length of the path, traveled by the robot at any given time, is s(t) = vt. Specifically for t = tl, l = vtl.
\r\nWhen following the arc, the robot’s turning angle at any given time is Δθ(t) = θ(t) − θ0 = ω(t − tl) and the length of the arc is sarc(t) = rΔθ(t) = rω(t − tl). From the latter, r = ![\"sarc(t)](\"/shared/Images/LatextDoc110x.png\")
![\"1-ω\"](\"/shared/Images/LatextDoc111x.png\")
= ![\"v-ω\"](\"/shared/Images/LatextDoc112x.png\")
.
Figure 4 displays the sample forward-turn-arc motion primitive trajectory.
\r\n\r\n
![\"PIC\"](\"/shared/Images/fig1.jpg\")
\r\n
Consider the case of when the robot follows the straight line segment of the motion primitive with the fixed velocity v and the fixed heading θ0. As shown on Figure 5, this behavior can be described by the following equations:
\r\n![\"x(t)](\"/shared/Images/LatextDoc113x.png\")
Substituting t = tl and l = vtl into (2), we get equations for the last pose of the straight line segment:
\r\n![\"x](\"/shared/Images/LatextDoc114x.png\")
![\"PIC\"](\"/shared/Images/fig2.jpg\")
\r\n
Now consider the case of when the robot follows the arc of the circle with the fixed velocity v and the fixed rotational velocity ω. Derivatives ![\"ddxt\"](\"/shared/Images/LatextDoc115x.png\")
and ![\"ddyt\"](\"/shared/Images/LatextDoc116x.png\")
give us components of the robot’s velocity vx (in the direction of the x-axis) and vy (in the direction of the y-axis), correspondingly. As shown on Figure 6, we have the following system of three differential equations:
\r\n\t\t\t\t![\"dx-dt](\"/shared/Images/LatextDoc117x.png\") | \r\n\t\t\t\r\n\t\t\t\t(4) | \r\n\t\t
\r\n
![\"PIC\"](\"/shared/Images/fig3.jpg\")
\r\n
Integrating the last equation of (4), we receive:
\r\n\r\n\t\t\t\t![\"](\"/shared/Images/LatextDoc118x.png\") | \r\n\t\t\t\r\n\t\t\t\t(5) | \r\n\t\t
Substituting (5) into (4) gives us:
\r\n\r\n\t\t\t\t![\"dx-dt](\"/shared/Images/LatextDoc119x.png\") | \r\n\t\t\t\r\n\t\t\t\t(6) | \r\n\t\t
Integrating (6), we receive:
\r\n\r\n\t\t\t\t![\"](\"/shared/Images/LatextDoc120x.png\") | \r\n\t\t\t\r\n\t\t\t\t(7) | \r\n\t\t
From (7), (3) and using r = ![\"v-ω\"](\"/shared/Images/LatextDoc121x.png\")
, we get:
\r\n\t\t\t\t![\"x(t)](\"/shared/Images/LatextDoc122x.png\") | \r\n\t\t\t\r\n\t\t\t\t(8) | \r\n\t\t
Substituting t = tg = 1 into (8), we have:
\r\n\r\n\t\t\t\t![\"xg](\"/shared/Images/LatextDoc123x.png\") | \r\n\t\t\t\r\n\t\t\t\t(9) | \r\n\t\t
The (9) is a system of two linear equation involving variables l and r. It can be expressed in the matrix form:
\r\n\r\n\t\t\t\t![\"B](\"/shared/Images/LatextDoc124x.png\") | \r\n\t\t\t\r\n\t\t\t\t(10) | \r\n\t\t
The system (10) has a unique solution:
\r\n\r\n\t\t\t\t![\"](\"/shared/Images/LatextDoc125x.png\") | \r\n\t\t\t\r\n\t\t\t\t(11) | \r\n\t\t
By definition, ω = ![\"θg−-θ0-1−tl\"](\"/shared/Images/LatextDoc126x.png\")
. Using tl = ![\"lv\"](\"/shared/Images/LatextDoc127x.png\")
and r = ![\"v-ω\"](\"/shared/Images/LatextDoc128x.png\")
, we finally get:
\r\n\t\t\t\t![\"](\"/shared/Images/LatextDoc129x.png\") | \r\n\t\t\t\r\n\t\t\t\t(12) | \r\n\t\t
\r\n
In the previous sections we derived formulas for all initially unknown motion parameters. Specifically using (11), we can find the length of the straight line segment (l) and the turning radius (r). From (12) we can determine both the rotational (ω) and the translational (v) velocities. Finally, using tl = ![\"lv\"](\"/shared/Images/LatextDoc130x.png\")
we can calculate the time, corresponding to the end of the straight line segment.
The next step is to build the motion primitive trajectory. As defined earlier in this tutorial, the numofsamples is the given number of discrete poses required on the motion primitive trajectory. Let Δt be a time step between sequential discrete poses of the trajectory. Hence Δt = ![\"-----1------numofsamples−](\"/shared/Images/LatextDoc131x.png\")
. To build the motion primitive trajectory, we iterate over t = iΔt, where 0 ≤ i ≤ numofsamples-1 and use an appropriate formula to calculate each discrete pose. Specifically for t ≤ tl, we use (2) to construct the straight line segment of the motion primitive, then for tl ≤ t ≤ 1, use (8) to construct the arc portion of the motion primitive.
|
+ |
+ + (1) | +
|
+ |
+ + (4) | +
|
+ |
+ + (5) | +
|
+ |
+ + (6) | +
|
+ |
+ + (7) | +
|
+ |
+ + (8) | +
|
+ |
+ + (9) | +
|
+ |
+ + (10) | +
|
+ |
+ + (11) | +
|
+ |
+ + (12) | +
SBPL is available as a standalone software library. SBPL itself has no dependencies other than the C/C++ standard library.
+These build and install instructions are primarily for Linux. For other operating systems, CMake can generate the platform-specific build and project files necessary for building SBPL.
+Versions of ROS older than Fuerte may contain packages that depend on a ROS package version of SBPL. The recommended method to install SBPL is to install it as a standard system library. However, if you wish to use the old ROS package version of SBPL, you may follow these instructions.
+SBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
++git clone https://github.com/sbpl/sbpl.git+
In the source directory, build the SBPL library using standard CMake build conventions:
++mkdir build +cd build +cmake .. +make ++
Install the built library and headers onto your local system (usually into /usr/local):
+
+sudo make install
+A pre-built Debian package exists on Linux for ROS distributions Fuerte and newer. To install the Debian, run:
+
+sudo apt-get install ros-distro-sbpl
+where distro is the name of your ROS distribution. This will install the SBPL library and associated development headers alongside other ROS components (in /opt/ros/distro on Ubuntu distributions). A pkg-config file is also included to allow you to locate the SBPL library components in your build system.
+In the CMakeLists.txt for your (ROS) package, the following lines are needed to find the installed SBPL files:
+
+find_package(PkgConfig REQUIRED)
+pkg_check_modules(SBPL REQUIRED sbpl)
+include_directories(${SBPL_INCLUDE_DIRS})
+link_directories(${SBPL_LIBRARY_DIRS})
+
+Then, after you've declared your binaries, you need to link them against SBPL with the following line:
+
+target_link_libraries(your-binary-here ${SBPL_LIBRARIES})
+The ROS package version of SBPL was deprecated with the release of ROS Fuerte. However, packages in ROS Electric may still require the ROS package version of SBPL.
+SBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
++git clone https://github.com/sbpl/sbpl.git+
In the source directory, checkout the electric branch of the repository to revert to the old ROS package version:
+
+git checkout electric
+Ensure that SBPL is on your ROS_PACKAGE_PATH and type:
+
+rosmake sbpl
+SBPL is also available as a pre-built Debian in ROS Electric. To instal the Debian, run:
+
+sudo apt-get install ros-electric-arm-navigation
+In the manifest.xml for your package, you need to add the following line to declare the SBPL package as a dependency:
+
+<depend package="sbpl"/>
+
+
diff --git a/static/archive/legacy-drupal/content/pages/0054-building-installing-and-using-sbpl.json b/static/archive/legacy-drupal/content/pages/0054-building-installing-and-using-sbpl.json
new file mode 100644
index 0000000..fcf608e
--- /dev/null
+++ b/static/archive/legacy-drupal/content/pages/0054-building-installing-and-using-sbpl.json
@@ -0,0 +1,25 @@
+{
+ "nid": 54,
+ "vid": 54,
+ "type": "page",
+ "language": "und",
+ "title": "Building, Installing, and Using SBPL",
+ "slug": "building-installing-and-using-sbpl",
+ "uid": 36,
+ "status": 1,
+ "promote": 0,
+ "sticky": 0,
+ "comment": 1,
+ "created": 1378234875,
+ "changed": 1382358322,
+ "url_aliases": [],
+ "tags_tids": [],
+ "field_image": [],
+ "field_page_file": [],
+ "body_format": "full_html",
+ "body_summary": "",
+ "body_html_rewritten": "SBPL is available as a standalone software library. SBPL itself has no dependencies other than the C/C++ standard library.
\r\nThese build and install instructions are primarily for Linux. For other operating systems, CMake can generate the platform-specific build and project files necessary for building SBPL.
\r\nVersions of ROS older than Fuerte may contain packages that depend on a ROS package version of SBPL. The recommended method to install SBPL is to install it as a standard system library. However, if you wish to use the old ROS package version of SBPL, you may follow these instructions.
\r\nSBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
\r\n\r\ngit clone https://github.com/sbpl/sbpl.git\r\n
In the source directory, build the SBPL library using standard CMake build conventions:
\r\n\r\nmkdir build\r\ncd build\r\ncmake ..\r\nmake\r\n\r\n
Install the built library and headers onto your local system (usually into /usr/local):
\r\n\r\nsudo make install\r\nA pre-built Debian package exists on Linux for ROS distributions Fuerte and newer. To install the Debian, run:
\r\n\r\nsudo apt-get install ros-distro-sbpl\r\nwhere distro is the name of your ROS distribution. This will install the SBPL library and associated development headers alongside other ROS components (in /opt/ros/distro on Ubuntu distributions). A pkg-config file is also included to allow you to locate the SBPL library components in your build system.
\r\nIn the CMakeLists.txt for your (ROS) package, the following lines are needed to find the installed SBPL files:
\r\n\r\nfind_package(PkgConfig REQUIRED)\r\npkg_check_modules(SBPL REQUIRED sbpl)\r\ninclude_directories(${SBPL_INCLUDE_DIRS})\r\nlink_directories(${SBPL_LIBRARY_DIRS})\r\n\r\nThen, after you've declared your binaries, you need to link them against SBPL with the following line:
\r\n\r\ntarget_link_libraries(your-binary-here ${SBPL_LIBRARIES})\r\nThe ROS package version of SBPL was deprecated with the release of ROS Fuerte. However, packages in ROS Electric may still require the ROS package version of SBPL.
\r\nSBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
\r\n\r\ngit clone https://github.com/sbpl/sbpl.git\r\n
In the source directory, checkout the electric branch of the repository to revert to the old ROS package version:
\r\n\r\ngit checkout electric\r\nEnsure that SBPL is on your ROS_PACKAGE_PATH and type:
\r\n\r\nrosmake sbpl\r\nSBPL is also available as a pre-built Debian in ROS Electric. To instal the Debian, run:
\r\n\r\nsudo apt-get install ros-electric-arm-navigation\r\nIn the manifest.xml for your package, you need to add the following line to declare the SBPL package as a dependency:
\r\n\r\n<depend package="sbpl"/>\r\n",
+ "body_markdown": "# **Building, Installing, and Using SBPL**\n\nSBPL is available as a standalone software library. SBPL itself has no dependencies other than the C/C++ standard library.\n\nThese build and install instructions are primarily for Linux. For other operating systems, CMake can generate the platform-specific build and project files necessary for building SBPL.\n\nVersions of ROS older than Fuerte may contain packages that depend on a ROS package version of SBPL. The recommended method to install SBPL is to install it as a standard system library. However, if you wish to use the old ROS package version of SBPL, you may follow[ these instructions](#ROS Package Instructions).\n\n## **1. Building and Installing SBPL from source**\n\n### **1.1 Build SBPL**\n\nSBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:\n\n```\n\r\ngit clone https://github.com/sbpl/sbpl.git\n```\n\nIn the source directory, build the SBPL library using standard CMake build conventions:\n\n```\n\r\nmkdir build\r\ncd build\r\ncmake ..\r\nmake\r\n\n```\n\n### **1.2 Install SBPL**\n\nInstall the built library and headers onto your local system (usually into /usr/local):\n\n```\n\r\nsudo make install\n```\n\n## **2. Installing SBPL from pre-built binary package**\n\nA pre-built Debian package exists on Linux for ROS distributions Fuerte and newer. To install the Debian, run:\n\n```\n\r\nsudo apt-get install ros-*distro*-sbpl\n```\n\nwhere *distro* is the name of your ROS distribution. This will install the SBPL library and associated development headers alongside other ROS components (in /opt/ros/*distro* on Ubuntu distributions). A pkg-config file is also included to allow you to locate the SBPL library components in your build system.\n\n## **3. Build your (ROS) package with SBPL as a dependency (CMake)**\n\nIn the CMakeLists.txt for your (ROS) package, the following lines are needed to find the installed SBPL files:\n\n```\n\r\nfind_package(PkgConfig REQUIRED)\r\npkg_check_modules(SBPL REQUIRED sbpl)\r\ninclude_directories(${SBPL_INCLUDE_DIRS})\r\nlink_directories(${SBPL_LIBRARY_DIRS})\r\n\n```\n\nThen, after you've declared your binaries, you need to link them against SBPL with the following line:\n\n```\n\r\ntarget_link_libraries(*your-binary-here* ${SBPL_LIBRARIES})\n```\n\n## **[]()4. Installing and Using SBPL as a ROS package**\n\nThe ROS package version of SBPL was deprecated with the release of ROS Fuerte. However, packages in ROS Electric may still require the ROS package version of SBPL.\n\n### **4.1 Install SBPL**\n\n#### **4.1.1 Source install**\n\nSBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:\n\n```\n\r\ngit clone https://github.com/sbpl/sbpl.git\n```\n\nIn the source directory, checkout the *electric* branch of the repository to revert to the old ROS package version:\n\n```\n\r\ngit checkout electric\n```\n\nEnsure that SBPL is on your ROS_PACKAGE_PATH and type:\n\n```\n\r\nrosmake sbpl\n```\n\n#### **4.1.2 Binary install**\n\nSBPL is also available as a pre-built Debian in ROS Electric. To instal the Debian, run:\n\n```\n\r\nsudo apt-get install ros-electric-arm-navigation\n```\n\n### **4.2 Build your ROS package with SBPL as a depency (rosbuild)**\n\nIn the manifest.xml for your package, you need to add the following line to declare the SBPL package as a dependency:\n\n```\n\r\nSBPL is available as a standalone software library. SBPL itself has no dependencies other than the C/C++ standard library.
\r\nThese build and install instructions are primarily for Linux. For other operating systems, CMake can generate the platform-specific build and project files necessary for building SBPL.
\r\nVersions of ROS older than Fuerte may contain packages that depend on a ROS package version of SBPL. The recommended method to install SBPL is to install it as a standard system library. However, if you wish to use the old ROS package version of SBPL, you may follow these instructions.
\r\nSBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
\r\n\r\ngit clone https://github.com/sbpl/sbpl.git\r\n
In the source directory, build the SBPL library using standard CMake build conventions:
\r\n\r\nmkdir build\r\ncd build\r\ncmake ..\r\nmake\r\n\r\n
Install the built library and headers onto your local system (usually into /usr/local):
\r\n\r\nsudo make install\r\nA pre-built Debian package exists on Linux for ROS distributions Fuerte and newer. To install the Debian, run:
\r\n\r\nsudo apt-get install ros-distro-sbpl\r\nwhere distro is the name of your ROS distribution. This will install the SBPL library and associated development headers alongside other ROS components (in /opt/ros/distro on Ubuntu distributions). A pkg-config file is also included to allow you to locate the SBPL library components in your build system.
\r\nIn the CMakeLists.txt for your (ROS) package, the following lines are needed to find the installed SBPL files:
\r\n\r\nfind_package(PkgConfig REQUIRED)\r\npkg_check_modules(SBPL REQUIRED sbpl)\r\ninclude_directories(${SBPL_INCLUDE_DIRS})\r\nlink_directories(${SBPL_LIBRARY_DIRS})\r\n\r\nThen, after you've declared your binaries, you need to link them against SBPL with the following line:
\r\n\r\ntarget_link_libraries(your-binary-here ${SBPL_LIBRARIES})\r\nThe ROS package version of SBPL was deprecated with the release of ROS Fuerte. However, packages in ROS Electric may still require the ROS package version of SBPL.
\r\nSBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
\r\n\r\ngit clone https://github.com/sbpl/sbpl.git\r\n
In the source directory, checkout the electric branch of the repository to revert to the old ROS package version:
\r\n\r\ngit checkout electric\r\nEnsure that SBPL is on your ROS_PACKAGE_PATH and type:
\r\n\r\nrosmake sbpl\r\nSBPL is also available as a pre-built Debian in ROS Electric. To instal the Debian, run:
\r\n\r\nsudo apt-get install ros-electric-arm-navigation\r\nIn the manifest.xml for your package, you need to add the following line to declare the SBPL package as a dependency:
\r\n\r\n<depend package="sbpl"/>\r\n",
+ "revision_log": ""
+}
\ No newline at end of file
diff --git a/static/archive/legacy-drupal/content/pages/0054-building-installing-and-using-sbpl.md b/static/archive/legacy-drupal/content/pages/0054-building-installing-and-using-sbpl.md
new file mode 100644
index 0000000..8a0733f
--- /dev/null
+++ b/static/archive/legacy-drupal/content/pages/0054-building-installing-and-using-sbpl.md
@@ -0,0 +1,118 @@
+# Building, Installing, and Using SBPL
+
+# **Building, Installing, and Using SBPL**
+
+SBPL is available as a standalone software library. SBPL itself has no dependencies other than the C/C++ standard library.
+
+These build and install instructions are primarily for Linux. For other operating systems, CMake can generate the platform-specific build and project files necessary for building SBPL.
+
+Versions of ROS older than Fuerte may contain packages that depend on a ROS package version of SBPL. The recommended method to install SBPL is to install it as a standard system library. However, if you wish to use the old ROS package version of SBPL, you may follow[ these instructions](#ROS Package Instructions).
+
+## **1. Building and Installing SBPL from source**
+
+### **1.1 Build SBPL**
+
+SBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
+
+```
+
+git clone https://github.com/sbpl/sbpl.git
+```
+
+In the source directory, build the SBPL library using standard CMake build conventions:
+
+```
+
+mkdir build
+cd build
+cmake ..
+make
+
+```
+
+### **1.2 Install SBPL**
+
+Install the built library and headers onto your local system (usually into /usr/local):
+
+```
+
+sudo make install
+```
+
+## **2. Installing SBPL from pre-built binary package**
+
+A pre-built Debian package exists on Linux for ROS distributions Fuerte and newer. To install the Debian, run:
+
+```
+
+sudo apt-get install ros-*distro*-sbpl
+```
+
+where *distro* is the name of your ROS distribution. This will install the SBPL library and associated development headers alongside other ROS components (in /opt/ros/*distro* on Ubuntu distributions). A pkg-config file is also included to allow you to locate the SBPL library components in your build system.
+
+## **3. Build your (ROS) package with SBPL as a dependency (CMake)**
+
+In the CMakeLists.txt for your (ROS) package, the following lines are needed to find the installed SBPL files:
+
+```
+
+find_package(PkgConfig REQUIRED)
+pkg_check_modules(SBPL REQUIRED sbpl)
+include_directories(${SBPL_INCLUDE_DIRS})
+link_directories(${SBPL_LIBRARY_DIRS})
+
+```
+
+Then, after you've declared your binaries, you need to link them against SBPL with the following line:
+
+```
+
+target_link_libraries(*your-binary-here* ${SBPL_LIBRARIES})
+```
+
+## **[]()4. Installing and Using SBPL as a ROS package**
+
+The ROS package version of SBPL was deprecated with the release of ROS Fuerte. However, packages in ROS Electric may still require the ROS package version of SBPL.
+
+### **4.1 Install SBPL**
+
+#### **4.1.1 Source install**
+
+SBPL uses git as its version control system. From the directory where you want the SBPL source to reside, clone the latest source from https://github.com/sbpl/sbpl:
+
+```
+
+git clone https://github.com/sbpl/sbpl.git
+```
+
+In the source directory, checkout the *electric* branch of the repository to revert to the old ROS package version:
+
+```
+
+git checkout electric
+```
+
+Ensure that SBPL is on your ROS_PACKAGE_PATH and type:
+
+```
+
+rosmake sbpl
+```
+
+#### **4.1.2 Binary install**
+
+SBPL is also available as a pre-built Debian in ROS Electric. To instal the Debian, run:
+
+```
+
+sudo apt-get install ros-electric-arm-navigation
+```
+
+### **4.2 Build your ROS package with SBPL as a depency (rosbuild)**
+
+In the manifest.xml for your package, you need to add the following line to declare the SBPL package as a dependency:
+
+```
+
+Download & Compile:
+Run Demo:
++
+ + diff --git a/static/archive/legacy-drupal/content/pages/0055-arm-planning.json b/static/archive/legacy-drupal/content/pages/0055-arm-planning.json new file mode 100644 index 0000000..ed4b3ce --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0055-arm-planning.json @@ -0,0 +1,27 @@ +{ + "nid": 55, + "vid": 55, + "type": "page", + "language": "und", + "title": "Arm Planning", + "slug": "arm-planning", + "uid": 11, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1379455741, + "changed": 1380759273, + "url_aliases": [ + "sbpl_arm_planning" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "full_html", + "body_summary": "", + "body_html_rewritten": "
Download & Compile:
\r\nRun Demo:
\r\n\t\r\n
\r\n", + "body_markdown": "# sbpl_arm_planning\n\n## Repositories\n\n **ROS Diamondback**\n\n Arm Navigation\n\n svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/diamondback/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/diamondback/)\n\n **ROS Electric**\n\n Arm Navigation\n\n svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/electric/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/electric/)\n\n **ROS Fuerte**\n\n Arm Navigation\n\n svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/)\n\n (install documentation below)\n\n MoveIt! (only compatible with June 2012)\n\n svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/trunk/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/trunk/)\n\n **ROS Groovy**\n\n C++ API\n\n git clone https://github.com/bcohen/sbpl_manipulation.git\n\n [install documentation](https://github.com/bcohen/sbpl_manipulation)\n\n MoveIt!\n\n Coming soon!\n\n## How to get started (ROS Fuerte):\n\n**Download & Compile:**\n\n 0) Install prerequisites:\n\n sudo apt-get install ros-fuerte-pr2-kinematics ros-fuerte-arm-navigation ros-fuerte-arm-navigation-experimental\n\n 1) Get the Arm Planner:\n\n svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/) sbpl_arm_planning\n\n 2) Get the SBPL:\n\n git clone [https://github.com/sbpl/sbpl.git](https://github.com/sbpl/sbpl.git)\n\n 3) Build the SBPL. Follow the directions here:\n\n [https://github.com/sbpl/sbpl/blob/master/README.txt](https://github.com/sbpl/sbpl/blob/master/README.txt)\n\n 4) Build the Arm Planner:\n\n rosmake sbpl_arm_planner_node\n\n 5) Build the test package (for testing the planner):\n\n rosmake simple_arm_utils\n\n**Run Demo:**\n\n Make sure you added this to your bashrc: export ROBOT=sim\n\n **Terminal 1 - Bring up Gazebo & Right Arm Navigation Stack**\n\n roslaunch simple_arm_control gazebo_with_right_arm_nav.launch\n\n **Terminal 2 - Bring up RViz** (add display for visualization markers)\n\n rosrun rviz rviz\n\n **Terminal 3 - Launch the planner for the right arm**\n\n roslaunch sbpl_arm_planner_node sbpl_planning_right_arm.launch\n\n **Terminal 4 - Request a motion plan**\n\n roslaunch simple_arm_control goal1.launch\n", + "body_html_raw": "
Download & Compile:
\r\nRun Demo:
\r\n\t\r\n
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0055-arm-planning.md b/static/archive/legacy-drupal/content/pages/0055-arm-planning.md new file mode 100644 index 0000000..80addb5 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0055-arm-planning.md @@ -0,0 +1,89 @@ +# Arm Planning + +# sbpl_arm_planning + +## Repositories + + **ROS Diamondback** + + Arm Navigation + + svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/diamondback/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/diamondback/) + + **ROS Electric** + + Arm Navigation + + svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/electric/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/electric/) + + **ROS Fuerte** + + Arm Navigation + + svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/) + + (install documentation below) + + MoveIt! (only compatible with June 2012) + + svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/trunk/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/trunk/) + + **ROS Groovy** + + C++ API + + git clone https://github.com/bcohen/sbpl_manipulation.git + + [install documentation](https://github.com/bcohen/sbpl_manipulation) + + MoveIt! + + Coming soon! + +## How to get started (ROS Fuerte): + +**Download & Compile:** + + 0) Install prerequisites: + + sudo apt-get install ros-fuerte-pr2-kinematics ros-fuerte-arm-navigation ros-fuerte-arm-navigation-experimental + + 1) Get the Arm Planner: + + svn co [https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/](https://mediabox.grasp.upenn.edu/svn/penn-ros-pkgs/sbpl_arm_planning/branches/fuerte_arm_navigation/) sbpl_arm_planning + + 2) Get the SBPL: + + git clone [https://github.com/sbpl/sbpl.git](https://github.com/sbpl/sbpl.git) + + 3) Build the SBPL. Follow the directions here: + + [https://github.com/sbpl/sbpl/blob/master/README.txt](https://github.com/sbpl/sbpl/blob/master/README.txt) + + 4) Build the Arm Planner: + + rosmake sbpl_arm_planner_node + + 5) Build the test package (for testing the planner): + + rosmake simple_arm_utils + +**Run Demo:** + + Make sure you added this to your bashrc: export ROBOT=sim + + **Terminal 1 - Bring up Gazebo & Right Arm Navigation Stack** + + roslaunch simple_arm_control gazebo_with_right_arm_nav.launch + + **Terminal 2 - Bring up RViz** (add display for visualization markers) + + rosrun rviz rviz + + **Terminal 3 - Launch the planner for the right arm** + + roslaunch sbpl_arm_planner_node sbpl_planning_right_arm.launch + + **Terminal 4 - Request a motion plan** + + roslaunch simple_arm_control goal1.launch diff --git a/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.html b/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.html new file mode 100644 index 0000000..5dd381e --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.html @@ -0,0 +1,7 @@ + +
Phd. student. C.S.
+ + diff --git a/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.json b/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.json new file mode 100644 index 0000000..26c54db --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.json @@ -0,0 +1,27 @@ +{ + "nid": 56, + "vid": 56, + "type": "page", + "language": "und", + "title": "Aram Ebtekar", + "slug": "aram-ebtekar", + "uid": 1592, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382042307, + "changed": 1382112277, + "url_aliases": [ + "Aram Ebtekar" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Phd. student. C.S.
\r\n", + "body_markdown": "Phd. student. C.S.\n", + "body_html_raw": "Phd. student. C.S.
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.md b/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.md new file mode 100644 index 0000000..686742c --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0056-aram-ebtekar.md @@ -0,0 +1,3 @@ +# Aram Ebtekar + +Phd. student. C.S. diff --git a/static/archive/legacy-drupal/content/pages/0057-kush-prasad.html b/static/archive/legacy-drupal/content/pages/0057-kush-prasad.html new file mode 100644 index 0000000..e630255 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0057-kush-prasad.html @@ -0,0 +1,7 @@ + +Research Staff
+ + diff --git a/static/archive/legacy-drupal/content/pages/0057-kush-prasad.json b/static/archive/legacy-drupal/content/pages/0057-kush-prasad.json new file mode 100644 index 0000000..4abba7e --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0057-kush-prasad.json @@ -0,0 +1,27 @@ +{ + "nid": 57, + "vid": 57, + "type": "page", + "language": "und", + "title": "Kush Prasad", + "slug": "kush-prasad", + "uid": 1596, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382043303, + "changed": 1382117324, + "url_aliases": [ + "Kush Prasad" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Research Staff
\r\n", + "body_markdown": "Research Staff\n", + "body_html_raw": "Research Staff
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0057-kush-prasad.md b/static/archive/legacy-drupal/content/pages/0057-kush-prasad.md new file mode 100644 index 0000000..e47e15c --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0057-kush-prasad.md @@ -0,0 +1,3 @@ +# Kush Prasad + +Research Staff diff --git a/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.html b/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.html new file mode 100644 index 0000000..aa5a09a --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.html @@ -0,0 +1,7 @@ + +Phd. student
+ + diff --git a/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.json b/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.json new file mode 100644 index 0000000..f81c921 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.json @@ -0,0 +1,27 @@ +{ + "nid": 58, + "vid": 58, + "type": "page", + "language": "und", + "title": "Sung-Kyun Kim", + "slug": "sung-kyun-kim", + "uid": 1591, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382043402, + "changed": 1382112256, + "url_aliases": [ + "Sung-Kyun Kim" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Phd. student
\r\n", + "body_markdown": "Phd. student\n", + "body_html_raw": "Phd. student
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.md b/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.md new file mode 100644 index 0000000..21d880d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0058-sung-kyun-kim.md @@ -0,0 +1,3 @@ +# Sung-Kyun Kim + +Phd. student diff --git a/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.html b/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.html new file mode 100644 index 0000000..bb400ba --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.html @@ -0,0 +1,7 @@ + +Post Doc
+ + diff --git a/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.json b/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.json new file mode 100644 index 0000000..780441b --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.json @@ -0,0 +1,27 @@ +{ + "nid": 59, + "vid": 59, + "type": "page", + "language": "und", + "title": "Soonkyum Kim", + "slug": "soonkyum-kim", + "uid": 1590, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382043628, + "changed": 1382112221, + "url_aliases": [ + "Soonkyum Kim" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Post Doc
\r\n", + "body_markdown": "Post Doc\n", + "body_html_raw": "Post Doc
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.md b/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.md new file mode 100644 index 0000000..4070d55 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0059-soonkyum-kim.md @@ -0,0 +1,3 @@ +# Soonkyum Kim + +Post Doc diff --git a/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.html b/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.html new file mode 100644 index 0000000..670763a --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.html @@ -0,0 +1,7 @@ + +Masters Student
+ + diff --git a/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.json b/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.json new file mode 100644 index 0000000..24fd79b --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.json @@ -0,0 +1,27 @@ +{ + "nid": 60, + "vid": 60, + "type": "page", + "language": "und", + "title": "Siddharth Swaminathan", + "slug": "siddharth-swaminathan", + "uid": 1595, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382043736, + "changed": 1382117198, + "url_aliases": [ + "Siddharth Swaminathan" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Masters Student
\r\n", + "body_markdown": "Masters Student\n", + "body_html_raw": "Masters Student
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.md b/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.md new file mode 100644 index 0000000..12d5593 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0060-siddharth-swaminathan.md @@ -0,0 +1,3 @@ +# Siddharth Swaminathan + +Masters Student diff --git a/static/archive/legacy-drupal/content/pages/0061-chen-gao.html b/static/archive/legacy-drupal/content/pages/0061-chen-gao.html new file mode 100644 index 0000000..4d750fc --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0061-chen-gao.html @@ -0,0 +1,7 @@ + +Masters Student
+ + diff --git a/static/archive/legacy-drupal/content/pages/0061-chen-gao.json b/static/archive/legacy-drupal/content/pages/0061-chen-gao.json new file mode 100644 index 0000000..32be931 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0061-chen-gao.json @@ -0,0 +1,27 @@ +{ + "nid": 61, + "vid": 61, + "type": "page", + "language": "und", + "title": "Chen Gao", + "slug": "chen-gao", + "uid": 1589, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382043949, + "changed": 1382112198, + "url_aliases": [ + "Chen Gao" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Masters Student
\r\n", + "body_markdown": "Masters Student\n", + "body_html_raw": "Masters Student
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0061-chen-gao.md b/static/archive/legacy-drupal/content/pages/0061-chen-gao.md new file mode 100644 index 0000000..45160e4 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0061-chen-gao.md @@ -0,0 +1,3 @@ +# Chen Gao + +Masters Student diff --git a/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.html b/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.html new file mode 100644 index 0000000..5295085 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.html @@ -0,0 +1,7 @@ + +Summer Intern/Off-site Develepor
+ + diff --git a/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.json b/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.json new file mode 100644 index 0000000..a613e38 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.json @@ -0,0 +1,27 @@ +{ + "nid": 62, + "vid": 62, + "type": "page", + "language": "und", + "title": "Ellis Ratner", + "slug": "ellis-ratner", + "uid": 1588, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382044111, + "changed": 1382112175, + "url_aliases": [ + "Ellis Ratner" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Summer Intern/Off-site Develepor
\r\n", + "body_markdown": "Summer Intern/Off-site Develepor\n", + "body_html_raw": "Summer Intern/Off-site Develepor
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.md b/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.md new file mode 100644 index 0000000..019d28d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0062-ellis-ratner.md @@ -0,0 +1,3 @@ +# Ellis Ratner + +Summer Intern/Off-site Develepor diff --git a/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.html b/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.html new file mode 100644 index 0000000..a71074f --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.html @@ -0,0 +1,7 @@ + +Summer Intern
+ + diff --git a/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.json b/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.json new file mode 100644 index 0000000..be53094 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.json @@ -0,0 +1,27 @@ +{ + "nid": 63, + "vid": 63, + "type": "page", + "language": "und", + "title": "Krishna Sapkota", + "slug": "krishna-sapkota", + "uid": 13, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382044177, + "changed": 1382117363, + "url_aliases": [ + "Krishna Sapkota" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Summer Intern
\r\n", + "body_markdown": "Summer Intern\n", + "body_html_raw": "Summer Intern
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.md b/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.md new file mode 100644 index 0000000..1ef6d24 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0063-krishna-sapkota.md @@ -0,0 +1,3 @@ +# Krishna Sapkota + +Summer Intern diff --git a/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.html b/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.html new file mode 100644 index 0000000..76b02cc --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.html @@ -0,0 +1,7 @@ + +Summer Intern
+ + diff --git a/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.json b/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.json new file mode 100644 index 0000000..7e89846 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.json @@ -0,0 +1,27 @@ +{ + "nid": 64, + "vid": 64, + "type": "page", + "language": "und", + "title": "Burak Yucesoy", + "slug": "burak-yucesoy", + "uid": 13, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382044250, + "changed": 1382117341, + "url_aliases": [ + "Burak Yucesoy" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Summer Intern
\r\n", + "body_markdown": "Summer Intern\n", + "body_html_raw": "Summer Intern
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.md b/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.md new file mode 100644 index 0000000..c68878d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0064-burak-yucesoy.md @@ -0,0 +1,3 @@ +# Burak Yucesoy + +Summer Intern diff --git a/static/archive/legacy-drupal/content/pages/0065-arjun-menon.html b/static/archive/legacy-drupal/content/pages/0065-arjun-menon.html new file mode 100644 index 0000000..d42ccff --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0065-arjun-menon.html @@ -0,0 +1,7 @@ + +TBF
+ + diff --git a/static/archive/legacy-drupal/content/pages/0065-arjun-menon.json b/static/archive/legacy-drupal/content/pages/0065-arjun-menon.json new file mode 100644 index 0000000..10847b6 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0065-arjun-menon.json @@ -0,0 +1,27 @@ +{ + "nid": 65, + "vid": 65, + "type": "page", + "language": "und", + "title": "Arjun Menon", + "slug": "arjun-menon", + "uid": 1587, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382044738, + "changed": 1382112300, + "url_aliases": [ + "Arjun Menon" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "TBF
\r\n", + "body_markdown": "TBF\n", + "body_html_raw": "TBF
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0065-arjun-menon.md b/static/archive/legacy-drupal/content/pages/0065-arjun-menon.md new file mode 100644 index 0000000..ff9a491 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0065-arjun-menon.md @@ -0,0 +1,3 @@ +# Arjun Menon + +TBF diff --git a/static/archive/legacy-drupal/content/pages/0066-hao-wang.html b/static/archive/legacy-drupal/content/pages/0066-hao-wang.html new file mode 100644 index 0000000..4896345 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0066-hao-wang.html @@ -0,0 +1,7 @@ + +Masters Student
+ + diff --git a/static/archive/legacy-drupal/content/pages/0066-hao-wang.json b/static/archive/legacy-drupal/content/pages/0066-hao-wang.json new file mode 100644 index 0000000..043019d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0066-hao-wang.json @@ -0,0 +1,27 @@ +{ + "nid": 66, + "vid": 66, + "type": "page", + "language": "und", + "title": "Hao Wang", + "slug": "hao-wang", + "uid": 1586, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382044789, + "changed": 1382112106, + "url_aliases": [ + "Hao Wang" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Masters Student
\r\n", + "body_markdown": "Masters Student\n", + "body_html_raw": "Masters Student
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0066-hao-wang.md b/static/archive/legacy-drupal/content/pages/0066-hao-wang.md new file mode 100644 index 0000000..3ac3384 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0066-hao-wang.md @@ -0,0 +1,3 @@ +# Hao Wang + +Masters Student diff --git a/static/archive/legacy-drupal/content/pages/0067-victor-hwang.html b/static/archive/legacy-drupal/content/pages/0067-victor-hwang.html new file mode 100644 index 0000000..b50dd03 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0067-victor-hwang.html @@ -0,0 +1,7 @@ + +Masters Student
+ + diff --git a/static/archive/legacy-drupal/content/pages/0067-victor-hwang.json b/static/archive/legacy-drupal/content/pages/0067-victor-hwang.json new file mode 100644 index 0000000..fb43f6b --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0067-victor-hwang.json @@ -0,0 +1,27 @@ +{ + "nid": 67, + "vid": 67, + "type": "page", + "language": "und", + "title": "Victor Hwang", + "slug": "victor-hwang", + "uid": 648, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382044955, + "changed": 1382112369, + "url_aliases": [ + "Victor Hwang" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Masters Student
\r\n", + "body_markdown": "Masters Student\n", + "body_html_raw": "Masters Student
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0067-victor-hwang.md b/static/archive/legacy-drupal/content/pages/0067-victor-hwang.md new file mode 100644 index 0000000..0f22e93 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0067-victor-hwang.md @@ -0,0 +1,3 @@ +# Victor Hwang + +Masters Student diff --git a/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.html b/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.html new file mode 100644 index 0000000..6d5363d --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.html @@ -0,0 +1,7 @@ + +Software Developer
+ + diff --git a/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.json b/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.json new file mode 100644 index 0000000..4c8ac53 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.json @@ -0,0 +1,27 @@ +{ + "nid": 68, + "vid": 68, + "type": "page", + "language": "und", + "title": "Margarite Safonova", + "slug": "margarite-safonova", + "uid": 1633, + "status": 1, + "promote": 0, + "sticky": 0, + "comment": 1, + "created": 1382374632, + "changed": 1382374890, + "url_aliases": [ + "Margarite Safonova" + ], + "tags_tids": [], + "field_image": [], + "field_page_file": [], + "body_format": "filtered_html", + "body_summary": "", + "body_html_rewritten": "Software Developer
\r\n", + "body_markdown": "Software Developer\n", + "body_html_raw": "Software Developer
\r\n", + "revision_log": "" +} \ No newline at end of file diff --git a/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.md b/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.md new file mode 100644 index 0000000..6eabf52 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0068-margarite-safonova.md @@ -0,0 +1,3 @@ +# Margarite Safonova + +Software Developer diff --git a/static/archive/legacy-drupal/content/pages/0069-discriminatively-guided-deliberative-perception-for-pose-estimation-of-multiple-3d-object-instances.html b/static/archive/legacy-drupal/content/pages/0069-discriminatively-guided-deliberative-perception-for-pose-estimation-of-multiple-3d-object-instances.html new file mode 100644 index 0000000..e4b6fe1 --- /dev/null +++ b/static/archive/legacy-drupal/content/pages/0069-discriminatively-guided-deliberative-perception-for-pose-estimation-of-multiple-3d-object-instances.html @@ -0,0 +1,14 @@ + + -
-
- \";s:16:\"filter_html_help\";i:1;s:20:\"filter_html_nofollow\";i:0;}"
+ },
+ {
+ "format": "filtered_html",
+ "module": "filter",
+ "name": "filter_autop",
+ "weight": 2,
+ "status": 1,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "filtered_html",
+ "module": "filter",
+ "name": "filter_htmlcorrector",
+ "weight": 10,
+ "status": 1,
+ "settings": "a:0:{}"
+ }
+ ]
+ },
+ {
+ "format": "full_html",
+ "name": "Full HTML",
+ "status": 1,
+ "cache": 1,
+ "weight": 1,
+ "filters": [
+ {
+ "format": "full_html",
+ "module": "filter",
+ "name": "filter_html",
+ "weight": -50,
+ "status": 0,
+ "settings": "a:3:{s:12:\"allowed_html\";s:74:\"
-
-
- \";s:16:\"filter_html_help\";i:1;s:20:\"filter_html_nofollow\";i:0;}"
+ },
+ {
+ "format": "full_html",
+ "module": "filter",
+ "name": "filter_html_escape",
+ "weight": -49,
+ "status": 0,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "full_html",
+ "module": "php",
+ "name": "php_code",
+ "weight": -48,
+ "status": 0,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "full_html",
+ "module": "filter",
+ "name": "filter_url",
+ "weight": -47,
+ "status": 1,
+ "settings": "a:1:{s:17:\"filter_url_length\";s:2:\"72\";}"
+ },
+ {
+ "format": "full_html",
+ "module": "image_resize_filter",
+ "name": "image_resize_filter",
+ "weight": -46,
+ "status": 1,
+ "settings": "a:4:{s:4:\"link\";i:1;s:10:\"link_class\";s:0:\"\";s:8:\"link_rel\";s:0:\"\";s:15:\"image_locations\";a:2:{s:5:\"local\";s:5:\"local\";s:6:\"remote\";i:0;}}"
+ },
+ {
+ "format": "full_html",
+ "module": "filter",
+ "name": "filter_autop",
+ "weight": -45,
+ "status": 0,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "full_html",
+ "module": "filter",
+ "name": "filter_htmlcorrector",
+ "weight": -44,
+ "status": 0,
+ "settings": "a:0:{}"
+ }
+ ]
+ },
+ {
+ "format": "plain_text",
+ "name": "Plain text",
+ "status": 1,
+ "cache": 1,
+ "weight": 10,
+ "filters": [
+ {
+ "format": "plain_text",
+ "module": "filter",
+ "name": "filter_html",
+ "weight": -10,
+ "status": 0,
+ "settings": "a:3:{s:12:\"allowed_html\";s:74:\"
-
-
- \";s:16:\"filter_html_help\";i:1;s:20:\"filter_html_nofollow\";i:0;}"
+ },
+ {
+ "format": "plain_text",
+ "module": "filter",
+ "name": "filter_html_escape",
+ "weight": 0,
+ "status": 1,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "plain_text",
+ "module": "filter",
+ "name": "filter_url",
+ "weight": 1,
+ "status": 1,
+ "settings": "a:1:{s:17:\"filter_url_length\";i:72;}"
+ },
+ {
+ "format": "plain_text",
+ "module": "filter",
+ "name": "filter_autop",
+ "weight": 2,
+ "status": 1,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "plain_text",
+ "module": "filter",
+ "name": "filter_htmlcorrector",
+ "weight": 10,
+ "status": 0,
+ "settings": "a:0:{}"
+ }
+ ]
+ },
+ {
+ "format": "php_code",
+ "name": "PHP code",
+ "status": 1,
+ "cache": 0,
+ "weight": 11,
+ "filters": [
+ {
+ "format": "php_code",
+ "module": "filter",
+ "name": "filter_html",
+ "weight": -10,
+ "status": 0,
+ "settings": "a:3:{s:12:\"allowed_html\";s:74:\"
-
-
- \";s:16:\"filter_html_help\";i:1;s:20:\"filter_html_nofollow\";i:0;}"
+ },
+ {
+ "format": "php_code",
+ "module": "filter",
+ "name": "filter_html_escape",
+ "weight": -10,
+ "status": 0,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "php_code",
+ "module": "filter",
+ "name": "filter_autop",
+ "weight": 0,
+ "status": 0,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "php_code",
+ "module": "filter",
+ "name": "filter_url",
+ "weight": 0,
+ "status": 0,
+ "settings": "a:1:{s:17:\"filter_url_length\";s:2:\"72\";}"
+ },
+ {
+ "format": "php_code",
+ "module": "php",
+ "name": "php_code",
+ "weight": 0,
+ "status": 1,
+ "settings": "a:0:{}"
+ },
+ {
+ "format": "php_code",
+ "module": "filter",
+ "name": "filter_htmlcorrector",
+ "weight": 10,
+ "status": 0,
+ "settings": "a:0:{}"
+ }
+ ]
+ }
+]
\ No newline at end of file
diff --git a/static/archive/legacy-drupal/data/url_aliases.json b/static/archive/legacy-drupal/data/url_aliases.json
new file mode 100644
index 0000000..f22c5e7
--- /dev/null
+++ b/static/archive/legacy-drupal/data/url_aliases.json
@@ -0,0 +1,651 @@
+{
+ "by_node": [
+ {
+ "nid": 3,
+ "page_file": "0003-people.html",
+ "title": "People",
+ "aliases": [
+ "People"
+ ]
+ },
+ {
+ "nid": 9,
+ "page_file": "0009-home.html",
+ "title": "Home",
+ "aliases": [
+ "Home"
+ ]
+ },
+ {
+ "nid": 10,
+ "page_file": "0010-publications.html",
+ "title": "Publications",
+ "aliases": [
+ "Publications"
+ ]
+ },
+ {
+ "nid": 11,
+ "page_file": "0011-videos.html",
+ "title": "Videos",
+ "aliases": [
+ "Videos"
+ ]
+ },
+ {
+ "nid": 12,
+ "page_file": "0012-robots.html",
+ "title": "Robots",
+ "aliases": [
+ "Robots"
+ ]
+ },
+ {
+ "nid": 13,
+ "page_file": "0013-ben-cohen.html",
+ "title": "Ben Cohen",
+ "aliases": [
+ "BenCohen"
+ ]
+ },
+ {
+ "nid": 14,
+ "page_file": "0014-brian-macallister.html",
+ "title": "Brian MacAllister",
+ "aliases": [
+ "BrianMacAllister"
+ ]
+ },
+ {
+ "nid": 15,
+ "page_file": "0015-andrew-dornbush.html",
+ "title": "Andrew Dornbush",
+ "aliases": [
+ "AndrewDornbush"
+ ]
+ },
+ {
+ "nid": 16,
+ "page_file": "0016-subhrajit-bhattacharya.html",
+ "title": "Subhrajit Bhattacharya",
+ "aliases": [
+ "SubhrajitBhattacharya"
+ ]
+ },
+ {
+ "nid": 17,
+ "page_file": "0017-jonathan-butzke.html",
+ "title": "Jonathan Butzke",
+ "aliases": [
+ "JonathanButzke"
+ ]
+ },
+ {
+ "nid": 18,
+ "page_file": "0018-chris-clingerman.html",
+ "title": "Chris Clingerman",
+ "aliases": [
+ "ChrisClingerman"
+ ]
+ },
+ {
+ "nid": 19,
+ "page_file": "0019-john-drake.html",
+ "title": "John Drake",
+ "aliases": [
+ "JohnDrake"
+ ]
+ },
+ {
+ "nid": 20,
+ "page_file": "0020-steven-gray.html",
+ "title": "Steven Gray",
+ "aliases": [
+ "StevenGray"
+ ]
+ },
+ {
+ "nid": 21,
+ "page_file": "0021-kalin-gochev.html",
+ "title": "Kalin Gochev",
+ "aliases": [
+ "KalinGochev"
+ ]
+ },
+ {
+ "nid": 22,
+ "page_file": "0022-bradford-neuman.html",
+ "title": "Bradford Neuman",
+ "aliases": [
+ "BradfordNeuman"
+ ]
+ },
+ {
+ "nid": 23,
+ "page_file": "0023-aline-normoyle.html",
+ "title": "Aline Normoyle",
+ "aliases": [
+ "AlineNormoyle"
+ ]
+ },
+ {
+ "nid": 24,
+ "page_file": "0024-mike-phillips.html",
+ "title": "Mike Phillips",
+ "aliases": [
+ "MikePhillips"
+ ]
+ },
+ {
+ "nid": 25,
+ "page_file": "0025-venkatraman-narayanan.html",
+ "title": "Venkatraman Narayanan",
+ "aliases": [
+ "VenkatramanNarayanan"
+ ]
+ },
+ {
+ "nid": 26,
+ "page_file": "0026-alex-kushleyev.html",
+ "title": "Alex Kushleyev",
+ "aliases": [
+ "AlexKushleyev"
+ ]
+ },
+ {
+ "nid": 27,
+ "page_file": "0027-harsh-pandey.html",
+ "title": "Harsh Pandey",
+ "aliases": [
+ "HarshPandey"
+ ]
+ },
+ {
+ "nid": 28,
+ "page_file": "0028-kavan-mceachern.html",
+ "title": "Kavan McEachern",
+ "aliases": [
+ "KavanMcEachern"
+ ]
+ },
+ {
+ "nid": 29,
+ "page_file": "0029-matthew-mac-allister.html",
+ "title": "Matthew Mac Allister",
+ "aliases": [
+ "MatthewMacAllister"
+ ]
+ },
+ {
+ "nid": 30,
+ "page_file": "0030-contact.html",
+ "title": "Contact",
+ "aliases": [
+ "Contact"
+ ]
+ },
+ {
+ "nid": 31,
+ "page_file": "0031-login.html",
+ "title": "Login",
+ "aliases": [
+ "Login"
+ ]
+ },
+ {
+ "nid": 32,
+ "page_file": "0032-software.html",
+ "title": "Software",
+ "aliases": [
+ "Software"
+ ]
+ },
+ {
+ "nid": 33,
+ "page_file": "0033-untitled-33.html",
+ "title": "",
+ "aliases": [
+ "Files"
+ ]
+ },
+ {
+ "nid": 39,
+ "page_file": "0039-eduardo-barrera.html",
+ "title": "Eduardo Barrera",
+ "aliases": [
+ "EduardoBarrera"
+ ]
+ },
+ {
+ "nid": 42,
+ "page_file": "0042-old-software.html",
+ "title": "Old Software",
+ "aliases": [
+ "OldSoftwarePage"
+ ]
+ },
+ {
+ "nid": 43,
+ "page_file": "0043-sandip-aine.html",
+ "title": "Sandip Aine",
+ "aliases": [
+ "SandipAine"
+ ]
+ },
+ {
+ "nid": 44,
+ "page_file": "0044-calendar.html",
+ "title": "Calendar",
+ "aliases": [
+ "Calender"
+ ]
+ },
+ {
+ "nid": 45,
+ "page_file": "0045-tutorials.html",
+ "title": "Tutorials",
+ "aliases": [
+ "Tutorials"
+ ]
+ },
+ {
+ "nid": 55,
+ "page_file": "0055-arm-planning.html",
+ "title": "Arm Planning",
+ "aliases": [
+ "sbpl_arm_planning"
+ ]
+ },
+ {
+ "nid": 56,
+ "page_file": "0056-aram-ebtekar.html",
+ "title": "Aram Ebtekar",
+ "aliases": [
+ "Aram Ebtekar"
+ ]
+ },
+ {
+ "nid": 57,
+ "page_file": "0057-kush-prasad.html",
+ "title": "Kush Prasad",
+ "aliases": [
+ "Kush Prasad"
+ ]
+ },
+ {
+ "nid": 58,
+ "page_file": "0058-sung-kyun-kim.html",
+ "title": "Sung-Kyun Kim",
+ "aliases": [
+ "Sung-Kyun Kim"
+ ]
+ },
+ {
+ "nid": 59,
+ "page_file": "0059-soonkyum-kim.html",
+ "title": "Soonkyum Kim",
+ "aliases": [
+ "Soonkyum Kim"
+ ]
+ },
+ {
+ "nid": 60,
+ "page_file": "0060-siddharth-swaminathan.html",
+ "title": "Siddharth Swaminathan",
+ "aliases": [
+ "Siddharth Swaminathan"
+ ]
+ },
+ {
+ "nid": 61,
+ "page_file": "0061-chen-gao.html",
+ "title": "Chen Gao",
+ "aliases": [
+ "Chen Gao"
+ ]
+ },
+ {
+ "nid": 62,
+ "page_file": "0062-ellis-ratner.html",
+ "title": "Ellis Ratner",
+ "aliases": [
+ "Ellis Ratner"
+ ]
+ },
+ {
+ "nid": 63,
+ "page_file": "0063-krishna-sapkota.html",
+ "title": "Krishna Sapkota",
+ "aliases": [
+ "Krishna Sapkota"
+ ]
+ },
+ {
+ "nid": 64,
+ "page_file": "0064-burak-yucesoy.html",
+ "title": "Burak Yucesoy",
+ "aliases": [
+ "Burak Yucesoy"
+ ]
+ },
+ {
+ "nid": 65,
+ "page_file": "0065-arjun-menon.html",
+ "title": "Arjun Menon",
+ "aliases": [
+ "Arjun Menon"
+ ]
+ },
+ {
+ "nid": 66,
+ "page_file": "0066-hao-wang.html",
+ "title": "Hao Wang",
+ "aliases": [
+ "Hao Wang"
+ ]
+ },
+ {
+ "nid": 67,
+ "page_file": "0067-victor-hwang.html",
+ "title": "Victor Hwang",
+ "aliases": [
+ "Victor Hwang"
+ ]
+ },
+ {
+ "nid": 68,
+ "page_file": "0068-margarite-safonova.html",
+ "title": "Margarite Safonova",
+ "aliases": [
+ "Margarite Safonova"
+ ]
+ },
+ {
+ "nid": 69,
+ "page_file": "0069-discriminatively-guided-deliberative-perception-for-pose-estimation-of-multiple-3d-object-instances.html",
+ "title": "Discriminatively-guided Deliberative Perception for Pose Estimation of Multiple 3D Object Instances",
+ "aliases": [
+ "Software/d2p"
+ ]
+ }
+ ],
+ "non_node_aliases": [],
+ "all": [
+ {
+ "pid": 1,
+ "source": "node/13",
+ "alias": "BenCohen",
+ "language": "und"
+ },
+ {
+ "pid": 2,
+ "source": "node/14",
+ "alias": "BrianMacAllister",
+ "language": "und"
+ },
+ {
+ "pid": 3,
+ "source": "node/15",
+ "alias": "AndrewDornbush",
+ "language": "und"
+ },
+ {
+ "pid": 4,
+ "source": "node/16",
+ "alias": "SubhrajitBhattacharya",
+ "language": "und"
+ },
+ {
+ "pid": 5,
+ "source": "node/17",
+ "alias": "JonathanButzke",
+ "language": "und"
+ },
+ {
+ "pid": 6,
+ "source": "node/18",
+ "alias": "ChrisClingerman",
+ "language": "und"
+ },
+ {
+ "pid": 7,
+ "source": "node/19",
+ "alias": "JohnDrake",
+ "language": "und"
+ },
+ {
+ "pid": 8,
+ "source": "node/20",
+ "alias": "StevenGray",
+ "language": "und"
+ },
+ {
+ "pid": 9,
+ "source": "node/21",
+ "alias": "KalinGochev",
+ "language": "und"
+ },
+ {
+ "pid": 10,
+ "source": "node/22",
+ "alias": "BradfordNeuman",
+ "language": "und"
+ },
+ {
+ "pid": 11,
+ "source": "node/23",
+ "alias": "AlineNormoyle",
+ "language": "und"
+ },
+ {
+ "pid": 12,
+ "source": "node/24",
+ "alias": "MikePhillips",
+ "language": "und"
+ },
+ {
+ "pid": 13,
+ "source": "node/25",
+ "alias": "VenkatramanNarayanan",
+ "language": "und"
+ },
+ {
+ "pid": 14,
+ "source": "node/26",
+ "alias": "AlexKushleyev",
+ "language": "und"
+ },
+ {
+ "pid": 15,
+ "source": "node/27",
+ "alias": "HarshPandey",
+ "language": "und"
+ },
+ {
+ "pid": 16,
+ "source": "node/28",
+ "alias": "KavanMcEachern",
+ "language": "und"
+ },
+ {
+ "pid": 17,
+ "source": "node/29",
+ "alias": "MatthewMacAllister",
+ "language": "und"
+ },
+ {
+ "pid": 18,
+ "source": "node/31",
+ "alias": "Login",
+ "language": "und"
+ },
+ {
+ "pid": 22,
+ "source": "node/30",
+ "alias": "Contact",
+ "language": "und"
+ },
+ {
+ "pid": 23,
+ "source": "node/10",
+ "alias": "Publications",
+ "language": "und"
+ },
+ {
+ "pid": 24,
+ "source": "node/3",
+ "alias": "People",
+ "language": "und"
+ },
+ {
+ "pid": 25,
+ "source": "node/11",
+ "alias": "Videos",
+ "language": "und"
+ },
+ {
+ "pid": 26,
+ "source": "node/32",
+ "alias": "Software",
+ "language": "und"
+ },
+ {
+ "pid": 27,
+ "source": "node/33",
+ "alias": "Files",
+ "language": "und"
+ },
+ {
+ "pid": 28,
+ "source": "node/12",
+ "alias": "Robots",
+ "language": "und"
+ },
+ {
+ "pid": 29,
+ "source": "node/9",
+ "alias": "Home",
+ "language": "und"
+ },
+ {
+ "pid": 32,
+ "source": "node/39",
+ "alias": "EduardoBarrera",
+ "language": "und"
+ },
+ {
+ "pid": 34,
+ "source": "node/42",
+ "alias": "OldSoftwarePage",
+ "language": "und"
+ },
+ {
+ "pid": 35,
+ "source": "node/43",
+ "alias": "SandipAine",
+ "language": "und"
+ },
+ {
+ "pid": 36,
+ "source": "node/44",
+ "alias": "Calender",
+ "language": "und"
+ },
+ {
+ "pid": 37,
+ "source": "node/45",
+ "alias": "Tutorials",
+ "language": "und"
+ },
+ {
+ "pid": 38,
+ "source": "node/55",
+ "alias": "sbpl_arm_planning",
+ "language": "und"
+ },
+ {
+ "pid": 39,
+ "source": "node/56",
+ "alias": "Aram Ebtekar",
+ "language": "und"
+ },
+ {
+ "pid": 40,
+ "source": "node/57",
+ "alias": "Kush Prasad",
+ "language": "und"
+ },
+ {
+ "pid": 41,
+ "source": "node/58",
+ "alias": "Sung-Kyun Kim",
+ "language": "und"
+ },
+ {
+ "pid": 42,
+ "source": "node/59",
+ "alias": "Soonkyum Kim",
+ "language": "und"
+ },
+ {
+ "pid": 43,
+ "source": "node/60",
+ "alias": "Siddharth Swaminathan",
+ "language": "und"
+ },
+ {
+ "pid": 44,
+ "source": "node/61",
+ "alias": "Chen Gao",
+ "language": "und"
+ },
+ {
+ "pid": 45,
+ "source": "node/62",
+ "alias": "Ellis Ratner",
+ "language": "und"
+ },
+ {
+ "pid": 46,
+ "source": "node/63",
+ "alias": "Krishna Sapkota",
+ "language": "und"
+ },
+ {
+ "pid": 47,
+ "source": "node/64",
+ "alias": "Burak Yucesoy",
+ "language": "und"
+ },
+ {
+ "pid": 48,
+ "source": "node/65",
+ "alias": "Arjun Menon",
+ "language": "und"
+ },
+ {
+ "pid": 49,
+ "source": "node/66",
+ "alias": "Hao Wang",
+ "language": "und"
+ },
+ {
+ "pid": 50,
+ "source": "node/67",
+ "alias": "Victor Hwang",
+ "language": "und"
+ },
+ {
+ "pid": 51,
+ "source": "node/68",
+ "alias": "Margarite Safonova",
+ "language": "und"
+ },
+ {
+ "pid": 52,
+ "source": "node/69",
+ "alias": "Software/d2p",
+ "language": "und"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/static/archive/legacy-drupal/manifest.md b/static/archive/legacy-drupal/manifest.md
new file mode 100644
index 0000000..524a0b2
--- /dev/null
+++ b/static/archive/legacy-drupal/manifest.md
@@ -0,0 +1,423 @@
+# newwebsite/ manifest
+
+_Generated: 2026-05-10T00:58:39_
+
+**Total: 374 files, 770.2 MB**
+
+Sizes for each top-level subtree:
+
+| Subtree | Files | Size |
+|---------|------:|-----:|
+| `(top-level)` | 2 | 8.3 KB |
+| `content/` | 175 | 744.1 KB |
+| `data/` | 16 | 182.52 MB |
+| `media/` | 177 | 586.87 MB |
+| `reference/` | 2 | 25.9 KB |
+| `scripts/` | 2 | 62.6 KB |
+
+## `(top-level)`
+
+| Path | Size | Source |
+|------|-----:|--------|
+| `README.md` | 8.0 KB | human-readable overview of this folder |
+| `requirements.txt` | 240 B | Python deps (stdlib-only) |
+
+## `content/`
+
+| Path | Size | Source |
+|------|-----:|--------|
+| `content/blocks/001-private-files.html` | 280 B | extracted from `block_custom` table (sidebar/footer HTML) |
+| `content/blocks/001-private-files.json` | 553 B | extracted from `block_custom` table (sidebar/footer HTML) |
+| `content/blocks/001-private-files.md` | 91 B | extracted from `block_custom` table (sidebar/footer HTML) |
+| `content/blocks/002-publicfiles.html` | 190 B | extracted from `block_custom` table (sidebar/footer HTML) |
+| `content/blocks/002-publicfiles.json` | 347 B | extracted from `block_custom` table (sidebar/footer HTML) |
+| `content/blocks/002-publicfiles.md` | 69 B | extracted from `block_custom` table (sidebar/footer HTML) |
+| `content/blocks_index.json` | 546 B | index of every entry under content/blocks/ |
+| `content/menus.json` | 21.7 KB | extracted from `menu_links` table |
+| `content/pages/0003-people.html` | 2.9 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0003-people.json` | 8.1 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0003-people.md` | 1.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0009-home.html` | 3.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0009-home.json` | 9.9 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0009-home.md` | 1.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0010-publications.html` | 294 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0010-publications.json` | 859 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0010-publications.md` | 17 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0011-videos.html` | 7.4 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0011-videos.json` | 17.9 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0011-videos.md` | 1.4 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0012-robots.html` | 3.2 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0012-robots.json` | 9.3 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0012-robots.md` | 2.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0013-ben-cohen.html` | 158 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0013-ben-cohen.json` | 591 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0013-ben-cohen.md` | 39 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0014-brian-macallister.html` | 858 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0014-brian-macallister.json` | 2.0 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0014-brian-macallister.md` | 113 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0015-andrew-dornbush.html` | 160 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0015-andrew-dornbush.json` | 578 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0015-andrew-dornbush.md` | 35 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0016-subhrajit-bhattacharya.html` | 211 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0016-subhrajit-bhattacharya.json` | 710 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0016-subhrajit-bhattacharya.md` | 79 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0017-jonathan-butzke.html` | 1.9 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0017-jonathan-butzke.json` | 5.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0017-jonathan-butzke.md` | 1.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0018-chris-clingerman.html` | 199 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0018-chris-clingerman.json` | 692 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0018-chris-clingerman.md` | 73 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0019-john-drake.html` | 189 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0019-john-drake.json` | 680 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0019-john-drake.md` | 69 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0020-steven-gray.html` | 189 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0020-steven-gray.json` | 678 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0020-steven-gray.md` | 68 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0021-kalin-gochev.html` | 164 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0021-kalin-gochev.json` | 599 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0021-kalin-gochev.md` | 42 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0022-bradford-neuman.html` | 238 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0022-bradford-neuman.json` | 812 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0022-bradford-neuman.md` | 106 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0023-aline-normoyle.html` | 197 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0023-aline-normoyle.json` | 692 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0023-aline-normoyle.md` | 73 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0024-mike-phillips.html` | 178 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0024-mike-phillips.json` | 634 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0024-mike-phillips.md` | 46 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0025-venkatraman-narayanan.html` | 189 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0025-venkatraman-narayanan.json` | 648 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0025-venkatraman-narayanan.md` | 58 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0026-alex-kushleyev.html` | 158 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0026-alex-kushleyev.json` | 575 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0026-alex-kushleyev.md` | 34 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0027-harsh-pandey.html` | 152 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0027-harsh-pandey.json` | 563 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0027-harsh-pandey.md` | 30 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0028-kavan-mceachern.html` | 158 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0028-kavan-mceachern.json` | 572 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0028-kavan-mceachern.md` | 33 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0029-matthew-mac-allister.html` | 173 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0029-matthew-mac-allister.json` | 611 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0029-matthew-mac-allister.md` | 43 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0030-contact.html` | 1.3 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0030-contact.json` | 3.3 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0030-contact.md` | 436 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0031-login.html` | 116 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0031-login.json` | 473 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0031-login.md` | 10 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0032-software.html` | 30.7 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0032-software.json` | 95.4 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0032-software.md` | 30.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0033-untitled-33.html` | 259 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0033-untitled-33.json` | 772 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0033-untitled-33.md` | 16 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0039-eduardo-barrera.html` | 158 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0039-eduardo-barrera.json` | 573 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0039-eduardo-barrera.md` | 33 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0042-old-software.html` | 1.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0042-old-software.json` | 5.3 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0042-old-software.md` | 1.1 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0043-sandip-aine.html` | 166 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0043-sandip-aine.json` | 608 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0043-sandip-aine.md` | 45 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0044-calendar.html` | 350 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0044-calendar.json` | 975 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0044-calendar.md` | 13 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0045-tutorials.html` | 1.3 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0045-tutorials.json` | 4.0 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0045-tutorials.md` | 983 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0046-navigation-with-sbpl-in-x-y-theta.html` | 2.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0046-navigation-with-sbpl-in-x-y-theta.json` | 7.4 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0046-navigation-with-sbpl-in-x-y-theta.md` | 2.1 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0047-sbpl-overview.html` | 3.2 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0047-sbpl-overview.json` | 9.2 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0047-sbpl-overview.md` | 2.4 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0048-kinematic-constraints-and-motion-primitives.html` | 2.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0048-kinematic-constraints-and-motion-primitives.json` | 7.3 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0048-kinematic-constraints-and-motion-primitives.md` | 2.0 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0049-primer-to-the-search-based-planning-library-sbpl.html` | 9.1 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0049-primer-to-the-search-based-planning-library-sbpl.json` | 25.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0049-primer-to-the-search-based-planning-library-sbpl.md` | 7.0 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0050-primer-to-search-based-motion-planning.html` | 9.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0050-primer-to-search-based-motion-planning.json` | 27.0 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0050-primer-to-search-based-motion-planning.md` | 7.7 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.html` | 6.4 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.json` | 18.1 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0051-planning-with-sbpl-example-in-x-y-theta-state-space.md` | 4.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0052-generating-motion-primitives-with-sbpl.html` | 8.2 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0052-generating-motion-primitives-with-sbpl.json` | 24.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0052-generating-motion-primitives-with-sbpl.md` | 7.6 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0053-forward-arc-motion-primitives.html` | 45.0 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0053-forward-arc-motion-primitives.json` | 113.7 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0053-forward-arc-motion-primitives.md` | 17.1 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0054-building-installing-and-using-sbpl.html` | 4.2 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0054-building-installing-and-using-sbpl.json` | 12.3 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0054-building-installing-and-using-sbpl.md` | 3.4 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0055-arm-planning.html` | 6.7 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0055-arm-planning.json` | 17.1 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0055-arm-planning.md` | 2.5 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0056-aram-ebtekar.html` | 157 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0056-aram-ebtekar.json` | 586 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0056-aram-ebtekar.md` | 35 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0057-kush-prasad.html` | 151 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0057-kush-prasad.json` | 571 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0057-kush-prasad.md` | 30 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0058-sung-kyun-kim.html` | 153 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0058-sung-kyun-kim.json` | 571 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0058-sung-kyun-kim.md` | 30 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0059-soonkyum-kim.html` | 147 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0059-soonkyum-kim.json` | 556 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0059-soonkyum-kim.md` | 25 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0060-siddharth-swaminathan.html` | 172 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0060-siddharth-swaminathan.json` | 604 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0060-siddharth-swaminathan.md` | 41 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0061-chen-gao.html` | 146 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0061-chen-gao.json` | 565 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0061-chen-gao.md` | 28 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0062-ellis-ratner.html` | 171 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0062-ellis-ratner.json` | 628 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0062-ellis-ratner.md` | 49 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0063-krishna-sapkota.html` | 158 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0063-krishna-sapkota.json` | 578 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0063-krishna-sapkota.md` | 33 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0064-burak-yucesoy.html` | 154 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0064-burak-yucesoy.json` | 572 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0064-burak-yucesoy.md` | 31 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0065-arjun-menon.html` | 140 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0065-arjun-menon.json` | 538 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0065-arjun-menon.md` | 19 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0066-hao-wang.html` | 146 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0066-hao-wang.json` | 565 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0066-hao-wang.md` | 28 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0067-victor-hwang.html` | 154 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0067-victor-hwang.json` | 576 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0067-victor-hwang.md` | 32 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0068-margarite-safonova.html` | 169 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0068-margarite-safonova.json` | 604 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0068-margarite-safonova.md` | 41 B | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0069-discriminatively-guided-deliberative-perception-for-pose-estimation-of-multiple-3d-object-instances.html` | 2.0 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0069-discriminatively-guided-deliberative-perception-for-pose-estimation-of-multiple-3d-object-instances.json` | 5.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/pages/0069-discriminatively-guided-deliberative-perception-for-pose-estimation-of-multiple-3d-object-instances.md` | 1.8 KB | extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`) |
+| `content/site_variables.json` | 378 B | curated subset of `variable` (site_name, theme, etc.) |
+| `content/users.json` | 7.4 KB | extracted from `users` + `users_roles` + `role` (passwords stripped, spam accounts filtered) |
+
+## `data/`
+
+| Path | Size | Source |
+|------|-----:|--------|
+| `data/comments.json` | 2 B | extracted from `comment` + `field_data_comment_body` |
+| `data/contact_categories.json` | 146 B | extracted from `contact` table |
+| `data/drupal_variables.json` | 17.6 KB | all `variable` rows, PHP-decoded |
+| `data/file_usage.json` | 286 B | extracted from `file_usage` table |
+| `data/files_managed.json` | 722 B | extracted from `file_managed` table |
+| `data/node_types.json` | 747 B | extracted from `node_type` table |
+| `data/page_field_image.json` | 2 B | extracted from `field_data_field_image` |
+| `data/page_field_page_file.json` | 2 B | extracted from `field_data_field_page_file` |
+| `data/page_field_tags.json` | 2 B | extracted from `field_data_field_tags` |
+| `data/pages_index.csv` | 11.3 KB | generated by scripts/extract.py |
+| `data/raw/drupal_dump.sql` | 22.2 MB | verbatim copy of ../drupal_dump.sql |
+| `data/raw/dump-2018-04-12.sql` | 160.2 MB | verbatim copy of ../dump-2018-04-12.sql |
+| `data/roles.json` | 4.7 KB | extracted from `role` + `role_permission` |
+| `data/taxonomy.json` | 295 B | extracted from `taxonomy_vocabulary` + `taxonomy_term_data` + `taxonomy_term_hierarchy` + `taxonomy_index` |
+| `data/text_formats.json` | 5.6 KB | extracted from `filter_format` + `filter` |
+| `data/url_aliases.json` | 12.2 KB | extracted from `url_alias` table (Drupal path aliases per node) |
+
+## `media/`
+
+| Path | Size | Source |
+|------|-----:|--------|
+| `media/images/17K4g.png` | 665.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/1FghC.gif` | 1.8 MB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/1IOLc.png` | 679.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/2012-07-05-212032.jpg` | 129.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/2822.jpg` | 79.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/2uktC.png` | 62.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/3ptkg6.jpg` | 134.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/3pyrjf(1).jpg` | 88.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/3pyrjf.jpg` | 88.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/4ty7b.jpg` | 361.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/9oIuo.jpg` | 65.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/Awesome.png` | 183.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/BasePrim(1).jpg` | 190.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/BasePrim.jpg` | 190.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/DSC00420.JPG` | 140.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/IMG_2895.JPG` | 2.1 MB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/IMG_2895_small.jpeg` | 14.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/IMG_2896.JPG` | 2.3 MB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/IMG_2896_small.jpeg` | 17.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/IMG_2897.JPG` | 2.2 MB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/IMG_2897_small.jpeg` | 25.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc10x.png` | 399 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc110x.png` | 364 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc111x.png` | 192 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc112x.png` | 209 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc113x.png` | 1.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc114x.png` | 1.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc115x.png` | 254 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc116x.png` | 262 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc117x.png` | 1.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc118x.png` | 1.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc119x.png` | 1.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc11x.png` | 879 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc120x.png` | 2.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc121x.png` | 210 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc122x.png` | 2.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc123x.png` | 1.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc124x.png` | 2.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc125x.png` | 997 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc126x.png` | 349 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc127x.png` | 201 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc128x.png` | 210 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc129x.png` | 781 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc12x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc130x.png` | 207 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc131x.png` | 406 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc13x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc14x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc15x.png` | 272 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc16x.png` | 221 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc17x.png` | 226 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc18x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/LatextDoc19x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/MC-UAV-1-2.jpg` | 45.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/MC-UAV-1-2_small.jpeg` | 5.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/MC-UAV-3.jpg` | 725.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/MotionPrimitives.jpg` | 256.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/PathGen.jpg` | 43.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/Screenshot-69.png` | 707.0 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/Screenshot.png` | 138.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/VdayFinal.jpg` | 4.6 MB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/VdayFinal_small.jpeg` | 30.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/17K4g.png` | 13.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/1FghC.gif` | 5.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/1IOLc.png` | 16.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/2012-07-05-212032.jpg` | 1.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/2822.jpg` | 3.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/2uktC.png` | 9.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/3ptkg6.jpg` | 3.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/3pyrjf(1).jpg` | 3.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/3pyrjf.jpg` | 3.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/4ty7b.jpg` | 1.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/9oIuo.jpg` | 3.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/Awesome.png` | 10.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/BasePrim(1).jpg` | 1.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/BasePrim.jpg` | 1.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/DSC00420.JPG` | 3.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/IMG_2895.JPG` | 2.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/IMG_2895_small.jpeg` | 2.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/IMG_2896.JPG` | 2.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/IMG_2896_small.jpeg` | 2.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/IMG_2897.JPG` | 2.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/IMG_2897_small.jpeg` | 2.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc10x.png` | 399 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc110x.png` | 364 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc111x.png` | 192 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc112x.png` | 209 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc113x.png` | 1.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc114x.png` | 1.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc115x.png` | 254 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc116x.png` | 262 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc117x.png` | 3.0 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc118x.png` | 1.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc119x.png` | 3.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc11x.png` | 1.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc120x.png` | 2.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc121x.png` | 210 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc122x.png` | 2.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc123x.png` | 3.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc124x.png` | 2.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc125x.png` | 1.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc126x.png` | 349 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc127x.png` | 201 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc128x.png` | 210 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc129x.png` | 1.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc12x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc130x.png` | 207 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc131x.png` | 406 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc13x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc14x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc15x.png` | 272 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc16x.png` | 221 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc17x.png` | 226 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc18x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/LatextDoc19x.png` | 197 B | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/MC-UAV-1-2.jpg` | 1.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/MC-UAV-1-2_small.jpeg` | 1.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/MC-UAV-3.jpg` | 2.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/MotionPrimitives.jpg` | 1.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/PathGen.jpg` | 1.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/Screenshot-69.png` | 7.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/Screenshot.png` | 6.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/VdayFinal.jpg` | 3.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/VdayFinal_small.jpeg` | 3.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/andrew-mike-kenny.jpg` | 2.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/brian-kenny-shooped.jpg` | 3.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/brian-kenny.jpg` | 3.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/brian.jpg` | 2.9 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/fig1.jpg` | 1.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/fig2.jpg` | 1.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/fig3.jpg` | 1.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/kin2.png` | 8.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/matt-ed-jon-kenny.jpg` | 3.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/mprims.png` | 5.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/primer1.png` | 2.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/segbot_small.png` | 17.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/tree.png` | 10.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/tumblr_inline_mkp8yrkzjm1qz4rgp.png` | 8.0 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/_thumbs/unaligned_mprims.png` | 3.8 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/andrew-mike-kenny.jpg` | 400.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/brian-kenny-shooped.jpg` | 191.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/brian-kenny.jpg` | 194.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/brian.jpg` | 384.1 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/fig1.jpg` | 113.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/fig2.jpg` | 22.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/fig3.jpg` | 23.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/kin2.png` | 100.6 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/matt-ed-jon-kenny.jpg` | 888.2 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/mprims.png` | 15.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/primer1.png` | 25.3 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/segbot_small.png` | 105.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/tree.png` | 124.4 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/tumblr_inline_mkp8yrkzjm1qz4rgp.png` | 40.5 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/images/unaligned_mprims.png` | 8.7 KB | copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/) |
+| `media/logos/sbpl_logo2_transparent.png` | 36.8 KB | copied from drupal-7.33/sites/default/files/sbpl_logo2_* |
+| `media/logos/sbpl_logo2_transparent_70percent.png` | 29.6 KB | copied from drupal-7.33/sites/default/files/sbpl_logo2_* |
+| `media/pictures/picture-13-1342204530.jpg` | 468.8 KB | copied from drupal-7.33/sites/default/files/pictures/ |
+| `media/pictures/picture-32-1344464691.jpg` | 240.7 KB | copied from drupal-7.33/sites/default/files/pictures/ |
+| `media/pictures/picture-33-1344493553.jpg` | 9.5 KB | copied from drupal-7.33/sites/default/files/pictures/ |
+| `media/uploads/Images/3jZ04.png` | 15.6 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/ImagesImages/VdayFinal.jpg` | 4.6 MB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/SBPL/index.html` | 817 B | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/SBPL/sbpl.tar.gz` | 611.4 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/SBPL/sbpl.zip` | 687.4 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/_thumbs/Images/3jZ04.png` | 2.1 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/resize/site/all/images/segbot-284x231.png` | 109.2 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/site/all/images/hexarotor.png` | 47.9 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/site/all/images/pr2_grasp.png` | 88.2 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/site/all/images/rtfm.png` | 41.0 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/site/all/images/secretary_part_3.png` | 123.1 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/site/all/images/segbot.png` | 388.7 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/uploads/site/all/images/steal_this_comic.png` | 44.4 KB | copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/ |
+| `media/videos/beam_graphs.mp4` | 8.8 MB | copied from Desktop/, Downloads/ and drupal-7.33/shared/Venkat/ICRA13/ |
+| `media/videos/crashes1.wmv` | 6.1 MB | copied from Desktop/, Downloads/ and drupal-7.33/shared/Venkat/ICRA13/ |
+| `media/videos/icra2_HD.mp4` | 116.3 MB | copied from Desktop/, Downloads/ and drupal-7.33/shared/Venkat/ICRA13/ |
+| `media/videos/manip1_collect.mp4` | 230.0 MB | copied from Desktop/, Downloads/ and drupal-7.33/shared/Venkat/ICRA13/ |
+| `media/videos/sbpl_flight_march17.mp4` | 197.2 MB | copied from Desktop/, Downloads/ and drupal-7.33/shared/Venkat/ICRA13/ |
+
+## `reference/`
+
+| Path | Size | Source |
+|------|-----:|--------|
+| `reference/original_settings.php` | 21.1 KB | copy of ../settings.php with passwords + drupal_hash_salt redacted |
+| `reference/website_installation_procedure.md` | 4.9 KB | verbatim copy of ../website_installation_procedure.md |
+
+## `scripts/`
+
+_Source: in-tree extraction tooling_
+
+| Path | Size | Source |
+|------|-----:|--------|
+| `scripts/build_manifest.py` | 6.3 KB | in-tree extraction tooling |
+| `scripts/extract.py` | 56.3 KB | in-tree extraction tooling |
+
diff --git a/static/archive/legacy-drupal/media/images/17K4g.png b/static/archive/legacy-drupal/media/images/17K4g.png
new file mode 100755
index 0000000..6529b04
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/17K4g.png differ
diff --git a/static/archive/legacy-drupal/media/images/1FghC.gif b/static/archive/legacy-drupal/media/images/1FghC.gif
new file mode 100755
index 0000000..ddad6ba
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/1FghC.gif differ
diff --git a/static/archive/legacy-drupal/media/images/1IOLc.png b/static/archive/legacy-drupal/media/images/1IOLc.png
new file mode 100755
index 0000000..1350a20
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/1IOLc.png differ
diff --git a/static/archive/legacy-drupal/media/images/2012-07-05-212032.jpg b/static/archive/legacy-drupal/media/images/2012-07-05-212032.jpg
new file mode 100755
index 0000000..4a7a1df
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/2012-07-05-212032.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/2822.jpg b/static/archive/legacy-drupal/media/images/2822.jpg
new file mode 100755
index 0000000..29bbc19
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/2822.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/2uktC.png b/static/archive/legacy-drupal/media/images/2uktC.png
new file mode 100755
index 0000000..9ba7d62
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/2uktC.png differ
diff --git a/static/archive/legacy-drupal/media/images/3ptkg6.jpg b/static/archive/legacy-drupal/media/images/3ptkg6.jpg
new file mode 100755
index 0000000..c03b8ca
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/3ptkg6.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/3pyrjf(1).jpg b/static/archive/legacy-drupal/media/images/3pyrjf(1).jpg
new file mode 100755
index 0000000..a940fe5
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/3pyrjf(1).jpg differ
diff --git a/static/archive/legacy-drupal/media/images/3pyrjf.jpg b/static/archive/legacy-drupal/media/images/3pyrjf.jpg
new file mode 100755
index 0000000..a940fe5
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/3pyrjf.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/4ty7b.jpg b/static/archive/legacy-drupal/media/images/4ty7b.jpg
new file mode 100755
index 0000000..ed17a46
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/4ty7b.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/9oIuo.jpg b/static/archive/legacy-drupal/media/images/9oIuo.jpg
new file mode 100755
index 0000000..7ce5170
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/9oIuo.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/Awesome.png b/static/archive/legacy-drupal/media/images/Awesome.png
new file mode 100755
index 0000000..11b7257
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/Awesome.png differ
diff --git a/static/archive/legacy-drupal/media/images/BasePrim(1).jpg b/static/archive/legacy-drupal/media/images/BasePrim(1).jpg
new file mode 100755
index 0000000..285ed04
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/BasePrim(1).jpg differ
diff --git a/static/archive/legacy-drupal/media/images/BasePrim.jpg b/static/archive/legacy-drupal/media/images/BasePrim.jpg
new file mode 100755
index 0000000..285ed04
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/BasePrim.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/DSC00420.JPG b/static/archive/legacy-drupal/media/images/DSC00420.JPG
new file mode 100755
index 0000000..f95b3eb
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/DSC00420.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/IMG_2895.JPG b/static/archive/legacy-drupal/media/images/IMG_2895.JPG
new file mode 100755
index 0000000..89ff59c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/IMG_2895.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/IMG_2895_small.jpeg b/static/archive/legacy-drupal/media/images/IMG_2895_small.jpeg
new file mode 100755
index 0000000..0b7f242
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/IMG_2895_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/IMG_2896.JPG b/static/archive/legacy-drupal/media/images/IMG_2896.JPG
new file mode 100755
index 0000000..7762c3f
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/IMG_2896.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/IMG_2896_small.jpeg b/static/archive/legacy-drupal/media/images/IMG_2896_small.jpeg
new file mode 100755
index 0000000..296e75b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/IMG_2896_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/IMG_2897.JPG b/static/archive/legacy-drupal/media/images/IMG_2897.JPG
new file mode 100755
index 0000000..aec9c81
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/IMG_2897.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/IMG_2897_small.jpeg b/static/archive/legacy-drupal/media/images/IMG_2897_small.jpeg
new file mode 100755
index 0000000..84de20e
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/IMG_2897_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc10x.png b/static/archive/legacy-drupal/media/images/LatextDoc10x.png
new file mode 100755
index 0000000..21aee7e
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc10x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc110x.png b/static/archive/legacy-drupal/media/images/LatextDoc110x.png
new file mode 100755
index 0000000..51ed0ba
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc110x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc111x.png b/static/archive/legacy-drupal/media/images/LatextDoc111x.png
new file mode 100755
index 0000000..9e452e9
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc111x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc112x.png b/static/archive/legacy-drupal/media/images/LatextDoc112x.png
new file mode 100755
index 0000000..5a1a8ef
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc112x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc113x.png b/static/archive/legacy-drupal/media/images/LatextDoc113x.png
new file mode 100755
index 0000000..0dff7f9
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc113x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc114x.png b/static/archive/legacy-drupal/media/images/LatextDoc114x.png
new file mode 100755
index 0000000..567f242
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc114x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc115x.png b/static/archive/legacy-drupal/media/images/LatextDoc115x.png
new file mode 100755
index 0000000..f35d86c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc115x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc116x.png b/static/archive/legacy-drupal/media/images/LatextDoc116x.png
new file mode 100755
index 0000000..9fbbdb3
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc116x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc117x.png b/static/archive/legacy-drupal/media/images/LatextDoc117x.png
new file mode 100755
index 0000000..bdc2454
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc117x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc118x.png b/static/archive/legacy-drupal/media/images/LatextDoc118x.png
new file mode 100755
index 0000000..dd4ddb2
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc118x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc119x.png b/static/archive/legacy-drupal/media/images/LatextDoc119x.png
new file mode 100755
index 0000000..1fdbed0
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc119x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc11x.png b/static/archive/legacy-drupal/media/images/LatextDoc11x.png
new file mode 100755
index 0000000..bfa7c7c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc11x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc120x.png b/static/archive/legacy-drupal/media/images/LatextDoc120x.png
new file mode 100755
index 0000000..2974312
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc120x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc121x.png b/static/archive/legacy-drupal/media/images/LatextDoc121x.png
new file mode 100755
index 0000000..e6e7058
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc121x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc122x.png b/static/archive/legacy-drupal/media/images/LatextDoc122x.png
new file mode 100755
index 0000000..16a2639
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc122x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc123x.png b/static/archive/legacy-drupal/media/images/LatextDoc123x.png
new file mode 100755
index 0000000..3328840
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc123x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc124x.png b/static/archive/legacy-drupal/media/images/LatextDoc124x.png
new file mode 100755
index 0000000..b212708
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc124x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc125x.png b/static/archive/legacy-drupal/media/images/LatextDoc125x.png
new file mode 100755
index 0000000..376c6a4
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc125x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc126x.png b/static/archive/legacy-drupal/media/images/LatextDoc126x.png
new file mode 100755
index 0000000..1732e70
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc126x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc127x.png b/static/archive/legacy-drupal/media/images/LatextDoc127x.png
new file mode 100755
index 0000000..e0e2cb4
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc127x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc128x.png b/static/archive/legacy-drupal/media/images/LatextDoc128x.png
new file mode 100755
index 0000000..e6e7058
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc128x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc129x.png b/static/archive/legacy-drupal/media/images/LatextDoc129x.png
new file mode 100755
index 0000000..9b32060
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc129x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc12x.png b/static/archive/legacy-drupal/media/images/LatextDoc12x.png
new file mode 100755
index 0000000..7e21b53
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc12x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc130x.png b/static/archive/legacy-drupal/media/images/LatextDoc130x.png
new file mode 100755
index 0000000..0bf351b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc130x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc131x.png b/static/archive/legacy-drupal/media/images/LatextDoc131x.png
new file mode 100755
index 0000000..2cffa00
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc131x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc13x.png b/static/archive/legacy-drupal/media/images/LatextDoc13x.png
new file mode 100755
index 0000000..7e21b53
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc13x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc14x.png b/static/archive/legacy-drupal/media/images/LatextDoc14x.png
new file mode 100755
index 0000000..7e21b53
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc14x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc15x.png b/static/archive/legacy-drupal/media/images/LatextDoc15x.png
new file mode 100755
index 0000000..907963c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc15x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc16x.png b/static/archive/legacy-drupal/media/images/LatextDoc16x.png
new file mode 100755
index 0000000..d015d34
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc16x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc17x.png b/static/archive/legacy-drupal/media/images/LatextDoc17x.png
new file mode 100755
index 0000000..68174d1
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc17x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc18x.png b/static/archive/legacy-drupal/media/images/LatextDoc18x.png
new file mode 100755
index 0000000..2f19f7b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc18x.png differ
diff --git a/static/archive/legacy-drupal/media/images/LatextDoc19x.png b/static/archive/legacy-drupal/media/images/LatextDoc19x.png
new file mode 100755
index 0000000..2f19f7b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/LatextDoc19x.png differ
diff --git a/static/archive/legacy-drupal/media/images/MC-UAV-1-2.jpg b/static/archive/legacy-drupal/media/images/MC-UAV-1-2.jpg
new file mode 100755
index 0000000..fed46c3
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/MC-UAV-1-2.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/MC-UAV-1-2_small.jpeg b/static/archive/legacy-drupal/media/images/MC-UAV-1-2_small.jpeg
new file mode 100755
index 0000000..b73ce54
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/MC-UAV-1-2_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/MC-UAV-3.jpg b/static/archive/legacy-drupal/media/images/MC-UAV-3.jpg
new file mode 100755
index 0000000..18f4709
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/MC-UAV-3.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/MotionPrimitives.jpg b/static/archive/legacy-drupal/media/images/MotionPrimitives.jpg
new file mode 100755
index 0000000..934ee6f
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/MotionPrimitives.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/PathGen.jpg b/static/archive/legacy-drupal/media/images/PathGen.jpg
new file mode 100755
index 0000000..c2b57bd
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/PathGen.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/Screenshot-69.png b/static/archive/legacy-drupal/media/images/Screenshot-69.png
new file mode 100755
index 0000000..d7d0567
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/Screenshot-69.png differ
diff --git a/static/archive/legacy-drupal/media/images/Screenshot.png b/static/archive/legacy-drupal/media/images/Screenshot.png
new file mode 100755
index 0000000..9e37e8b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/Screenshot.png differ
diff --git a/static/archive/legacy-drupal/media/images/VdayFinal.jpg b/static/archive/legacy-drupal/media/images/VdayFinal.jpg
new file mode 100755
index 0000000..44348bd
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/VdayFinal.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/VdayFinal_small.jpeg b/static/archive/legacy-drupal/media/images/VdayFinal_small.jpeg
new file mode 100755
index 0000000..265b1d3
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/VdayFinal_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/17K4g.png b/static/archive/legacy-drupal/media/images/_thumbs/17K4g.png
new file mode 100755
index 0000000..be82819
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/17K4g.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/1FghC.gif b/static/archive/legacy-drupal/media/images/_thumbs/1FghC.gif
new file mode 100755
index 0000000..afcc2fb
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/1FghC.gif differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/1IOLc.png b/static/archive/legacy-drupal/media/images/_thumbs/1IOLc.png
new file mode 100755
index 0000000..e7a714b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/1IOLc.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/2012-07-05-212032.jpg b/static/archive/legacy-drupal/media/images/_thumbs/2012-07-05-212032.jpg
new file mode 100755
index 0000000..fa71e32
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/2012-07-05-212032.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/2822.jpg b/static/archive/legacy-drupal/media/images/_thumbs/2822.jpg
new file mode 100755
index 0000000..711e1b9
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/2822.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/2uktC.png b/static/archive/legacy-drupal/media/images/_thumbs/2uktC.png
new file mode 100755
index 0000000..6036d33
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/2uktC.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/3ptkg6.jpg b/static/archive/legacy-drupal/media/images/_thumbs/3ptkg6.jpg
new file mode 100755
index 0000000..fe98e63
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/3ptkg6.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/3pyrjf(1).jpg b/static/archive/legacy-drupal/media/images/_thumbs/3pyrjf(1).jpg
new file mode 100755
index 0000000..7e2c219
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/3pyrjf(1).jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/3pyrjf.jpg b/static/archive/legacy-drupal/media/images/_thumbs/3pyrjf.jpg
new file mode 100755
index 0000000..7e2c219
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/3pyrjf.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/4ty7b.jpg b/static/archive/legacy-drupal/media/images/_thumbs/4ty7b.jpg
new file mode 100755
index 0000000..730e5dd
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/4ty7b.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/9oIuo.jpg b/static/archive/legacy-drupal/media/images/_thumbs/9oIuo.jpg
new file mode 100755
index 0000000..ee862b2
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/9oIuo.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/Awesome.png b/static/archive/legacy-drupal/media/images/_thumbs/Awesome.png
new file mode 100755
index 0000000..1fb0ec1
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/Awesome.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/BasePrim(1).jpg b/static/archive/legacy-drupal/media/images/_thumbs/BasePrim(1).jpg
new file mode 100755
index 0000000..4abc238
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/BasePrim(1).jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/BasePrim.jpg b/static/archive/legacy-drupal/media/images/_thumbs/BasePrim.jpg
new file mode 100755
index 0000000..4abc238
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/BasePrim.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/DSC00420.JPG b/static/archive/legacy-drupal/media/images/_thumbs/DSC00420.JPG
new file mode 100755
index 0000000..ec4443a
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/DSC00420.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/IMG_2895.JPG b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2895.JPG
new file mode 100755
index 0000000..f7eb51c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2895.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/IMG_2895_small.jpeg b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2895_small.jpeg
new file mode 100755
index 0000000..d867b7d
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2895_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/IMG_2896.JPG b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2896.JPG
new file mode 100755
index 0000000..e0c7c17
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2896.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/IMG_2896_small.jpeg b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2896_small.jpeg
new file mode 100755
index 0000000..6d961b5
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2896_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/IMG_2897.JPG b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2897.JPG
new file mode 100755
index 0000000..0822120
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2897.JPG differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/IMG_2897_small.jpeg b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2897_small.jpeg
new file mode 100755
index 0000000..3ba06b9
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/IMG_2897_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc10x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc10x.png
new file mode 100644
index 0000000..21aee7e
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc10x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc110x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc110x.png
new file mode 100644
index 0000000..51ed0ba
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc110x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc111x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc111x.png
new file mode 100644
index 0000000..9e452e9
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc111x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc112x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc112x.png
new file mode 100644
index 0000000..5a1a8ef
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc112x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc113x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc113x.png
new file mode 100755
index 0000000..9605e3e
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc113x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc114x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc114x.png
new file mode 100755
index 0000000..f5fa6b8
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc114x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc115x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc115x.png
new file mode 100644
index 0000000..f35d86c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc115x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc116x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc116x.png
new file mode 100644
index 0000000..9fbbdb3
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc116x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc117x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc117x.png
new file mode 100755
index 0000000..db112f7
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc117x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc118x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc118x.png
new file mode 100755
index 0000000..55d1563
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc118x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc119x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc119x.png
new file mode 100755
index 0000000..1e1a0ab
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc119x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc11x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc11x.png
new file mode 100755
index 0000000..46cd51d
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc11x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc120x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc120x.png
new file mode 100755
index 0000000..d7849d1
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc120x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc121x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc121x.png
new file mode 100644
index 0000000..e6e7058
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc121x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc122x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc122x.png
new file mode 100755
index 0000000..ece698a
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc122x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc123x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc123x.png
new file mode 100755
index 0000000..e308ace
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc123x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc124x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc124x.png
new file mode 100755
index 0000000..639a6b3
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc124x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc125x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc125x.png
new file mode 100755
index 0000000..fe3f8ab
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc125x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc126x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc126x.png
new file mode 100644
index 0000000..1732e70
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc126x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc127x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc127x.png
new file mode 100644
index 0000000..e0e2cb4
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc127x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc128x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc128x.png
new file mode 100644
index 0000000..e6e7058
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc128x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc129x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc129x.png
new file mode 100755
index 0000000..67cc16a
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc129x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc12x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc12x.png
new file mode 100644
index 0000000..7e21b53
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc12x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc130x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc130x.png
new file mode 100644
index 0000000..0bf351b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc130x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc131x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc131x.png
new file mode 100644
index 0000000..2cffa00
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc131x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc13x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc13x.png
new file mode 100644
index 0000000..7e21b53
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc13x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc14x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc14x.png
new file mode 100644
index 0000000..7e21b53
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc14x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc15x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc15x.png
new file mode 100644
index 0000000..907963c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc15x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc16x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc16x.png
new file mode 100644
index 0000000..d015d34
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc16x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc17x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc17x.png
new file mode 100644
index 0000000..68174d1
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc17x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc18x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc18x.png
new file mode 100644
index 0000000..2f19f7b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc18x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc19x.png b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc19x.png
new file mode 100644
index 0000000..2f19f7b
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/LatextDoc19x.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-1-2.jpg b/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-1-2.jpg
new file mode 100755
index 0000000..0b043e7
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-1-2.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-1-2_small.jpeg b/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-1-2_small.jpeg
new file mode 100755
index 0000000..4295bfa
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-1-2_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-3.jpg b/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-3.jpg
new file mode 100755
index 0000000..2268bd0
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/MC-UAV-3.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/MotionPrimitives.jpg b/static/archive/legacy-drupal/media/images/_thumbs/MotionPrimitives.jpg
new file mode 100755
index 0000000..88d6c87
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/MotionPrimitives.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/PathGen.jpg b/static/archive/legacy-drupal/media/images/_thumbs/PathGen.jpg
new file mode 100755
index 0000000..140083c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/PathGen.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/Screenshot-69.png b/static/archive/legacy-drupal/media/images/_thumbs/Screenshot-69.png
new file mode 100755
index 0000000..38fe05e
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/Screenshot-69.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/Screenshot.png b/static/archive/legacy-drupal/media/images/_thumbs/Screenshot.png
new file mode 100755
index 0000000..e576a27
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/Screenshot.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/VdayFinal.jpg b/static/archive/legacy-drupal/media/images/_thumbs/VdayFinal.jpg
new file mode 100755
index 0000000..8dd8a27
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/VdayFinal.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/VdayFinal_small.jpeg b/static/archive/legacy-drupal/media/images/_thumbs/VdayFinal_small.jpeg
new file mode 100755
index 0000000..72a89a9
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/VdayFinal_small.jpeg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/andrew-mike-kenny.jpg b/static/archive/legacy-drupal/media/images/_thumbs/andrew-mike-kenny.jpg
new file mode 100755
index 0000000..a7ea4ce
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/andrew-mike-kenny.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/brian-kenny-shooped.jpg b/static/archive/legacy-drupal/media/images/_thumbs/brian-kenny-shooped.jpg
new file mode 100755
index 0000000..d0c25a3
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/brian-kenny-shooped.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/brian-kenny.jpg b/static/archive/legacy-drupal/media/images/_thumbs/brian-kenny.jpg
new file mode 100755
index 0000000..96ace4c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/brian-kenny.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/brian.jpg b/static/archive/legacy-drupal/media/images/_thumbs/brian.jpg
new file mode 100755
index 0000000..48b944d
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/brian.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/fig1.jpg b/static/archive/legacy-drupal/media/images/_thumbs/fig1.jpg
new file mode 100755
index 0000000..16e5449
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/fig1.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/fig2.jpg b/static/archive/legacy-drupal/media/images/_thumbs/fig2.jpg
new file mode 100755
index 0000000..3cfcf59
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/fig2.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/fig3.jpg b/static/archive/legacy-drupal/media/images/_thumbs/fig3.jpg
new file mode 100755
index 0000000..5e7d632
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/fig3.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/kin2.png b/static/archive/legacy-drupal/media/images/_thumbs/kin2.png
new file mode 100755
index 0000000..f9cef8f
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/kin2.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/matt-ed-jon-kenny.jpg b/static/archive/legacy-drupal/media/images/_thumbs/matt-ed-jon-kenny.jpg
new file mode 100755
index 0000000..97dd48f
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/matt-ed-jon-kenny.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/mprims.png b/static/archive/legacy-drupal/media/images/_thumbs/mprims.png
new file mode 100755
index 0000000..cd94ffb
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/mprims.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/primer1.png b/static/archive/legacy-drupal/media/images/_thumbs/primer1.png
new file mode 100755
index 0000000..8897964
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/primer1.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/segbot_small.png b/static/archive/legacy-drupal/media/images/_thumbs/segbot_small.png
new file mode 100755
index 0000000..c1fd8af
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/segbot_small.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/tree.png b/static/archive/legacy-drupal/media/images/_thumbs/tree.png
new file mode 100755
index 0000000..b47b1b4
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/tree.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/tumblr_inline_mkp8yrkzjm1qz4rgp.png b/static/archive/legacy-drupal/media/images/_thumbs/tumblr_inline_mkp8yrkzjm1qz4rgp.png
new file mode 100755
index 0000000..8857897
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/tumblr_inline_mkp8yrkzjm1qz4rgp.png differ
diff --git a/static/archive/legacy-drupal/media/images/_thumbs/unaligned_mprims.png b/static/archive/legacy-drupal/media/images/_thumbs/unaligned_mprims.png
new file mode 100755
index 0000000..3d678a0
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/_thumbs/unaligned_mprims.png differ
diff --git a/static/archive/legacy-drupal/media/images/andrew-mike-kenny.jpg b/static/archive/legacy-drupal/media/images/andrew-mike-kenny.jpg
new file mode 100755
index 0000000..f6ac2ac
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/andrew-mike-kenny.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/brian-kenny-shooped.jpg b/static/archive/legacy-drupal/media/images/brian-kenny-shooped.jpg
new file mode 100755
index 0000000..0c773d0
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/brian-kenny-shooped.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/brian-kenny.jpg b/static/archive/legacy-drupal/media/images/brian-kenny.jpg
new file mode 100755
index 0000000..7a6238a
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/brian-kenny.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/brian.jpg b/static/archive/legacy-drupal/media/images/brian.jpg
new file mode 100755
index 0000000..e5cace3
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/brian.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/fig1.jpg b/static/archive/legacy-drupal/media/images/fig1.jpg
new file mode 100755
index 0000000..4c73a3d
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/fig1.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/fig2.jpg b/static/archive/legacy-drupal/media/images/fig2.jpg
new file mode 100755
index 0000000..1b30f18
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/fig2.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/fig3.jpg b/static/archive/legacy-drupal/media/images/fig3.jpg
new file mode 100755
index 0000000..3922fde
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/fig3.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/kin2.png b/static/archive/legacy-drupal/media/images/kin2.png
new file mode 100755
index 0000000..a3e10d8
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/kin2.png differ
diff --git a/static/archive/legacy-drupal/media/images/matt-ed-jon-kenny.jpg b/static/archive/legacy-drupal/media/images/matt-ed-jon-kenny.jpg
new file mode 100755
index 0000000..1d5492c
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/matt-ed-jon-kenny.jpg differ
diff --git a/static/archive/legacy-drupal/media/images/mprims.png b/static/archive/legacy-drupal/media/images/mprims.png
new file mode 100755
index 0000000..0afe4d2
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/mprims.png differ
diff --git a/static/archive/legacy-drupal/media/images/primer1.png b/static/archive/legacy-drupal/media/images/primer1.png
new file mode 100755
index 0000000..6022929
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/primer1.png differ
diff --git a/static/archive/legacy-drupal/media/images/segbot_small.png b/static/archive/legacy-drupal/media/images/segbot_small.png
new file mode 100755
index 0000000..7a5fcfd
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/segbot_small.png differ
diff --git a/static/archive/legacy-drupal/media/images/tree.png b/static/archive/legacy-drupal/media/images/tree.png
new file mode 100755
index 0000000..86eab26
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/tree.png differ
diff --git a/static/archive/legacy-drupal/media/images/tumblr_inline_mkp8yrkzjm1qz4rgp.png b/static/archive/legacy-drupal/media/images/tumblr_inline_mkp8yrkzjm1qz4rgp.png
new file mode 100755
index 0000000..afebe76
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/tumblr_inline_mkp8yrkzjm1qz4rgp.png differ
diff --git a/static/archive/legacy-drupal/media/images/unaligned_mprims.png b/static/archive/legacy-drupal/media/images/unaligned_mprims.png
new file mode 100755
index 0000000..769d377
Binary files /dev/null and b/static/archive/legacy-drupal/media/images/unaligned_mprims.png differ
diff --git a/static/archive/legacy-drupal/media/logos/sbpl_logo2_transparent.png b/static/archive/legacy-drupal/media/logos/sbpl_logo2_transparent.png
new file mode 100644
index 0000000..df2f943
Binary files /dev/null and b/static/archive/legacy-drupal/media/logos/sbpl_logo2_transparent.png differ
diff --git a/static/archive/legacy-drupal/media/logos/sbpl_logo2_transparent_70percent.png b/static/archive/legacy-drupal/media/logos/sbpl_logo2_transparent_70percent.png
new file mode 100644
index 0000000..919ca50
Binary files /dev/null and b/static/archive/legacy-drupal/media/logos/sbpl_logo2_transparent_70percent.png differ
diff --git a/static/archive/legacy-drupal/media/pictures/picture-13-1342204530.jpg b/static/archive/legacy-drupal/media/pictures/picture-13-1342204530.jpg
new file mode 100644
index 0000000..6abea31
Binary files /dev/null and b/static/archive/legacy-drupal/media/pictures/picture-13-1342204530.jpg differ
diff --git a/static/archive/legacy-drupal/media/pictures/picture-32-1344464691.jpg b/static/archive/legacy-drupal/media/pictures/picture-32-1344464691.jpg
new file mode 100644
index 0000000..bf9177f
Binary files /dev/null and b/static/archive/legacy-drupal/media/pictures/picture-32-1344464691.jpg differ
diff --git a/static/archive/legacy-drupal/media/pictures/picture-33-1344493553.jpg b/static/archive/legacy-drupal/media/pictures/picture-33-1344493553.jpg
new file mode 100644
index 0000000..b864b25
Binary files /dev/null and b/static/archive/legacy-drupal/media/pictures/picture-33-1344493553.jpg differ
diff --git a/static/archive/legacy-drupal/media/uploads/Images/3jZ04.png b/static/archive/legacy-drupal/media/uploads/Images/3jZ04.png
new file mode 100644
index 0000000..e8612e0
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/Images/3jZ04.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/ImagesImages/VdayFinal.jpg b/static/archive/legacy-drupal/media/uploads/ImagesImages/VdayFinal.jpg
new file mode 100644
index 0000000..44348bd
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/ImagesImages/VdayFinal.jpg differ
diff --git a/static/archive/legacy-drupal/media/uploads/SBPL/index.html b/static/archive/legacy-drupal/media/uploads/SBPL/index.html
new file mode 100644
index 0000000..09de51b
--- /dev/null
+++ b/static/archive/legacy-drupal/media/uploads/SBPL/index.html
@@ -0,0 +1,24 @@
+
+
+
+
+
SBPL software downloads
+
+
+
+SBPL software downloads
+The original sbpl.net site exposed this directory at
+/shared/SBPL/ as an Apache directory listing.
+The two release archives are preserved here verbatim:
+
+ - sbpl.tar.gz (611 KB)
+ - sbpl.zip (688 KB)
+
+Both archives are identical in content; the .tar.gz is
+gzip-compressed for Linux/macOS users, the .zip for Windows.
+
+
diff --git a/static/archive/legacy-drupal/media/uploads/SBPL/sbpl.tar.gz b/static/archive/legacy-drupal/media/uploads/SBPL/sbpl.tar.gz
new file mode 100644
index 0000000..9e1e081
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/SBPL/sbpl.tar.gz differ
diff --git a/static/archive/legacy-drupal/media/uploads/SBPL/sbpl.zip b/static/archive/legacy-drupal/media/uploads/SBPL/sbpl.zip
new file mode 100644
index 0000000..d25f80b
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/SBPL/sbpl.zip differ
diff --git a/static/archive/legacy-drupal/media/uploads/_thumbs/Images/3jZ04.png b/static/archive/legacy-drupal/media/uploads/_thumbs/Images/3jZ04.png
new file mode 100644
index 0000000..477f1da
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/_thumbs/Images/3jZ04.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/resize/site/all/images/segbot-284x231.png b/static/archive/legacy-drupal/media/uploads/resize/site/all/images/segbot-284x231.png
new file mode 100644
index 0000000..cd66219
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/resize/site/all/images/segbot-284x231.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/site/all/images/hexarotor.png b/static/archive/legacy-drupal/media/uploads/site/all/images/hexarotor.png
new file mode 100644
index 0000000..3e5a867
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/site/all/images/hexarotor.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/site/all/images/pr2_grasp.png b/static/archive/legacy-drupal/media/uploads/site/all/images/pr2_grasp.png
new file mode 100644
index 0000000..9d737af
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/site/all/images/pr2_grasp.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/site/all/images/rtfm.png b/static/archive/legacy-drupal/media/uploads/site/all/images/rtfm.png
new file mode 100644
index 0000000..a4ae484
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/site/all/images/rtfm.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/site/all/images/secretary_part_3.png b/static/archive/legacy-drupal/media/uploads/site/all/images/secretary_part_3.png
new file mode 100644
index 0000000..55fc91d
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/site/all/images/secretary_part_3.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/site/all/images/segbot.png b/static/archive/legacy-drupal/media/uploads/site/all/images/segbot.png
new file mode 100644
index 0000000..fa85ac3
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/site/all/images/segbot.png differ
diff --git a/static/archive/legacy-drupal/media/uploads/site/all/images/steal_this_comic.png b/static/archive/legacy-drupal/media/uploads/site/all/images/steal_this_comic.png
new file mode 100644
index 0000000..7f7b526
Binary files /dev/null and b/static/archive/legacy-drupal/media/uploads/site/all/images/steal_this_comic.png differ
diff --git a/static/archive/legacy-drupal/media/videos/README.md b/static/archive/legacy-drupal/media/videos/README.md
new file mode 100644
index 0000000..12106e1
--- /dev/null
+++ b/static/archive/legacy-drupal/media/videos/README.md
@@ -0,0 +1,70 @@
+# Legacy SBPL Video Assets — Awaiting LFS Push from a Maintainer
+
+The five video files from the original sbpl.net `media/videos/` folder
+**are not yet committed** to this repository, but the scaffolding is in
+place so a maintainer with write access to `sbpl/sbpl.github.io` can
+add them in a single push.
+
+| File | Size | sha256 (from the workstation extraction) |
+|----------------------------|---------|-------------------------------------------|
+| `manip1_collect.mp4` | ~241 MB | (compute on add) |
+| `sbpl_flight_march17.mp4` | ~207 MB | (compute on add) |
+| `icra2_HD.mp4` | ~122 MB | (compute on add) |
+| `beam_graphs.mp4` | ~9 MB | (compute on add) |
+| `crashes1.wmv` | ~6 MB | (compute on add) |
+
+## Why aren't they in the PR?
+
+The PR is opened from a **public fork** (`PegasusGTV/sbpl.github.io`).
+GitHub does not allow public forks to upload new LFS objects to their
+LFS namespace — they share LFS storage with the upstream parent, and
+upstream-write permission is required for new objects. The migration
+account does not currently have push permission on
+`sbpl/sbpl.github.io`, so the videos couldn't be uploaded directly.
+
+The `.gitattributes` file at the repo root already declares
+`static/archive/legacy-drupal/media/videos/*.{mp4,wmv,avi,mov}` as
+Git LFS-tracked, so dropping the files in and committing them will
+route them to LFS automatically — no further configuration is needed.
+
+## To add the videos
+
+On a machine with `git-lfs` installed and **push access to
+`sbpl/sbpl.github.io`** (i.e. a maintainer):
+
+```bash
+git lfs install # one-time per machine
+git clone git@github.com:sbpl/sbpl.github.io.git
+cd sbpl.github.io
+git checkout import-legacy-sbpl-net-content # after merging the PR, this is `main`
+
+# Copy the .mp4 / .wmv files in from wherever the workstation extraction lives:
+cp /path/to/newwebsite/media/videos/*.mp4 \
+ static/archive/legacy-drupal/media/videos/
+cp /path/to/newwebsite/media/videos/*.wmv \
+ static/archive/legacy-drupal/media/videos/
+
+# Remove this README and commit the videos as LFS:
+git rm static/archive/legacy-drupal/media/videos/README.md
+git add static/archive/legacy-drupal/media/videos/*.mp4 \
+ static/archive/legacy-drupal/media/videos/*.wmv
+git commit -m "feat(archive): add legacy sbpl.net video assets via Git LFS"
+git push
+```
+
+After the push, `git lfs ls-files` should list all five video files.
+
+## Want to keep them out of LFS entirely?
+
+If the maintainers prefer to avoid GitHub LFS bandwidth costs, two
+alternatives that keep the archive structure intact:
+
+1. **Mirror to Internet Archive / CMU Box** — upload the videos there
+ and replace this README with a list of permanent external URLs.
+2. **Move out of `static/`** — the `static/` directory ships with
+ every GitHub-Pages deploy; moving the videos to a sibling
+ non-static `archive/` folder keeps them in the repo for posterity
+ but stops them from being served at every deploy.
+
+See [`/LEGACY_LFS.md`](/LEGACY_LFS.md) at the repo root for the longer
+discussion of LFS quotas and bandwidth.
diff --git a/static/archive/legacy-drupal/reference/original_settings.php b/static/archive/legacy-drupal/reference/original_settings.php
new file mode 100644
index 0000000..7d32db5
--- /dev/null
+++ b/static/archive/legacy-drupal/reference/original_settings.php
@@ -0,0 +1,527 @@
+ 'mysql',
+ * 'database' => 'databasename',
+ * 'username' => 'username',
+ * 'password' => '***REDACTED***',
+ * 'host' => 'localhost',
+ * 'port' => 3306,
+ * 'prefix' => 'myprefix_',
+ * 'collation' => 'utf8_general_ci',
+ * );
+ * @endcode
+ *
+ * The "driver" property indicates what Drupal database driver the
+ * connection should use. This is usually the same as the name of the
+ * database type, such as mysql or sqlite, but not always. The other
+ * properties will vary depending on the driver. For SQLite, you must
+ * specify a database file name in a directory that is writable by the
+ * webserver. For most other drivers, you must specify a
+ * username, password, host, and database name.
+ *
+ * Some database engines support transactions. In order to enable
+ * transaction support for a given database, set the 'transactions' key
+ * to TRUE. To disable it, set it to FALSE. Note that the default value
+ * varies by driver. For MySQL, the default is FALSE since MyISAM tables
+ * do not support transactions.
+ *
+ * For each database, you may optionally specify multiple "target" databases.
+ * A target database allows Drupal to try to send certain queries to a
+ * different database if it can but fall back to the default connection if not.
+ * That is useful for master/slave replication, as Drupal may try to connect
+ * to a slave server when appropriate and if one is not available will simply
+ * fall back to the single master server.
+ *
+ * The general format for the $databases array is as follows:
+ * @code
+ * $databases['default']['default'] = $info_array;
+ * $databases['default']['slave'][] = $info_array;
+ * $databases['default']['slave'][] = $info_array;
+ * $databases['extra']['default'] = $info_array;
+ * @endcode
+ *
+ * In the above example, $info_array is an array of settings described above.
+ * The first line sets a "default" database that has one master database
+ * (the second level default). The second and third lines create an array
+ * of potential slave databases. Drupal will select one at random for a given
+ * request as needed. The fourth line creates a new database with a name of
+ * "extra".
+ *
+ * For a single database configuration, the following is sufficient:
+ * @code
+ * $databases['default']['default'] = array(
+ * 'driver' => 'mysql',
+ * 'database' => 'databasename',
+ * 'username' => 'username',
+ * 'password' => '***REDACTED***',
+ * 'host' => 'localhost',
+ * 'prefix' => 'main_',
+ * 'collation' => 'utf8_general_ci',
+ * );
+ * @endcode
+ *
+ * You can optionally set prefixes for some or all database table names
+ * by using the 'prefix' setting. If a prefix is specified, the table
+ * name will be prepended with its value. Be sure to use valid database
+ * characters only, usually alphanumeric and underscore. If no prefixes
+ * are desired, leave it as an empty string ''.
+ *
+ * To have all database names prefixed, set 'prefix' as a string:
+ * @code
+ * 'prefix' => 'main_',
+ * @endcode
+ * To provide prefixes for specific tables, set 'prefix' as an array.
+ * The array's keys are the table names and the values are the prefixes.
+ * The 'default' element is mandatory and holds the prefix for any tables
+ * not specified elsewhere in the array. Example:
+ * @code
+ * 'prefix' => array(
+ * 'default' => 'main_',
+ * 'users' => 'shared_',
+ * 'sessions' => 'shared_',
+ * 'role' => 'shared_',
+ * 'authmap' => 'shared_',
+ * ),
+ * @endcode
+ * You can also use a reference to a schema/database as a prefix. This maybe
+ * useful if your Drupal installation exists in a schema that is not the default
+ * or you want to access several databases from the same code base at the same
+ * time.
+ * Example:
+ * @code
+ * 'prefix' => array(
+ * 'default' => 'main.',
+ * 'users' => 'shared.',
+ * 'sessions' => 'shared.',
+ * 'role' => 'shared.',
+ * 'authmap' => 'shared.',
+ * );
+ * @endcode
+ * NOTE: MySQL and SQLite's definition of a schema is a database.
+ *
+ * Advanced users can add or override initial commands to execute when
+ * connecting to the database server, as well as PDO connection settings. For
+ * example, to enable MySQL SELECT queries to exceed the max_join_size system
+ * variable, and to reduce the database connection timeout to 5 seconds:
+ *
+ * @code
+ * $databases['default']['default'] = array(
+ * 'init_commands' => array(
+ * 'big_selects' => 'SET SQL_BIG_SELECTS=1',
+ * ),
+ * 'pdo' => array(
+ * PDO::ATTR_TIMEOUT => 5,
+ * ),
+ * );
+ * @endcode
+ *
+ * WARNING: These defaults are designed for database portability. Changing them
+ * may cause unexpected behavior, including potential data loss.
+ *
+ * @see DatabaseConnection_mysql::__construct
+ * @see DatabaseConnection_pgsql::__construct
+ * @see DatabaseConnection_sqlite::__construct
+ *
+ * Database configuration format:
+ * @code
+ * $databases['default']['default'] = array(
+ * 'driver' => 'mysql',
+ * 'database' => 'databasename',
+ * 'username' => 'username',
+ * 'password' => '***REDACTED***',
+ * 'host' => 'localhost',
+ * 'prefix' => '',
+ * );
+ * $databases['default']['default'] = array(
+ * 'driver' => 'pgsql',
+ * 'database' => 'databasename',
+ * 'username' => 'username',
+ * 'password' => '***REDACTED***',
+ * 'host' => 'localhost',
+ * 'prefix' => '',
+ * );
+ * $databases['default']['default'] = array(
+ * 'driver' => 'sqlite',
+ * 'database' => '/path/to/databasefilename',
+ * );
+ * @endcode
+ */
+$databases = array (
+ 'default' =>
+ array (
+ 'default' =>
+ array (
+ 'database' => 'drupal',
+ 'username' => 'drupaladmin',
+ 'password' => '***REDACTED***',
+ 'host' => 'localhost',
+ 'port' => '',
+ 'driver' => 'mysql',
+ 'prefix' => '',
+ ),
+ ),
+);
+
+/**
+ * Access control for update.php script.
+ *
+ * If you are updating your Drupal installation using the update.php script but
+ * are not logged in using either an account with the "Administer software
+ * updates" permission or the site maintenance account (the account that was
+ * created during installation), you will need to modify the access check
+ * statement below. Change the FALSE to a TRUE to disable the access check.
+ * After finishing the upgrade, be sure to open this file again and change the
+ * TRUE back to a FALSE!
+ */
+$update_free_access = FALSE;
+
+/**
+ * Salt for one-time login links and cancel links, form tokens, etc.
+ *
+ * This variable will be set to a random value by the installer. All one-time
+ * login links will be invalidated if the value is changed. Note that if your
+ * site is deployed on a cluster of web servers, you must ensure that this
+ * variable has the same value on each server. If this variable is empty, a hash
+ * of the serialized database credentials will be used as a fallback salt.
+ *
+ * For enhanced security, you may set this variable to a value using the
+ * contents of a file outside your docroot that is never saved together
+ * with any backups of your Drupal files and database.
+ *
+ * Example:
+ * $drupal_hash_salt = file_get_contents('/home/example/salt.txt');
+ *
+ */
+$drupal_hash_salt = 'TMtgt3povh-IfbCv_Ct0dKnI_1e-1pzkrfY7H03LXSQ';
+
+/**
+ * Base URL (optional).
+ *
+ * If Drupal is generating incorrect URLs on your site, which could
+ * be in HTML headers (links to CSS and JS files) or visible links on pages
+ * (such as in menus), uncomment the Base URL statement below (remove the
+ * leading hash sign) and fill in the absolute URL to your Drupal installation.
+ *
+ * You might also want to force users to use a given domain.
+ * See the .htaccess file for more information.
+ *
+ * Examples:
+ * $base_url = 'http://www.example.com';
+ * $base_url = 'http://www.example.com:8888';
+ * $base_url = 'http://www.example.com/drupal';
+ * $base_url = 'https://www.example.com:8888/drupal';
+ *
+ * It is not allowed to have a trailing slash; Drupal will add it
+ * for you.
+ */
+# $base_url = 'http://sbpl.net:21128'; // NO trailing slash!
+
+/**
+ * PHP settings:
+ *
+ * To see what PHP settings are possible, including whether they can be set at
+ * runtime (by using ini_set()), read the PHP documentation:
+ * http://www.php.net/manual/en/ini.list.php
+ * See drupal_initialize_variables() in includes/bootstrap.inc for required
+ * runtime settings and the .htaccess file for non-runtime settings. Settings
+ * defined there should not be duplicated here so as to avoid conflict issues.
+ */
+
+/**
+ * Some distributions of Linux (most notably Debian) ship their PHP
+ * installations with garbage collection (gc) disabled. Since Drupal depends on
+ * PHP's garbage collection for clearing sessions, ensure that garbage
+ * collection occurs by using the most common settings.
+ */
+ini_set('session.gc_probability', 1);
+ini_set('session.gc_divisor', 100);
+
+/**
+ * Set session lifetime (in seconds), i.e. the time from the user's last visit
+ * to the active session may be deleted by the session garbage collector. When
+ * a session is deleted, authenticated users are logged out, and the contents
+ * of the user's $_SESSION variable is discarded.
+ */
+ini_set('session.gc_maxlifetime', 200000);
+
+/**
+ * Set session cookie lifetime (in seconds), i.e. the time from the session is
+ * created to the cookie expires, i.e. when the browser is expected to discard
+ * the cookie. The value 0 means "until the browser is closed".
+ */
+ini_set('session.cookie_lifetime', 2000000);
+
+/**
+ * If you encounter a situation where users post a large amount of text, and
+ * the result is stripped out upon viewing but can still be edited, Drupal's
+ * output filter may not have sufficient memory to process it. If you
+ * experience this issue, you may wish to uncomment the following two lines
+ * and increase the limits of these variables. For more information, see
+ * http://php.net/manual/en/pcre.configuration.php.
+ */
+# ini_set('pcre.backtrack_limit', 200000);
+# ini_set('pcre.recursion_limit', 200000);
+
+/**
+ * Drupal automatically generates a unique session cookie name for each site
+ * based on its full domain name. If you have multiple domains pointing at the
+ * same Drupal site, you can either redirect them all to a single domain (see
+ * comment in .htaccess), or uncomment the line below and specify their shared
+ * base domain. Doing so assures that users remain logged in as they cross
+ * between your various domains. Make sure to always start the $cookie_domain
+ * with a leading dot, as per RFC 2109.
+ */
+#$cookie_domain = '.sbpl.net';
+$cookie_domain = 'localhost';
+
+/**
+ * Variable overrides:
+ *
+ * To override specific entries in the 'variable' table for this site,
+ * set them here. You usually don't need to use this feature. This is
+ * useful in a configuration file for a vhost or directory, rather than
+ * the default settings.php. Any configuration setting from the 'variable'
+ * table can be given a new value. Note that any values you provide in
+ * these variable overrides will not be modifiable from the Drupal
+ * administration interface.
+ *
+ * The following overrides are examples:
+ * - site_name: Defines the site's name.
+ * - theme_default: Defines the default theme for this site.
+ * - anonymous: Defines the human-readable name of anonymous users.
+ * Remove the leading hash signs to enable.
+ */
+# $conf['site_name'] = 'My Drupal site';
+# $conf['theme_default'] = 'garland';
+# $conf['anonymous'] = 'Visitor';
+
+/**
+ * A custom theme can be set for the offline page. This applies when the site
+ * is explicitly set to maintenance mode through the administration page or when
+ * the database is inactive due to an error. It can be set through the
+ * 'maintenance_theme' key. The template file should also be copied into the
+ * theme. It is located inside 'modules/system/maintenance-page.tpl.php'.
+ * Note: This setting does not apply to installation and update pages.
+ */
+# $conf['maintenance_theme'] = 'bartik';
+
+/**
+ * Reverse Proxy Configuration:
+ *
+ * Reverse proxy servers are often used to enhance the performance
+ * of heavily visited sites and may also provide other site caching,
+ * security, or encryption benefits. In an environment where Drupal
+ * is behind a reverse proxy, the real IP address of the client should
+ * be determined such that the correct client IP address is available
+ * to Drupal's logging, statistics, and access management systems. In
+ * the most simple scenario, the proxy server will add an
+ * X-Forwarded-For header to the request that contains the client IP
+ * address. However, HTTP headers are vulnerable to spoofing, where a
+ * malicious client could bypass restrictions by setting the
+ * X-Forwarded-For header directly. Therefore, Drupal's proxy
+ * configuration requires the IP addresses of all remote proxies to be
+ * specified in $conf['reverse_proxy_addresses'] to work correctly.
+ *
+ * Enable this setting to get Drupal to determine the client IP from
+ * the X-Forwarded-For header (or $conf['reverse_proxy_header'] if set).
+ * If you are unsure about this setting, do not have a reverse proxy,
+ * or Drupal operates in a shared hosting environment, this setting
+ * should remain commented out.
+ *
+ * In order for this setting to be used you must specify every possible
+ * reverse proxy IP address in $conf['reverse_proxy_addresses'].
+ * If a complete list of reverse proxies is not available in your
+ * environment (for example, if you use a CDN) you may set the
+ * $_SERVER['REMOTE_ADDR'] variable directly in settings.php.
+ * Be aware, however, that it is likely that this would allow IP
+ * address spoofing unless more advanced precautions are taken.
+ */
+# $conf['reverse_proxy'] = TRUE;
+
+/**
+ * Specify every reverse proxy IP address in your environment.
+ * This setting is required if $conf['reverse_proxy'] is TRUE.
+ */
+# $conf['reverse_proxy_addresses'] = array('a.b.c.d', ...);
+
+/**
+ * Set this value if your proxy server sends the client IP in a header
+ * other than X-Forwarded-For.
+ */
+# $conf['reverse_proxy_header'] = 'HTTP_X_CLUSTER_CLIENT_IP';
+
+/**
+ * Page caching:
+ *
+ * By default, Drupal sends a "Vary: Cookie" HTTP header for anonymous page
+ * views. This tells a HTTP proxy that it may return a page from its local
+ * cache without contacting the web server, if the user sends the same Cookie
+ * header as the user who originally requested the cached page. Without "Vary:
+ * Cookie", authenticated users would also be served the anonymous page from
+ * the cache. If the site has mostly anonymous users except a few known
+ * editors/administrators, the Vary header can be omitted. This allows for
+ * better caching in HTTP proxies (including reverse proxies), i.e. even if
+ * clients send different cookies, they still get content served from the cache.
+ * However, authenticated users should access the site directly (i.e. not use an
+ * HTTP proxy, and bypass the reverse proxy if one is used) in order to avoid
+ * getting cached pages from the proxy.
+ */
+# $conf['omit_vary_cookie'] = TRUE;
+
+/**
+ * CSS/JS aggregated file gzip compression:
+ *
+ * By default, when CSS or JS aggregation and clean URLs are enabled Drupal will
+ * store a gzip compressed (.gz) copy of the aggregated files. If this file is
+ * available then rewrite rules in the default .htaccess file will serve these
+ * files to browsers that accept gzip encoded content. This allows pages to load
+ * faster for these users and has minimal impact on server load. If you are
+ * using a webserver other than Apache httpd, or a caching reverse proxy that is
+ * configured to cache and compress these files itself you may want to uncomment
+ * one or both of the below lines, which will prevent gzip files being stored.
+ */
+# $conf['css_gzip_compression'] = FALSE;
+# $conf['js_gzip_compression'] = FALSE;
+
+/**
+ * String overrides:
+ *
+ * To override specific strings on your site with or without enabling locale
+ * module, add an entry to this list. This functionality allows you to change
+ * a small number of your site's default English language interface strings.
+ *
+ * Remove the leading hash signs to enable.
+ */
+# $conf['locale_custom_strings_en'][''] = array(
+# 'forum' => 'Discussion board',
+# '@count min' => '@count minutes',
+# );
+
+/**
+ *
+ * IP blocking:
+ *
+ * To bypass database queries for denied IP addresses, use this setting.
+ * Drupal queries the {blocked_ips} table by default on every page request
+ * for both authenticated and anonymous users. This allows the system to
+ * block IP addresses from within the administrative interface and before any
+ * modules are loaded. However on high traffic websites you may want to avoid
+ * this query, allowing you to bypass database access altogether for anonymous
+ * users under certain caching configurations.
+ *
+ * If using this setting, you will need to add back any IP addresses which
+ * you may have blocked via the administrative interface. Each element of this
+ * array represents a blocked IP address. Uncommenting the array and leaving it
+ * empty will have the effect of disabling IP blocking on your site.
+ *
+ * Remove the leading hash signs to enable.
+ */
+# $conf['blocked_ips'] = array(
+# 'a.b.c.d',
+# );
+
+/**
+ * Fast 404 pages:
+ *
+ * Drupal can generate fully themed 404 pages. However, some of these responses
+ * are for images or other resource files that are not displayed to the user.
+ * This can waste bandwidth, and also generate server load.
+ *
+ * The options below return a simple, fast 404 page for URLs matching a
+ * specific pattern:
+ * - 404_fast_paths_exclude: A regular expression to match paths to exclude,
+ * such as images generated by image styles, or dynamically-resized images.
+ * If you need to add more paths, you can add '|path' to the expression.
+ * - 404_fast_paths: A regular expression to match paths that should return a
+ * simple 404 page, rather than the fully themed 404 page. If you don't have
+ * any aliases ending in htm or html you can add '|s?html?' to the expression.
+ * - 404_fast_html: The html to return for simple 404 pages.
+ *
+ * Add leading hash signs if you would like to disable this functionality.
+ */
+$conf['404_fast_paths_exclude'] = '/\/(?:styles)\//';
+$conf['404_fast_paths'] = '/\.(?:txt|png|gif|jpe?g|css|js|ico|swf|flv|cgi|bat|pl|dll|exe|asp)$/i';
+$conf['404_fast_html'] = '404 Not Found Not Found
The requested URL "@path" was not found on this server.
';
+
+/**
+ * By default, fast 404s are returned as part of the normal page request
+ * process, which will properly serve valid pages that happen to match and will
+ * also log actual 404s to the Drupal log. Alternatively you can choose to
+ * return a 404 now by uncommenting the following line. This will reduce server
+ * load, but will cause even valid pages that happen to match the pattern to
+ * return 404s, rather than the actual page. It will also prevent the Drupal
+ * system log entry. Ensure you understand the effects of this before enabling.
+ *
+ * To enable this functionality, remove the leading hash sign below.
+ */
+# drupal_fast_404();
+
+/**
+ * Authorized file system operations:
+ *
+ * The Update manager module included with Drupal provides a mechanism for
+ * site administrators to securely install missing updates for the site
+ * directly through the web user interface by providing either SSH or FTP
+ * credentials. This allows the site to update the new files as the user who
+ * owns all the Drupal files, instead of as the user the webserver is running
+ * as. However, some sites might wish to disable this functionality, and only
+ * update the code directly via SSH or FTP themselves. This setting completely
+ * disables all functionality related to these authorized file operations.
+ *
+ * Remove the leading hash signs to disable.
+ */
+# $conf['allow_authorize_operations'] = FALSE;
diff --git a/static/archive/legacy-drupal/reference/website_installation_procedure.md b/static/archive/legacy-drupal/reference/website_installation_procedure.md
new file mode 100644
index 0000000..04d22de
--- /dev/null
+++ b/static/archive/legacy-drupal/reference/website_installation_procedure.md
@@ -0,0 +1,130 @@
+# Website Installation Procedure #
+
+The majority of these instructions can be found at www.drupal.org. However, this
+document may contain any qwerks encountered during the first installation of
+Drupal on this system.
+
+## Download system requirements ##
+
+* The Drupal CMS requires a webserver, a database, and PHP5.
+* Download and install Apache2, MySQL and PHP5 with database extensions:
+ * `sudo apt-get install apache2 mysql-server php5 php5-common php5-mysql php5-gd`
+
+## Download and extract Drupal ##
+
+* Download Drupal from the website:
+ * `wget http://ftp.drupal.org/files/projects/drupal-x.x.tar.gz` (currently 7.33 in place of x.x)
+ * `tar xzvf drupal-x.x.tar.gz`
+ * `sudo mv drupal-x.x /var/www`
+
+## Create the MySQL database ##
+
+* Login to MySQL as the root user.
+* Create the drupaladmin user and grant privileges:
+ * `mysql -u root -p`
+ * `CREATE USER 'drupaladmin'@'localhost' IDENTIFIED BY 'drupalpass'`;
+ * `GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES ON drupal.* TO 'drupaladmin'@'localhost';`
+* Login to MySQL as the drupaladmin and create the drupal database:
+ * `CREATE DATABASE drupal CHARACTER SET utf8 COLLATE utf8_general_ci`;
+
+## Create the settings.php file and files directory ##
+
+* Copy sites/default/default.settings.php file to sites/defualt/settings.php in the same directory:
+ * `cd /var/www/drupal-x.x`
+ * `cp sites/default/default.settings.php sites/default/settings.php`
+
+* Change permissions of the settings file during installation:
+ * `chmod 666 sites/default/settings.php`
+
+* Create the files directory and give the webuser permissions to write to it:
+ * `mkdir sites/default/files`
+ * `sudo chown www-data:www-data sites/default/files`
+
+## Run the installation script ##
+
+* Open up a browser and navigation to `hostname`/drupal-7.33 (Assuming a fresh Apache install)
+* Select Standard install as the installation profile.
+* Select English as the chosen language.
+* Enter the database name, username, and password for the database you created earlier.
+* Enter Search-Based Planning Lab as the Site name.
+* Enter sbpl@sbpl.net as the Site e-mail address.
+* Enter sbpl, sbpl@sbpl.net, and the standard password as the Site maintenance account
+* Enter the Default country and time zone.
+* Leave both boxes checked to check for updates automatically and receive e-mail notifications.
+
+## Reset permissions correctly after installation ##
+
+* Reset the permissions on settings.php:
+ * `chmod 644 sites/default/settings.php`
+
+## Set up cron ##
+
+* This should be set up automatically during installation.
+* Confirm that this was correctly set up by navigating to Adminstration > Configuration > System > Cron.
+
+## Configure website-specific Apache configuration ##
+
+* Create a Virtual Host configuration so that the website can be accessed at a different port number and document root:
+ * Edit /etc/apache2/ports.conf to listen on port 21128 and define a virtual host. Place the following sometime after the definitions for port 80:
+ * `NameVirtualHost *:21128`
+ * `Listen 21128`
+ * Create a configuration file for the Drupal website:
+ * `sudo touch /etc/apache2/sites-available/drupal`
+ * Edit /etc/apache2/sites-available/drupal and place the lines:
+
+```
+
+ ServerAdmin sbpl@sbpl.net
+ ServerName sbpl.net
+
+ DocumentRoot /var/www/drupal-x.x
+
+ AllowOverride None
+ Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
+ Order allow,deny
+ Allow from all
+
+
+ ErrorLog ${APACHE_LOG_DIR}/error.log
+
+ # Possible values include: debug, info, notice, warn, error, crit,
+ # alert, emergy.
+ LogLevel warn
+
+ CustomLog ${APACHE_LOG_DIR}/access.log combined
+
+ Alias /doc/ "/usr/share/doc/"
+
+ Options Indexes MultiViews FollowSymLinks
+ AllowOverride None
+ Order deny,allow
+ Deny from all
+ Allow from 127.0.0.0/255.0.0.0 ::1/128
+
+
+```
+
+ * Replace x.x with the version number of the website.
+ * Add the available site to the enabled site configurations:
+ * `sudo ln -s /etc/apache2/sites-avialable/drupal /etc/apache2/sites-enabled/drupal`
+ * Restart Apache2:
+ * `sudo service apache2 restart`
+
+## Configure clean URLs ##
+
+* Enable the Rewrite module for Apache and restart Apache:
+ * `a2enmod rewrite`
+ * `sudo service apache2 restart`
diff --git a/static/archive/legacy-drupal/requirements.txt b/static/archive/legacy-drupal/requirements.txt
new file mode 100644
index 0000000..4878c75
--- /dev/null
+++ b/static/archive/legacy-drupal/requirements.txt
@@ -0,0 +1,7 @@
+# The extractor uses only the Python 3 standard library.
+# No third-party packages are required.
+#
+# Optional (only if you want to re-run extraction with a fancier
+# HTML->Markdown converter):
+# html2text>=2024.2.26
+# markdownify>=0.11
diff --git a/static/archive/legacy-drupal/scripts/build_manifest.py b/static/archive/legacy-drupal/scripts/build_manifest.py
new file mode 100644
index 0000000..4ac7d73
--- /dev/null
+++ b/static/archive/legacy-drupal/scripts/build_manifest.py
@@ -0,0 +1,151 @@
+#!/usr/bin/env python3
+"""Walk newwebsite/ and write a manifest.md with every file + its size.
+
+Usage: python3 scripts/build_manifest.py
+"""
+
+from __future__ import annotations
+
+import datetime as _dt
+from pathlib import Path
+
+NEWSITE = Path(__file__).resolve().parent.parent
+MANIFEST = NEWSITE / "manifest.md"
+
+# Provenance map: where each top-level subtree came from on the source workspace.
+PROVENANCE = {
+ "content/pages": "extracted from data/raw/dump-2018-04-12.sql (`node` joined with `field_data_body`, `node_revision`, `url_alias`, `field_data_field_*`)",
+ "content/blocks": "extracted from `block_custom` table (sidebar/footer HTML)",
+ "content/blocks_index.json": "index of every entry under content/blocks/",
+ "content/menus.json": "extracted from `menu_links` table",
+ "content/users.json": "extracted from `users` + `users_roles` + `role` (passwords stripped, spam accounts filtered)",
+ "content/site_variables.json": "curated subset of `variable` (site_name, theme, etc.)",
+
+ "data/pages_index.csv": "generated by scripts/extract.py",
+ "data/url_aliases.json": "extracted from `url_alias` table (Drupal path aliases per node)",
+ "data/node_types.json": "extracted from `node_type` table",
+ "data/files_managed.json": "extracted from `file_managed` table",
+ "data/file_usage.json": "extracted from `file_usage` table",
+ "data/page_field_image.json": "extracted from `field_data_field_image`",
+ "data/page_field_page_file.json": "extracted from `field_data_field_page_file`",
+ "data/page_field_tags.json": "extracted from `field_data_field_tags`",
+ "data/taxonomy.json": "extracted from `taxonomy_vocabulary` + `taxonomy_term_data` + `taxonomy_term_hierarchy` + `taxonomy_index`",
+ "data/comments.json": "extracted from `comment` + `field_data_comment_body`",
+ "data/roles.json": "extracted from `role` + `role_permission`",
+ "data/contact_categories.json": "extracted from `contact` table",
+ "data/text_formats.json": "extracted from `filter_format` + `filter`",
+ "data/drupal_variables.json": "all `variable` rows, PHP-decoded",
+
+ "data/raw/dump-2018-04-12.sql": "verbatim copy of ../dump-2018-04-12.sql",
+ "data/raw/drupal_dump.sql": "verbatim copy of ../drupal_dump.sql",
+
+ "media/logos": "copied from drupal-7.33/sites/default/files/sbpl_logo2_*",
+ "media/images": "copied from drupal-7.33/shared/Images/ (with _thumbs/ from drupal-7.33/shared/_thumbs/Images/)",
+ "media/pictures": "copied from drupal-7.33/sites/default/files/pictures/",
+ "media/uploads": "copied from drupal-7.33/sites/default/files/{Images,ImagesImages,site,_thumbs,resize}/ + drupal-7.33/shared/SBPL/",
+ "media/uploads/SBPL": "drupal-7.33/shared/SBPL/{sbpl.tar.gz,sbpl.zip} + a small index.html",
+ "media/videos": "copied from Desktop/, Downloads/ and drupal-7.33/shared/Venkat/ICRA13/",
+
+ "reference/website_installation_procedure.md": "verbatim copy of ../website_installation_procedure.md",
+ "reference/original_settings.php": "copy of ../settings.php with passwords + drupal_hash_salt redacted",
+ "scripts": "in-tree extraction tooling",
+ "README.md": "human-readable overview of this folder",
+ "requirements.txt": "Python deps (stdlib-only)",
+}
+
+
+def fmt_size(n: int) -> str:
+ for unit in ("B", "KB", "MB", "GB"):
+ if n < 1024 or unit == "GB":
+ return f"{n:>8.1f} {unit}" if unit != "B" else f"{n:>8d} B "
+ n /= 1024
+ return f"{n} B"
+
+
+def looks_in(rel: str, prefix: str) -> bool:
+ return rel == prefix or rel.startswith(prefix + "/")
+
+
+def provenance_for(rel: str) -> str:
+ # Exact match wins
+ if rel in PROVENANCE:
+ return PROVENANCE[rel]
+ # Directory-prefix match
+ for prefix, note in PROVENANCE.items():
+ if "/" not in prefix and looks_in(rel, prefix):
+ return note
+ if looks_in(rel, prefix):
+ return note
+ return ""
+
+
+def walk_files():
+ for p in sorted(NEWSITE.rglob("*")):
+ if p.is_dir():
+ continue
+ if p == MANIFEST:
+ continue
+ rel = p.relative_to(NEWSITE).as_posix()
+ if rel.startswith("scripts/__pycache__"):
+ continue
+ yield rel, p.stat().st_size
+
+
+def main():
+ files = list(walk_files())
+ total = sum(sz for _, sz in files)
+
+ # Bucket by top-level dir for grouping in the manifest. Files at the
+ # repo root go into a synthetic "(top-level)" bucket.
+ TOP_LEVEL = "(top-level)"
+ by_dir: dict[str, list[tuple[str, int]]] = {}
+ for rel, sz in files:
+ if "/" in rel:
+ top = rel.split("/", 1)[0]
+ else:
+ top = TOP_LEVEL
+ by_dir.setdefault(top, []).append((rel, sz))
+
+ def label(top: str) -> str:
+ return top if top == TOP_LEVEL else f"{top}/"
+
+ lines: list[str] = []
+ lines.append("# newwebsite/ manifest")
+ lines.append("")
+ lines.append(f"_Generated: {_dt.datetime.now().isoformat(timespec='seconds')}_")
+ lines.append("")
+ lines.append(f"**Total: {len(files)} files, {total / (1024 * 1024):.1f} MB**")
+ lines.append("")
+ lines.append("Sizes for each top-level subtree:")
+ lines.append("")
+ lines.append("| Subtree | Files | Size |")
+ lines.append("|---------|------:|-----:|")
+ for top, entries in sorted(by_dir.items()):
+ sub_total = sum(sz for _, sz in entries)
+ size_str = (
+ f"{sub_total / (1024 * 1024):.2f} MB" if sub_total >= 1024 * 1024
+ else f"{sub_total / 1024:.1f} KB" if sub_total >= 1024
+ else f"{sub_total} B"
+ )
+ lines.append(f"| `{label(top)}` | {len(entries)} | {size_str} |")
+ lines.append("")
+
+ for top in sorted(by_dir):
+ lines.append(f"## `{label(top)}`")
+ lines.append("")
+ if top in PROVENANCE:
+ lines.append(f"_Source: {PROVENANCE[top]}_")
+ lines.append("")
+ lines.append("| Path | Size | Source |")
+ lines.append("|------|-----:|--------|")
+ for rel, sz in sorted(by_dir[top]):
+ note = provenance_for(rel)
+ lines.append(f"| `{rel}` | {fmt_size(sz)} | {note} |")
+ lines.append("")
+
+ MANIFEST.write_text("\n".join(lines) + "\n", encoding="utf-8")
+ print(f"Wrote {MANIFEST.relative_to(NEWSITE)} ({len(files)} files, {total/(1024*1024):.1f} MB)")
+
+
+if __name__ == "__main__":
+ main()
diff --git a/static/archive/legacy-drupal/scripts/extract.py b/static/archive/legacy-drupal/scripts/extract.py
new file mode 100644
index 0000000..e8675fc
--- /dev/null
+++ b/static/archive/legacy-drupal/scripts/extract.py
@@ -0,0 +1,1626 @@
+#!/usr/bin/env python3
+"""
+SBPL Drupal 7 dump extractor.
+
+Streams ../dump-2018-04-12.sql, decodes the relevant tables, and writes a
+clean, human-readable bundle under ../newwebsite/{content,data}/.
+
+Tables consumed:
+ Page content
+ node, field_data_body, node_revision, node_type
+ field_data_field_image, field_data_field_page_file, field_data_field_tags
+ Navigation
+ menu_links, menu_custom, url_alias
+ People + permissions
+ users, users_roles, role, role_permission
+ Files
+ file_managed, file_usage
+ Custom HTML blocks (sidebar / footer)
+ block_custom, block
+ Taxonomy / tags
+ taxonomy_vocabulary, taxonomy_term_data,
+ taxonomy_term_hierarchy, taxonomy_index
+ Comments
+ comment, field_data_comment_body
+ Contact form
+ contact
+ Filters / WYSIWYG text formats
+ filter_format, filter
+ Site config
+ variable
+
+Outputs (relative to repo root):
+ newwebsite/content/pages/-.{html,md,json}
+ newwebsite/content/menus.json
+ newwebsite/content/users.json
+ newwebsite/content/blocks/-.{html,md,json}
+ newwebsite/content/blocks_index.json
+ newwebsite/content/site_variables.json
+ newwebsite/data/pages_index.csv
+ newwebsite/data/files_managed.json
+ newwebsite/data/file_usage.json
+ newwebsite/data/url_aliases.json
+ newwebsite/data/node_types.json
+ newwebsite/data/taxonomy.json
+ newwebsite/data/comments.json
+ newwebsite/data/roles.json
+ newwebsite/data/contact_categories.json
+ newwebsite/data/text_formats.json
+ newwebsite/data/page_field_image.json
+ newwebsite/data/page_field_page_file.json
+ newwebsite/data/page_field_tags.json
+ newwebsite/data/drupal_variables.json
+
+Pure stdlib - no third-party deps.
+"""
+
+from __future__ import annotations
+
+import csv
+import html
+import json
+import os
+import re
+import sys
+from html.parser import HTMLParser
+from pathlib import Path
+
+# ---------------------------------------------------------------------------
+# Paths
+# ---------------------------------------------------------------------------
+
+SCRIPT_DIR = Path(__file__).resolve().parent
+NEWWEBSITE = SCRIPT_DIR.parent
+REPO_ROOT = NEWWEBSITE.parent
+SQL_DUMP = REPO_ROOT / "dump-2018-04-12.sql"
+
+PAGES_DIR = NEWWEBSITE / "content" / "pages"
+CONTENT_DIR = NEWWEBSITE / "content"
+DATA_DIR = NEWWEBSITE / "data"
+
+# ---------------------------------------------------------------------------
+# Schemas (column lists, in dump order)
+# ---------------------------------------------------------------------------
+
+NODE_COLUMNS = [
+ "nid", "vid", "type", "language", "title", "uid", "status",
+ "created", "changed", "comment", "promote", "sticky", "tnid",
+ "translate",
+]
+
+FIELD_DATA_BODY_COLUMNS = [
+ "entity_type", "bundle", "deleted", "entity_id", "revision_id",
+ "language", "delta", "body_value", "body_summary", "body_format",
+]
+
+NODE_REVISION_COLUMNS = [
+ "nid", "vid", "uid", "title", "log", "timestamp", "status",
+ "comment", "promote", "sticky",
+]
+
+MENU_LINKS_COLUMNS = [
+ "menu_name", "mlid", "plid", "link_path", "router_path", "link_title",
+ "options", "module", "hidden", "external", "has_children", "expanded",
+ "weight", "depth", "customized",
+ "p1", "p2", "p3", "p4", "p5", "p6", "p7", "p8", "p9",
+ "updated",
+]
+
+USERS_COLUMNS = [
+ "uid", "name", "pass", "mail", "theme", "signature", "signature_format",
+ "created", "access", "login", "status", "timezone", "language",
+ "picture", "init", "data",
+]
+
+FILE_MANAGED_COLUMNS = [
+ "fid", "uid", "filename", "uri", "filemime", "filesize", "status",
+ "timestamp",
+]
+
+VARIABLE_COLUMNS = ["name", "value"]
+
+# --- Additional content-bearing tables ----------------------------------------
+
+NODE_TYPE_COLUMNS = [
+ "type", "name", "base", "module", "description", "help", "has_title",
+ "title_label", "custom", "modified", "locked", "disabled", "orig_type",
+]
+
+URL_ALIAS_COLUMNS = ["pid", "source", "alias", "language"]
+
+BLOCK_CUSTOM_COLUMNS = ["bid", "body", "info", "format"]
+
+FIELD_DATA_FIELD_IMAGE_COLUMNS = [
+ "entity_type", "bundle", "deleted", "entity_id", "revision_id",
+ "language", "delta",
+ "field_image_fid", "field_image_alt", "field_image_title",
+ "field_image_width", "field_image_height",
+]
+
+FIELD_DATA_FIELD_PAGE_FILE_COLUMNS = [
+ "entity_type", "bundle", "deleted", "entity_id", "revision_id",
+ "language", "delta",
+ "field_page_file_fid", "field_page_file_display",
+ "field_page_file_description",
+]
+
+FIELD_DATA_FIELD_TAGS_COLUMNS = [
+ "entity_type", "bundle", "deleted", "entity_id", "revision_id",
+ "language", "delta", "field_tags_tid",
+]
+
+FILE_USAGE_COLUMNS = ["fid", "module", "type", "id", "count"]
+
+TAXONOMY_VOCABULARY_COLUMNS = [
+ "vid", "name", "machine_name", "description", "hierarchy",
+ "module", "weight",
+]
+
+TAXONOMY_TERM_DATA_COLUMNS = [
+ "tid", "vid", "name", "description", "format", "weight",
+]
+
+TAXONOMY_TERM_HIERARCHY_COLUMNS = ["tid", "parent"]
+
+TAXONOMY_INDEX_COLUMNS = ["nid", "tid", "sticky", "created"]
+
+COMMENT_COLUMNS = [
+ "cid", "pid", "nid", "uid", "subject", "hostname", "created", "changed",
+ "status", "thread", "name", "mail", "homepage", "language",
+]
+
+FIELD_DATA_COMMENT_BODY_COLUMNS = [
+ "entity_type", "bundle", "deleted", "entity_id", "revision_id",
+ "language", "delta", "comment_body_value", "comment_body_format",
+]
+
+ROLE_COLUMNS = ["rid", "name", "weight"]
+
+USERS_ROLES_COLUMNS = ["uid", "rid"]
+
+ROLE_PERMISSION_COLUMNS = ["rid", "permission", "module"]
+
+CONTACT_COLUMNS = ["cid", "category", "recipients", "reply", "weight", "selected"]
+
+FILTER_FORMAT_COLUMNS = ["format", "name", "cache", "status", "weight"]
+FILTER_COLUMNS = ["format", "module", "name", "weight", "status", "settings"]
+
+TABLES_OF_INTEREST = {
+ # Page content
+ "node": NODE_COLUMNS,
+ "field_data_body": FIELD_DATA_BODY_COLUMNS,
+ "node_revision": NODE_REVISION_COLUMNS,
+ "node_type": NODE_TYPE_COLUMNS,
+ "field_data_field_image": FIELD_DATA_FIELD_IMAGE_COLUMNS,
+ "field_data_field_page_file": FIELD_DATA_FIELD_PAGE_FILE_COLUMNS,
+ "field_data_field_tags": FIELD_DATA_FIELD_TAGS_COLUMNS,
+ # Navigation
+ "menu_links": MENU_LINKS_COLUMNS,
+ "url_alias": URL_ALIAS_COLUMNS,
+ # People + permissions
+ "users": USERS_COLUMNS,
+ "users_roles": USERS_ROLES_COLUMNS,
+ "role": ROLE_COLUMNS,
+ "role_permission": ROLE_PERMISSION_COLUMNS,
+ # Files
+ "file_managed": FILE_MANAGED_COLUMNS,
+ "file_usage": FILE_USAGE_COLUMNS,
+ # Custom HTML blocks (sidebar / footer)
+ "block_custom": BLOCK_CUSTOM_COLUMNS,
+ # Taxonomy / tags
+ "taxonomy_vocabulary": TAXONOMY_VOCABULARY_COLUMNS,
+ "taxonomy_term_data": TAXONOMY_TERM_DATA_COLUMNS,
+ "taxonomy_term_hierarchy": TAXONOMY_TERM_HIERARCHY_COLUMNS,
+ "taxonomy_index": TAXONOMY_INDEX_COLUMNS,
+ # Comments
+ "comment": COMMENT_COLUMNS,
+ "field_data_comment_body": FIELD_DATA_COMMENT_BODY_COLUMNS,
+ # Contact form
+ "contact": CONTACT_COLUMNS,
+ # Text formats / WYSIWYG
+ "filter_format": FILTER_FORMAT_COLUMNS,
+ "filter": FILTER_COLUMNS,
+ # Site config
+ "variable": VARIABLE_COLUMNS,
+}
+
+
+# ---------------------------------------------------------------------------
+# Streaming SQL value parser
+# ---------------------------------------------------------------------------
+
+# MySQL backslash-escape decoding (per the dump format mysqldump produces).
+_MYSQL_ESCAPES = {
+ "0": "\0",
+ "'": "'",
+ '"': '"',
+ "b": "\b",
+ "n": "\n",
+ "r": "\r",
+ "t": "\t",
+ "Z": "\x1a",
+ "\\": "\\",
+ "%": "\\%", # \% / \_ are LIKE-escapes; preserve verbatim
+ "_": "\\_",
+}
+
+
+def _decode_mysql_string(raw: str) -> str:
+ """Decode a MySQL-quoted string body (without the surrounding quotes)."""
+ out = []
+ i = 0
+ n = len(raw)
+ while i < n:
+ c = raw[i]
+ if c == "\\" and i + 1 < n:
+ nxt = raw[i + 1]
+ out.append(_MYSQL_ESCAPES.get(nxt, nxt))
+ i += 2
+ else:
+ out.append(c)
+ i += 1
+ return "".join(out)
+
+
+def parse_values(values_str: str):
+ """
+ Parse the `(...),(...),(...)` payload of a MySQL INSERT.
+ Yields one tuple (list of Python values) at a time.
+
+ Values can be:
+ - NULL -> None
+ - integers / decimals -> int or float
+ - 'string with \\\\ \\' escapes' -> str
+ - hex literals like 0xABCD -> bytes
+ """
+ n = len(values_str)
+ i = 0
+
+ while i < n:
+ # Skip whitespace, commas, and the leading '('.
+ while i < n and values_str[i] in " \t\r\n,":
+ i += 1
+ if i >= n:
+ break
+ if values_str[i] == ";":
+ break
+ if values_str[i] != "(":
+ raise ValueError(f"expected '(' at offset {i}, got {values_str[i]!r}")
+ i += 1 # consume '('
+
+ row = []
+ while True:
+ # skip leading whitespace
+ while i < n and values_str[i] in " \t\r\n":
+ i += 1
+ if i >= n:
+ raise ValueError("unexpected EOF inside row")
+
+ c = values_str[i]
+ if c == ")":
+ i += 1
+ break
+
+ if c == "'":
+ # quoted string
+ i += 1
+ start = i
+ buf = []
+ while i < n:
+ ch = values_str[i]
+ if ch == "\\" and i + 1 < n:
+ i += 2
+ continue
+ if ch == "'":
+ # could be end-of-string OR doubled '' (rare in mysqldump)
+ if i + 1 < n and values_str[i + 1] == "'":
+ i += 2
+ continue
+ break
+ i += 1
+ if i >= n:
+ raise ValueError("unterminated string literal")
+ raw = values_str[start:i]
+ i += 1 # consume closing quote
+ # handle SQL '' -> '
+ raw = raw.replace("''", "'")
+ row.append(_decode_mysql_string(raw))
+ else:
+ # unquoted token: NULL, number, hex, etc.
+ start = i
+ while i < n and values_str[i] not in ",)":
+ i += 1
+ token = values_str[start:i].strip()
+ if token.upper() == "NULL":
+ row.append(None)
+ elif token.startswith("0x") or token.startswith("0X"):
+ try:
+ row.append(bytes.fromhex(token[2:]))
+ except ValueError:
+ row.append(token)
+ else:
+ # number
+ try:
+ if "." in token or "e" in token or "E" in token:
+ row.append(float(token))
+ else:
+ row.append(int(token))
+ except ValueError:
+ row.append(token)
+
+ # after value: expect ',' or ')'
+ while i < n and values_str[i] in " \t\r\n":
+ i += 1
+ if i < n and values_str[i] == ",":
+ i += 1
+ elif i < n and values_str[i] == ")":
+ i += 1
+ break
+ else:
+ raise ValueError(f"unexpected char after value at {i}: {values_str[i:i+20]!r}")
+
+ yield row
+
+
+# ---------------------------------------------------------------------------
+# Stream the dump and collect rows for tables of interest
+# ---------------------------------------------------------------------------
+
+INSERT_RE = re.compile(r"^INSERT INTO `([^`]+)` VALUES\s+(.+);\s*$", re.DOTALL)
+
+
+def stream_inserts(sql_path: Path, wanted: set[str]):
+ """
+ Yield (table_name, row_dict) tuples for every INSERT into a wanted table.
+ Reads the file line-by-line; mysqldump puts each INSERT on its own line.
+ """
+ with sql_path.open("r", encoding="utf-8", errors="replace", newline="\n") as f:
+ # increase max line length is automatic for Python; defaults are fine
+ for line in f:
+ if not line.startswith("INSERT INTO `"):
+ continue
+ # Quick prefix filter to skip irrelevant inserts cheaply.
+ tick_close = line.find("`", len("INSERT INTO `"))
+ if tick_close < 0:
+ continue
+ table = line[len("INSERT INTO `"):tick_close]
+ if table not in wanted:
+ continue
+ m = INSERT_RE.match(line)
+ if not m:
+ continue
+ payload = m.group(2)
+ cols = TABLES_OF_INTEREST[table]
+ for row in parse_values(payload):
+ if len(row) != len(cols):
+ raise ValueError(
+ f"{table}: expected {len(cols)} cols, got {len(row)} -> {row[:3]}..."
+ )
+ yield table, dict(zip(cols, row))
+
+
+# ---------------------------------------------------------------------------
+# PHP serialize() decoder (for menu_links.options)
+# ---------------------------------------------------------------------------
+
+class PhpUnserializeError(Exception):
+ pass
+
+
+def php_unserialize(data):
+ """
+ Minimal php_unserialize() supporting: N, b, i, d, s, a.
+ `data` may be str or bytes; returns Python objects.
+ """
+ if isinstance(data, bytes):
+ data = data.decode("utf-8", errors="replace")
+
+ pos = [0]
+
+ def peek(n=1):
+ return data[pos[0]:pos[0] + n]
+
+ def consume(n):
+ pos[0] += n
+
+ def expect(ch):
+ if peek() != ch:
+ raise PhpUnserializeError(
+ f"expected {ch!r} at {pos[0]}, got {peek()!r} in {data[max(0, pos[0]-10):pos[0]+10]!r}"
+ )
+ consume(1)
+
+ def read_until(ch):
+ end = data.find(ch, pos[0])
+ if end < 0:
+ raise PhpUnserializeError(f"missing {ch!r}")
+ out = data[pos[0]:end]
+ pos[0] = end + 1
+ return out
+
+ def parse():
+ if pos[0] >= len(data):
+ raise PhpUnserializeError("unexpected EOF")
+ type_ch = data[pos[0]]
+ if type_ch == "N":
+ consume(1)
+ expect(";")
+ return None
+ if type_ch == "b":
+ consume(2) # 'b:'
+ v = read_until(";")
+ return v == "1"
+ if type_ch == "i":
+ consume(2)
+ v = read_until(";")
+ return int(v)
+ if type_ch == "d":
+ consume(2)
+ v = read_until(";")
+ return float(v)
+ if type_ch == "s":
+ consume(2)
+ length = int(read_until(":"))
+ expect('"')
+ # PHP serialize length is in bytes; our `data` is unicode, so
+ # use a byte-aware slice.
+ byts = data[pos[0]:].encode("utf-8", errors="replace")
+ chunk = byts[:length].decode("utf-8", errors="replace")
+ # advance pos by the codepoint length of `chunk`
+ pos[0] += len(chunk)
+ expect('"')
+ expect(";")
+ return chunk
+ if type_ch == "a":
+ consume(2)
+ length = int(read_until(":"))
+ expect("{")
+ out = {}
+ for _ in range(length):
+ k = parse()
+ v = parse()
+ out[k] = v
+ expect("}")
+ # PHP arrays may be lists if keys are 0..N-1
+ if all(isinstance(k, int) for k in out) and \
+ list(out.keys()) == list(range(length)):
+ return [out[k] for k in range(length)]
+ return out
+ raise PhpUnserializeError(f"unsupported type {type_ch!r} at {pos[0]}")
+
+ try:
+ return parse()
+ except PhpUnserializeError:
+ # Return the raw blob as a string so callers can still see it.
+ return {"__raw__": data}
+
+
+# ---------------------------------------------------------------------------
+# Slug + path helpers
+# ---------------------------------------------------------------------------
+
+_SLUG_RE = re.compile(r"[^a-z0-9]+")
+
+
+def slugify(title: str) -> str:
+ s = title.lower().strip()
+ s = _SLUG_RE.sub("-", s).strip("-")
+ return s or "untitled"
+
+
+# ---------------------------------------------------------------------------
+# Asset URL rewriting (HTML body -> local media paths)
+# ---------------------------------------------------------------------------
+
+# Pages live at content/pages/, media at media/. Relative path:
+REL_MEDIA = "../../media"
+
+_ASSET_REWRITES = [
+ # /shared/Images/foo.png -> ../../media/images/foo.png
+ (re.compile(r'(?P["\'])(?:https?://[^"\']*)?/shared/Images/'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/images/'),
+ # /shared/SBPL/... -> ../../media/uploads/SBPL/...
+ # (old site served this folder as an Apache directory listing of
+ # sbpl.tar.gz / sbpl.zip downloads)
+ (re.compile(r'(?P["\'])(?:https?://[^"\']*)?/shared/SBPL/'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/uploads/SBPL/'),
+ # /shared/Venkat/... -> ../../media/videos/... (only ICRA13/beam_graphs.mp4 lives there)
+ (re.compile(r'(?P["\'])(?:https?://[^"\']*)?/shared/Venkat/ICRA13/'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/videos/'),
+ # /sites/default/files/pictures/foo.jpg -> ../../media/pictures/foo.jpg
+ (re.compile(r'(?P["\'])(?:https?://[^"\']*)?/sites/default/files/pictures/'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/pictures/'),
+ # /sites/default/files/sbpl_logo... -> ../../media/logos/...
+ (re.compile(r'(?P["\'])(?:https?://[^"\']*)?/sites/default/files/(sbpl_logo[^"\']*)'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/logos/{m.group(2)}'),
+ # /sites/default/files/Images|ImagesImages|site/... -> ../../media/uploads/...
+ (re.compile(r'(?P["\'])(?:https?://[^"\']*)?/sites/default/files/(Images/|ImagesImages/|site/)'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/uploads/{m.group(2)}'),
+ # public://Images/... -> ../../media/uploads/Images/... (Drupal stream wrapper, rare)
+ (re.compile(r'(?P["\'])public://Images/'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/uploads/Images/'),
+ (re.compile(r'(?P["\'])public://pictures/'),
+ lambda m: f'{m.group("q")}{REL_MEDIA}/pictures/'),
+]
+
+
+def rewrite_assets(html_text: str) -> str:
+ out = html_text
+ for pat, fn in _ASSET_REWRITES:
+ out = pat.sub(fn, out)
+ return out
+
+
+# --- alias -> page-file rewriter --------------------------------------------
+#
+# The People page contains links like …. These
+# are Drupal URL aliases that resolved to /node/ on the live site.
+# We feed `url_alias` into a map { 'AndrewDornbush' -> 'node/15' } and rewrite
+# such bare hrefs to point at the corresponding ../-.html page
+# file in this bundle.
+
+def make_alias_rewriter(alias_to_nid: dict, nid_to_stem: dict):
+ """Return rewrite_alias_links(html_text) -> html_text."""
+ if not alias_to_nid:
+ return lambda html_text: html_text
+
+ # Build a single regex that matches href|src="" for any known alias.
+ # We only rewrite quoted bare relative refs (no protocol, no slash).
+ aliases = sorted(alias_to_nid, key=len, reverse=True)
+ # Escape and join. Allow URL-encoded spaces (%20) too.
+ parts = []
+ for a in aliases:
+ parts.append(re.escape(a).replace(r"\ ", r"(?:\ |%20)"))
+ big = "(?:" + "|".join(parts) + ")"
+ pat = re.compile(
+ r'(?P(?:href|src))=(?P["\'])(?:https?://sbpl\.net/?)?(?P'
+ + big + r')(?P[?#][^"\']*)?(?P=q)',
+ flags=re.IGNORECASE,
+ )
+
+ def repl(m: re.Match) -> str:
+ alias = m.group("alias")
+ # Decode %20 back to space for lookup
+ clean = alias.replace("%20", " ")
+ nid = alias_to_nid.get(clean) or alias_to_nid.get(alias)
+ if nid is None:
+ return m.group(0)
+ stem = nid_to_stem.get(nid)
+ if stem is None:
+ return m.group(0)
+ frag = m.group("frag") or ""
+ return f'{m.group("attr")}={m.group("q")}{stem}.html{frag}{m.group("q")}'
+
+ def rewrite(html_text: str) -> str:
+ if not html_text:
+ return html_text
+ return pat.sub(repl, html_text)
+
+ return rewrite
+
+
+# ---------------------------------------------------------------------------
+# Minimal HTML -> Markdown converter (stdlib-only)
+# ---------------------------------------------------------------------------
+
+class _Html2Md(HTMLParser):
+ """
+ Tiny converter good enough for the WYSIWYG HTML in this dump
+ (CKEditor output: p, h1-h6, a, img, ul/ol/li, strong/em, br, hr,
+ blockquote, code/pre, table is rendered as raw HTML as fallback).
+ """
+
+ BLOCK_TAGS = {
+ "p", "div", "h1", "h2", "h3", "h4", "h5", "h6",
+ "ul", "ol", "li", "blockquote", "pre", "hr", "table", "tr", "tbody",
+ "thead", "tfoot",
+ }
+
+ def __init__(self):
+ super().__init__(convert_charrefs=True)
+ self.parts: list[str] = []
+ self.list_stack: list[tuple[str, int]] = [] # (type, counter)
+ self.in_pre = 0
+ self.link_href: list[str] = []
+ self._suppress_text = 0 # script/style depth
+ self._raw_html_depth = 0 # inside