Jekyll2023-01-17T22:33:13+00:00http://goodrobot.ai/feed.xmlSiddhartha SrinivasaProfessor at University of Washington, full-stack roboticist.Siddhartha SrinivasaThe Academic Research Flywheel2020-01-07T00:00:00+00:002020-01-07T00:00:00+00:00http://goodrobot.ai/academic%20advice/academic-research-flywheel<p>This post originally appeared on <a href="https://www.linkedin.com/pulse/academic-research-flywheel-siddhartha-srinivasa/">LinkedIn</a>.</p>
<p>Most of us suffer from a problem of infinite ambition and finite resources. A common mistake we make is to take the resource gunpowder we have, and make hundreds of small bullets and shoot. Some bullets miss, and some others hit. Instead, what if we only shot a fraction of our bullets, identified the holes we made, and shot a giant cannonball with the remaining gunpowder to obliterate the target?
<!--more--></p>
<figure style="width: 75%; max-width: 400px;" class="align-center">
<img src="http://goodrobot.ai/assets/images/academic-research-flywheel.jpeg" alt="Teaching HERB to shoot hoops for a class project" />
<figcaption style="text-align: center; font-size:0.7em;">All three phases of the flywheel are critical for success</figcaption>
</figure>
<p>All three phases are important. If you do not shoot enough bullets, you will not make enough holes. If you do not spend the time identifying the holes, you will not orient your cannonball correctly. And, if you do not take the often laborious effort of building the cannonball, you will not obliterate your target.</p>
<p>At my lab, we have specific names for these three phases.</p>
<p>The <strong>demo</strong> is something we put together quickly and scrappily. It’s our small bullet. We often try to make it fun. For example, we put together a bartender demo with our robot HERB to pickup and handover soda cans to people. Some things worked and many things did not.</p>
<p>A common mistake is to assume that the failures are relevant and jump to building a giant cannonball to address them. Often, demo failures are due to mistakes and errors rather than genuine problems. How does one identify the real problem?</p>
<p>The <strong>infrastructure</strong> is a hardening of the demo that systematically works through all of the mistakes and fixes them to the best of our abilities. We are careful not to introduce any new ideas in this step, and focus exclusively on fixing mistakes. At the end of this phase, we have usually reduced our failures to genuine problems with our ideas. For example, even after our best efforts at calibrating our system and tuning our perception algorithm, HERB was clumsily failing to pick up 1 out of 20 soda cans. Now we have identified the real hole.</p>
<p>The <strong>research</strong> is the new idea we are forced to invent because of a clearly identified pain point with our current set of ideas. When I do research it is not because I have a cool idea, but it is because I am in agony over the failure of my existing ideas. For example, we realized that our existing paradigm of moving to a pre-grasp pose and closing our fingers was very sensitive to even small errors in the relative pose between the hand and the soda can. A mere 5mm would result in the soda can slipping away from the grasp. So, we invented the push-grasp, an open-loop policy of pushing forward while grasping that guaranteed, via quasi-static physics, that the soda can would always curl into the hand as the fingers closed. More importantly, push-grasping changed the way the community looked at grasping, from a static problem to a dynamic and complex interaction between the hand and the object that, surprisingly, could be modeled via simple physics.</p>
<p>So, where is the flywheel? The nice and frustrating thing about robotics is that every target you obliterate merely reveals the next target. Grasping works now, well how about feeding people marshmallows? On we go to the next demo, building up our quiver of arrows.</p>
<p>Skipping phases leads to come common research failures. Here’s a few of them:</p>
<ul>
<li><strong>The YouTube Star:</strong> who loves shooting small bullets and declaring success, never really obliterating the target, but decreasing everyone else’s funding gunpowder claiming the problem is solved.</li>
<li><strong>The Magician:</strong> who loves building their favorite cannonballs and shooting them at make-believe targets that only their cannonballs can reach. Sometimes they are even charismatic enough to blindly convince others of the existence of these targets.</li>
<li><strong>The Etsy:</strong> who is so in love with the artisanal process of building the perfect hand-crafted cannonball that they don’t really care if it only obliterates a tiny target, but beautifully. I am grudgingly in love with the Etsy, but can never bring myself to wasting so much time.
So, go build your own academic research flywheel! I am, as always, happy to help however I can.</li>
</ul>Siddhartha SrinivasaThis post originally appeared on LinkedIn. Most of us suffer from a problem of infinite ambition and finite resources. A common mistake we make is to take the resource gunpowder we have, and make hundreds of small bullets and shoot. Some bullets miss, and some others hit. Instead, what if we only shot a fraction of our bullets, identified the holes we made, and shot a giant cannonball with the remaining gunpowder to obliterate the target?Writing Good Reviews2018-08-27T00:00:00+00:002018-08-27T00:00:00+00:00http://goodrobot.ai/academic%20advice/writing-good-reviews<p>Reviewing papers is one of the most important roles of an academic. But yet, we provide surprisingly little guidance to our reviewers on the <em>tone</em> of their reviews. I tried to capture some of my thoughts in this email I sent to my reviewers when I ran RSS 2017.
<!--more--></p>
<p>Dear X,</p>
<p>Thank you, again, for serving as a reviewer for RSS 2017!</p>
<p>Reviewers are the life-blood of a conference. Your high quality reviews are critical not only for the authors but also for me and for the continued success of RSS. I know you have a lot of experience reviewing, so I will keep this very short and specific.</p>
<p>I’d like your reviews to be compassionate, constructive, and scholarly.</p>
<ul>
<li><strong>Compassionate</strong>: invert your position and ask yourself how you’d feel if you received your review. If it makes your blood boil, take a break, and revise your review.</li>
<li><strong>Constructive</strong>: I’d like us to believe that every paper has a best paper award winner hidden in it. Your role is to guide the author to reveal it.</li>
<li><strong>Scholarly</strong>: cite your sources, do not make claims like <em>“I do not feel this is true”</em> [your feelings matter to me, but probably not to science]. Do not hawk your viewpoint. And please, absolutely no ad hominem attacks.</li>
</ul>
<p>As a reviewer, your role is to comment on the paper’s quality to help the program committee reach an informed decision. So, please refrain from saying things like <em>“This paper should be rejected from RSS”</em> in the main body of the review. You’re welcome to add it to the private comments to the committee.</p>
<p>Finally, I am sure that if you try hard [or sometimes not that hard] to investigate the true identity of your authors, you would likely be able to do it [with high probability]. But, please do not use that as grounds for rejection. Instead of saying <em>“I think that the author of this paper is Joe Biden, and this looks a lot like Joe’s 2015 paper”</em>, just say <em>“Here are the ways this paper is similar to Joe Biden’s 2015 paper”</em>. In a similar vein, do not punish authors for not citing non peer reviewed content [like arXiv or workshop papers].</p>
<p>Your Area Chairs and I will be monitoring your reviews and providing you some feedback as this unfolds.</p>
<p>Happy reviewing!</p>
<p>Please contact me if you have any questions.</p>
<p>Thank you, again!</p>
<p>Sidd.</p>
<h2 id="conflicts-of-interest">Conflicts of Interest</h2>
<p>In addition to the usual conflict rules, I’d recommend another simple rule: if you feel like you cannot comment on the paper in an unbiased manner, decline to review it. I often find people <em>vested</em> in a research topic to be the worst reviewers, digging in stubbornly to their viewpoint and refusing to give other ideas a fair listen. The more knowledgable you are, the more <em>enlightened</em> you ought to be about other viewpoints.</p>
<h2 id="rapoports-rules-of-criticism-as-stated-by-dennet">Rapoport’s Rules of Criticism as stated by Dennet</h2>
<p>Finally, I’d like to leave you with perhaps the most <a href="https://rationalwiki.org/wiki/Rapoport%27s_Rules">succinct summary</a> on how to compose a critical commentary:</p>
<ul>
<li>
<p>You should attempt to re-express your target’s position so clearly, vividly, and fairly that your target says, “<em>Thanks, I wish I’d thought of putting it that way.</em>”</p>
</li>
<li>
<p>You should list any points of agreement (especially if they are not matters of general or widespread agreement).</p>
</li>
<li>
<p>You should mention anything you have learned from your target.</p>
</li>
<li>
<p>Only then are you permitted to say so much as a word of rebuttal or criticism.</p>
</li>
</ul>Siddhartha SrinivasaReviewing papers is one of the most important roles of an academic. But yet, we provide surprisingly little guidance to our reviewers on the tone of their reviews. I tried to capture some of my thoughts in this email I sent to my reviewers when I ran RSS 2017.A Tangled Web, Slightly Untangled2018-08-26T00:00:00+00:002022-09-26T14:00:00+00:00http://goodrobot.ai/miscellaneous%20tricks/an-untangled-web<p>I finally updated my website to the 21st century, and decided to go full Computer Scientist on it.
I was looking for something that was full-featured (<a href="https://daringfireball.net/projects/markdown/">markdown</a>, <a href="https://www.mathjax.org/">math</a>),
methodical to update (<a href="https://git-scm.com/">git</a>), and customizable (<a href="https://www.w3schools.com/">layout</a>, <a href="https://fonts.google.com/">fonts</a>).
<!--more--></p>
<p>Having rewritten the <a href="http://rss2017.lids.mit.edu/">RSS 2017</a> website from scratch (later enhanced by the incomparable <a href="http://brianhou.com/">Brian Hou</a>), I developed a fondness for <a href="https://jekyllrb.com/">Jekyll</a> as my base engine. Infinitely flexible, Jekyll empowered us to generate the <em>entire</em> <a href="http://rss2017.lids.mit.edu/program/detailed/">proceedings</a> by piping data from <a href="https://cmt3.research.microsoft.com/">CMT</a> seamlessly.</p>
<p>I’m a big fan of <a href="https://www.edwardtufte.com/">Edward Tufte’s</a> work, especially his advice to <em><a href="https://en.wikipedia.org/wiki/Edward_Tufte">maximize data-ink</a></em>, so the <a href="https://en.wikipedia.org/wiki/Edward_Tufte">Tufte Jekyll theme</a> was a natural layout choice.</p>
<p>I hosted the site source code in a private GitHub repo. Now there were several ways to push the <em>built</em> site out to the world. I considered writing a <em><a href="(https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)">git post-receive hook</a></em> to pipe the site content to the UW CSE web server (works quite well for our <a href="https://personalrobotics.cs.washington.edu/">lab website</a>), but finally decided on something much simpler: <a href="https://help.github.com/articles/adding-a-remote/">point</a> my public <a href="https://pages.github.com/">GitHub pages</a> repository to the built site (remember to add an empty <code class="language-plaintext highlighter-rouge">.nojekyll</code> file).</p>
<p>Then, I setup a <em><a href="https://en.wikipedia.org/wiki/HTTP_301">301 redirect</a></em> from my UW CSE site to my GitHub pages public site. Now I had a stable and working pipeline. Finally, I decided to <a href="https://goodrobot.ai/">buy a domain</a> on <a href="https://www.namecheap.com/">NameCheap</a>, and secured it via SSL certificates from <a href="https://www.cloudflare.com/ssl/">CloudFlare</a>.</p>
<h2 id="update">Update</h2>
<p>After using the website for a few years, I got increasingly frustrated with the friction of having to <code class="language-plaintext highlighter-rouge">jekyll build</code> the site locally every time I updated content. A challenge with the Tufte Jekyll theme is that it uses custom <code class="language-plaintext highlighter-rouge">plugins</code> that are incompatible with the new <code class="language-plaintext highlighter-rouge">jekyll-remote-theme</code> <a href="https://github.com/benbalter/jekyll-remote-theme">plugin</a> that enables Github sites to be autobuilt upon custom actions like <code class="language-plaintext highlighter-rouge">push</code>. Now, there are other <a href="https://jekyllrb.com/docs/continuous-integration/github-actions/">Github Actions</a> available but I worried about their brittleness. So I decided to simplify and pick a theme that could be installed as a remote theme. I’ve loved <a href="https://mmistakes.github.io/minimal-mistakes/">Minimal Mistakes</a> ever since!</p>Siddhartha SrinivasaI finally updated my website to the 21st century, and decided to go full Computer Scientist on it. I was looking for something that was full-featured (markdown, math), methodical to update (git), and customizable (layout, fonts).