Looking for MediaAmp, Course Links, or Files in Canvas's "Enhanced" Rich Content Editor (RCE)?

Recently, my university has changed things so that faculty using Canvas LMS will now encounter the “Enhanced Rich Content Editor (RCE)” by default whenever they edit an assignment, announcement, etc. Strangely, this change was made in the middle of the semester, not giving faculty who were unfamiliar with the "Enhanced" RCE a chance to find everything they frequently used in the classical editor. So here's a list of tips (with screenshots) to help you get used to the new editor.

• ASU uses MediaAmp to host videos for streaming to students. If you’re looking for MediaAmp (to embed videos) in the new RCE, you have to click on the little “Plug-in” icon (looks like a plug) and possibly search for it under “View All.” 
  
  
• If you’re looking for course links (Pages, Assignments, etc.), you have to click on the “Link” Icon (looks like chain links) and then select “Course Links."
  

  
  
• If you’re looking for your Files, you have to click on the “Link” icon, then select “Course Links”, then in the pop-up “Add” window that comes up on the right, change “Course Links” to “Files."
  

  

  
  
  
• Alternatively, some of you might not see the wisdom of changing editors in the middle of a semester like this one. For those of you, you can go to “Settings” and “Feature Options” and then toggle “RCE Enhancements” OFF to get the old editor back (at least for a little while).
  

  

I hope that's helpful! I wish I could say that the Enhanced RCE is an improvement, but I think you can see how it adds so many extra steps to find things that used to be up front and ready to use in the old editor. Even though it looks a little nicer, it's a net downgrade from the old editor.  And it is still impossible to drag images into the editor to insert them or simply paste them in place. You get no functional benefits out of the editor, and you get a lot of extra drag.

Happy editing, faculty!

Your iPad/iPhone/iPod not showing up on wireless sync on iTunes in Windows XP?

UPDATE: This solution appears to work for Windows 7 as well. As the problem is likely in the Apple software, the solution should work across Windows operating systems.

Last year for my mom's birthday, we bought her an iPad 2. When iOS 5 came out, she took advantage of the cool wireless sync feature to iTunes running on her Windows XP machine. It worked great for a few months, but then suddenly her iPad stopped showing up in the sync list unless it was physically plugged into her computer. On the iPad, it said it couldn't see her computer.

After tweaking some settings and doing a few reboots, I managed to get her computer to start wireless sync'ing again. I had an idea about what it was, but I wasn't sure.

Then, after a few weeks, I hear from her that it has started again. So I did a little more searching, and after combining multiple people's error reports and extracting the common thing that seemed to fix them all, I think I came up with the fix. It's a simple fix, and she's able to do it herself whenever the iPad loses connectivity. For the last few weeks, every time the iPad stops talking to her computer, she's able to recover immediately. So I think we've figured it out.

The fix? Restart the Apple Mobile Device service. Here's how:

1. Quit iTunes.
2. Right-click on "My Computer" and go to "Manage".
   • Alternatively (e.g., on Windows 7), open up your "Control Panel". Then click to see "All Items." Then look for "Administrative Tools." You should find "Services" in there. That's the ultimate destination we're heading to.
   • Alternatively, click on "Start" and then "Run" and type "services.msc" (without the quotes) and hit enter.
3. Click on "Services and Applications" inside the "Computer Management" console.
4. Double-click on the "Services" that shows up.
5. Find the "Apple Mobile Device" service in the list and select it by clicking on it.
6. Click the link that says "Restart the service".
   • Alternatively, you can right-click on the service and select "Restart."
   • Alternatively, you can double-click on the service and then click the "Stop" button and then the "Start" button.
7. Close the management console.

Now that you've restarted the "Apple Mobile Device", your system should start working like normal again (you may want to start up iTunes again though). Eventually when your iOS device starts looking again, it will find your system and sync as needed.

This problem appears to be caused by some sort of race condition dealing with the Apple Mobile Device and the network. As the computer starts, the order in which things start is non-deterministic. Due to some random delays, the network may not come up quick enough. Consequently, the Apple Mobile Device gets confused by the network being in this state. Re-starting it manually later when the network is definitely up and running seems to fix this problem every time.

Installing docutils for Mercurial (rst2man and rst2html)

If you're building Mercurial from its source, you might notice that the latest versions are using reStructuredText to markup their documentation. Hence, you'll need to install docutils. Additionally:

• You'll have to install the rst2man tool that is presently only available in the docutils "Sandbox," which you have to download separately.
• You'll have to make sure you have the new rst2man.py tool accessible in your PATH as rst2man.
• You'll have to make sure you have the included rst2html.py tool accessible in your PATH as rst2html.

