Friday, April 24, 2009

Google code actually becomes useful! Supports a DVCS! MERCURIAL!

Google Code Blog: Mercurial support for Project Hosting on Google Code
We are happy to announce that Project Hosting on Google Code now supports the Mercurial version control system in addition to Subversion. This is being initially rolled out as a preview release to a few invited users on a per-project basis, so that we can iron out the kinks before making this available to the general public.


While there were several DVCSs that we could support, our decision to support Mercurial was based on two key reasons. The primary reason was to support our large base of existing Subversion users that want to use a distributed version control system. For these users we felt that Mercurial had the lowest barrier to adoption because of its similar command set, great documentation (including a great online book), and excellent tools such as Tortoise Hg. Second, given that Google Code's infrastructure is built for HTTP-based services, we found that Mercurial had the best protocol and performance characteristics for HTTP support. For more information, see our analysis.

Thursday, April 23, 2009

Warning: Quanser flexible joint uses different angle convention than motor

Quanser Academic makes a line of products, which you can see demo'd at their YouTube channel, that are sold to university laboratories as teaching aids for control theory. Today I noticed a funny undocumented quirk about one of those products. I have notified Quanser of this, and there is some indication that they will update their documentation to reflect this quirk. However, because their documentation is not on-line, it's hard to see how that update will ever reach people who have already bought these products.

I TA a graduate control lab, and today's lab had the students design and implement an LQR controller that made use of a full-state observer to control Quanser's flexible joint. The motor angle is measured by a shaft encoder (which is the output we use to drive our observer), and the arm angle is measured by another encoder. We don't need the measured arm angle because we're using a full-state observer, but we still capture it for comparison to our estimated arm angle.

The students build a controller that stabilizes the plant to a moving equilibrium that tracks a square wave. At every transition, the observer trajectories had some peaky transients, as is expected, but it appeared like they were always in the wrong direction for the arm angle and its speed. I dismissed this as peaking, but one group wanted to investigate further, and so I had them track a sine wave instead. What did we find? The arm angle and speed estimates were always EXACTLY 180 degrees out of phase with the measurements.

I was shocked, and so I looked into it. Visually, I could tell that the FLEXIBLE JOINT's ANGLE ENCODER is mounted UPSIDE DOWN with respect to the motor's angle encoder. That means that rotating the motor to the "right" produces a positive angle even though rotating the JOINT to the right produces a NEGATIVE angle! The observer had it right; it was the MEASUREMENTS that were incorrect! (I built a minimal example to test my hypothesis, and what I say matched what I observed; the opposing rotations lead to equal signs)

Nowhere is this documented. Because this angle is not directly driven (it's coupled to the assembly via springs) and the arm+spring system is naturally stable and fast, this POSITIVE FEEDBACK doesn't lead to destabilize the system unless you have extremely high gain. So I'm guessing no one ever noticed. Multiplying the measurement by -1 restored intuition. I drilled down into some Quanser demo code, and I found that they do the same thing in their controllers. I have no idea why they would not document this in their rotary joint docs. Do they expect everyone to go through all of their MATLAB and Simulink code?

I could understand this error if the flexible joint was a generic component made by a different company, but the joint is solely for the purpose of connecting to the motor, and so it would make sense that its encoder orientation would match the motor encoder orientation! At the moment, we need different gains for both.

Friday, April 10, 2009

Copying lyrics from Pandora to your clipboard

You may have noticed that Pandora gives you (everyone? just subscribers?) the ability to view the lyrics of songs. For example, when I view "Not Going Anywhere" by Keren Ann, it gives me the full lyrics for the song (note: not every song has its lyrics in the Pandora database).

Pandora has been clever about how they display the lyrics. They actually don't come down with the page. The page uses AJAX to download the lyrics after you download the page. It then populates the correct place on the page with the lyrics. It also changes the mouseover properties so that you cannot use your browser to highlight those lyrics. Because the lyrics are populated dynamically, saving the page doesn't work either.

Well, I thought that was lousy. If the lyrics are displayed in plaintext on my browser, I should be able to at least highlight them. If they really wanted to prevent me from doing that, they'd build a GIF/JPG/PNG on their end and send me the lyrics in that, right?

So I figured out that I could use Firebug, the Firefox add-on, to do what Pandora didn't want me to do.
  1. Start Firebug.
  2. Start the "Console."
  3. Use the pull-down menu on the "Console" tab to "enable" the Console.
  4. Issue the JavaScript command
    alert(fullLyrics.innerHTML)
    on the console.
  5. A dialog box should pop up with the lyrics. Use your mouse to copy them to your clipboard.
  6. You can then disable the Firebug console using that same pull-down menu.
That worked for me. It should work until they change the names within the JavaScript.