Archive of February 2009


Thu 26 Feb

Roomba iCreate Unresponsive with Player/Stage

I am working on a research project that uses an iCreate, the hacker's version of the Roomba. It's a nice litle platform, particularly when you extend its functionality with Player/Stage. We have a laptop mounted on top of the robot, which gives us a lot of flexibility with what we can do with it. However, until recently, we'd been seeing some very erratic behavior from the robot.

Scenario: iCreate plus Command Module running Player/Stage 2.1.2, connected via USB-to-serial cable from a laptop to the robot's serial port. Player runs fine and properly accepts clients (such as playerjoy). However, the robot seemingly randomly will stop responding to input from client programs, apparently getting "stuck" on the last command you gave it.

Solution: The problem is actually the command module. For some reason, even when the command module is turned off, the robot exhibits this strange behavior. Removing the Command Module resolved the problem for us.

· Tags: , ,

Mon 23 Feb

Dell PowerEdge T300 SAS RAID and FreeBSD

I spent a couple hours tonight tackling this problem so I thought I'd post a solution here in case anyone else runs into it.

Scenario: Performed a clean install of FreeBSD7.1-RELEASE on a Dell PowerEdge T300 server with a SAS RAID controller, which completed without errors. After rebooting and beginning to install packages, I started seeing the following error: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x00 Depth 120.

Solution: Searching online indicated that the problem was with support for Tagged Command Queuing in the mpt driver. The output of camcontrol was:

skipper# camcontrol tags da0 -v (pass0:mpt0:0:0:0): dev_openings  255 (pass0:mpt0:0:0:0): dev_active    0 (pass0:mpt0:0:0:0): devq_openings 255 (pass0:mpt0:0:0:0): devq_queued   0 (pass0:mpt0:0:0:0): held          0 (pass0:mpt0:0:0:0): mintags       2 (pass0:mpt0:0:0:0): maxtags       255

I then entered:

skipper# camcontrol tags da0 -N 119 (pass0:mpt0:0:0:0): dev_openings  119 (pass0:mpt0:0:0:0): dev_active    0 (pass0:mpt0:0:0:0): devq_openings 119 (pass0:mpt0:0:0:0): devq_queued   0 (pass0:mpt0:0:0:0): held          0 (pass0:mpt0:0:0:0): mintags       2 (pass0:mpt0:0:0:0): maxtags       255

This second command limited the size of the queue to 119, preventing the error I had seen before. To ensure that this problem wouldn't come up in the future, I added the following line to /etc/rc.local

# Set the devq_openings to 119 to prevent problems with SAS controller camcontrol tags da0 -N 119

Doing this runs the command at every boot, preventing the problem from creeping up in the future.

Additional Related Resources: http://www.zulustips.com/2007/09/06/mpt0-queue-full-event-on-dell-sas-5ir.html http://www.nabble.com/mpt-errors-QUEUE-FULL-EVENT,-freebsd-7.0-on-dell-1950-td20019090.html

· Tags: ,

Mon 16 Feb

Somebody set up us the bomb!

UNC got a bomb threat called in tonight. As of now, nothing has come of it and everyone I know is safe. But, I just wanted to record here a couple interesting tidbits that have come as a result of it. The first is a snippet from the WXYC show "Sports Rap" that was going on when the evacuation took place (WXYC is located in the UNC Student Union, which is adjacent to the pit).

[In the background] What's up? You serious? Wow... Ok. [On air] Ok, well we are, um, taking a hiatus... there is some questionable going ons in the building so... I don't really know how to say this, I don't really [laughs], um, yeah... We're going to go offline here for a minute, everything is ok, uh, but we're going to throw on some music guys. Uh, I assure you this, we're not skipping out to go watch the end of the game, although it does work to our advantage. So we'll check out the end of the game and hopefully we can come back up and check out the tail end here...

After one song their broadcast went silent -- according to my friend who also DJs at the station, that's the first time they've ever been off the air.

A lot of students got to wondering why the university didn't send out an alert message over the much-hyped AlertCarolina system when the threat was first reported. In fact, the news spread like wildfire over Facebook, and within half an hour the DTH had a story up on their website about it. I'm a member of the Student Technology Advisory Board at UNC, which works with ITS, who manages (but does not decide whether to activate!) the AlertCarolina system. We had an interesting discussion via our email list about why no alert was issued; a couple members of our group diligently contacted ITS and the Department of Public Safety about the matter. All in all I feel like DPS managed the situation well, and [EDIT: Seems like during the evacuation people were just told to get away from the Pit area by police with weapons... in the words of one commenter on the DTH article: "yeah, a text or email would really freak us out. much more than the cop with the rifle."] I am confident that students were in danger for very little if any time. However, communication was sorely lacking. Here's a point I made:

I think the most significant lesson from all of this is that news of an emergency will spread like wildfire regardless of the response from the authorities. The job of DPS and others in charge of managing situations like this should be to put a statement out quickly so they can control the message that gets spread around before the rumor/hype mill gets going.

I think within ten minutes of the evacuation I had started seeing the beginning of the storm of Facebook status updates warning of the bomb threat and subsequent evacuation. If you are responsible for managing emergencies like this, you must be aware of this dynamic and be transparent and forthright with the public to prevent panic and hype.

· Tags: , , , ,