So it's no surprise that yet-another-Python-related-adventure is yet-another-Python-related-headache. Here's how to get up and running. Things should get substantially simpler if and when docutils starts including rst2man as part of their standard distribution (however, you'll probably still have to make the simlinks unless Mercurial's installer is able to call the rst scripts with their .py extension). Meanwhile, here are some steps that will hopefully get you (the UNIX or Mac/OS X user) moving in the right direction.

• First, go to the docutils website and download the docutils snapshot as well as the docutils sandbox snapshot.
• tar zxf those tarballs to extract the docutils source code. That should give docutils and sandbox directories.
• Copy sandbox/manpage-writer/tools/rst2man.py to somewhere in your PATH (e.g., /usr/local/bin/rst2man.py or ~/bin/rst2man.py if you have ~/bin in your PATH).
• Create a symbolic link in your PATH from the rst2man.py you just placed there to rst2man. For example, symlink /usr/local/bin/rst2man.py to /usr/local/bin/rst2man by doing ln -s rst2man.py rst2man in the /usr/local/bin directory.
• Copy sandbox/manpage-writer/docutils/writers/manpage.py to docutils/docutils/writers/manpage.py.
• In the docutils directory, run python setup.py install (for a global installation) or python setup.py install --home ~ (for a home installation).
• Copy docutils/rst2html.py to somewhere in your PATH (e.g., /usr/local/bin/rst2html.py or ~/bin/rst2html.py).
• Create a symbolic link in your PATH from the rst2html.py you just placed there to rst2html. For example, ln -s rst2html.py rst2html inside your /usr/local/bin or ~/bin directory.
• Fetch the latest version of Mercurial and build it. Assuming you have all of the other dependencies, it should build OK.

Of course, YMMV, but I hope that at least helps get you on your way.

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.

Thanks, Microsoft, for SP3. I was getting tired of being happy.

UPDATE (THE FIX!!!): I decided to search Google again, and I found that several days after my support request, a new Microsoft support article (KB951830) was posted that describes the SAME problem as the old one (KB951446). However, in the new one, a HOTFIX is given. Strangely enough, that hotfix is NOT being distributed via Windows Update, and so you'll have to manually download and install it. I have informed the Microsoft support engineers (I've racked up two of them by now) about all of this.

NOTE: It might be important to note that before applying this patch, on the advice of the Microsoft support staff, I removed all registry keys that started with "$%&'()*+." (without the quotes). Evidently these keys are created by the SP3 install, but McAfee (which I was unable to disable due to network policy) wouldn't allow it. There were HUNDREDS of these keys (in each HKLM\SYSTEM\ControlSet*) and I had to delete them in SAFE MODE (to disable McAfee).

I also was asked to remove the keys (wordwrapped here):

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_CCPROXY
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_LIVEUPDATE_NOTICE_EX
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_LIVEUPDATE_NOTICE_SERVICE
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_LIVEUPDATE_NOTICE

None of those keys existed on my system.

UPDATE: After weeks of back and forth between me and Microsoft support, I'm finally in touch with an "Escalation Engineer" who is trying to get to the bottom of the problem.

Every morning, I'm still manually restarting my SharedAccess service after reconnecting my laptop. Otherwise, the Windows firewall blocks my access to the DNS running on the gateway. However, every other service gets through fine. That is, if I hard-coded my laptop's DNS, I think everything would be fine.

IF this problem is not a universal bug in SP3, it's something that was caused by installing SP3 with McAfee turned on (I can't turn it off due to network policy).

The Escalation Engineer seems to think that the problem might be fixed by installing a third party unsupported VBS script from some random blog by some Microsoft "MVP", but as far as I can tell, that fix prevents rebooting when SP3 is installed on some AMD systems. My system is an Intel Xeon system, and so I don't think it will make a difference. In fact, if I run it, it tells me that I don't need to run it because I'm on an Intel system. That's a good thing, because otherwise I'd have to uninstall SP3 and then run it. I would have been PISSED if the Escalation Engineer told me to uninstall SP3 and run the script just to find out that I had an Intel machine and the fix had NOTHING TO DO WITH IT.

Hopefully a hotfix is coming soon...

What a stupid fucking bug (KB951446) posted on May 6 with no indication that it will ever be fixed.

So, if you have a single computer (e.g., a laptop) connected to your ICS machine via a crossover cable, every time you disconnect that single computer, your ICS is going to die. The next time you reconnect, you have to restart the ICS service MANUALLY.

Remember that scene in High Fidelity where Rob explains to Barry that he just wants noise on in the background that he can ignore? That's the way I feel about Windows. I don't use it. I don't need it. I don't want it. I just have to have it for a few tedious things, and so I'd like it to sit back and do its thing without getting in my way. Right when I start forgetting that it's there, Microsoft goes ahead and does something to remind me it's still around. It's like some disease that just won't go away.

I've also heard a rumor that XP3's ICS restricts you to sharing your connection with no more than 10 other computers. That's pretty dumb too.