Category Archives: Code

Chicago GTUG Presentation: Building Robots with the Sparkfun IOIO

Last night I presented at the Chicago GTUG. It was held at 1871 in Merchandise Mart, and wow is that a great space! It was a real pleasure to talk there.

Here’s a link to the presentation:

Links to references from the presentation:

iohannes: a robot based off the Sparkfun IOIO

I will post something more thorough next week, but I wanted to get some pictures and a video up for the robot I’ve been working on.

The robot was inspired by the Sparkfun IOIO: a great little board that allows you to merge the world of Android phones with the world of hobby electronics. The result? A relatively cheap robotics platform with a huge range of possibilities.

Code is here:

Here’s the breakdown:

Lynxmotion Tri-Track chassis with two 12V DC motors — $220.95 (I actually got this used for $175)
Robokits RKI-1004 Dual Motor Driver (up to 5A) — $16 (thanks, Robot City Workshop!)
12.0V 2200mAh NiMh battery pack — $24

SparkFun IOIO — $49.95
HC-SR04 Ultrasonic distance sensor — $13.95
HTC Evo — “free”
9.6V 1800mA NiMh battery pack — $18

Total cost: $342.85

Currently the robot has two modes: a manual control mode and an autonomous, obstacle-avoidance mode. In manual mode you simply tell the motors to go forward, backwards, left or right. In obstacle-avoidance mode the robot will move forward until an obstacle is detected, at which point it will execute an “evasive maneuver” to clear the obstacle, and continue as before.

Code is here:

Next steps: get rosjava installed and integrated with the application. This will allow for remote control of the robot, plus remote computation like image processing of camera data.

Miscellaneous XCode Troubleshooting

The worker for service class “(null)” cannot be instantiated.

When trying to upload an app to an ipad yesterday, I got the following message when trying to deploy:

The worker for service class “(null)” cannot be instantiated.

I’m running in XCode4, with Debugger options set to “None”.

By setting Debugger options to “GDB”, I was able to deploy to the device. I have no idea why this was happening.

Attempt to install on device fails due to restrictions

When attempting to install my app on an ipad, I was only able to run the app remotely. In other words, it wasn’t actually installing the app on the device, there was no “desktop” icon, and when I “stopped” the build, the app was killed on the ipad as well.

After wasting a bunch of time on this, I eventually realized that there were restrictions set up on the device so I couldn’t actually install my app (the debugger setting was a red herring, apparently). I removed those restrictions in the Settings menu:

General > Restrictions > Installing Apps > ON

and then I was able to install my app via XCode without any issues.

Hudson Perforce Plugin error: no output for command

Last night, we restarted one of our Hudson nodes and started getting the following error when trying to run a Perforce build:
Started by user vaustje
Building remotely on node4
Using remote perforce client: SOME_CLIENT
Caught exception communicating with perforce. No output for: p4 workspace -o SOME_CLIENT
com.tek42.perforce.PerforceException: No output for: p4 workspace -o SOME_CLIENT
at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(
at com.tek42.perforce.parse.Workspaces.getWorkspace(
at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(
at hudson.plugins.perforce.PerforceSCM.checkout(
at hudson.model.AbstractProject.checkout(
at hudson.model.AbstractBuild$AbstractRunner.checkout(
at hudson.model.AbstractBuild$
at hudson.model.ResourceController.execute(
Finished: FAILURE
While we first suspected that there was an error running the p4 command on the remote machine, it turned out that p4 was not getting executed at all. What happened was, before restarting the node we had changed the .bashrc file and accidentally removed the location of our p4 executable from the path. Then, when the node was restarted the Hudson executor could no longer find the executable and thus failed with a very unintuitive message. (For some reason, specifying the explicit path to the executable via “Path to p4 executable” in the job config had no effect–see this JIRA issue) After fixing the PATH variable on the machine and restarting, our issue was resolved.
In general, you can check the value of the PATH variable, and other variables, on the Hudson nodes by going to Hudson » nodes » nodename and clicking on Log.

405 Error when deploying to Maven Repository

If you’re getting a 405 error when trying to deploy a file to your Maven repository, it’s because the URL (as in -Durl= you have specified is somehow incorrect.

For example, I was trying to deploy a file using the mvn deploy:deploy-file target to a Nexus repository, and I got the following error:

$ mvn deploy:deploy-file -DgroupId=com.austje.test -DartifactId=project -Dversion=1.0 -Dpackaging=jar -Dfile=project.jar -Durl= -DrepositoryId=MyReleases
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [deploy:deploy-file] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [deploy:deploy-file {execution: default-cli}]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file: Return code is: 405
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Jan 25 11:15:25 CST 2010
[INFO] Final Memory: 5M/9M
[INFO] ------------------------------------------------------------------------
Looking at the line Uploading:, it’s pretty obvious that my url is wrong–that’s not where the artifact should be uploaded at all. Turns out I gave the repository server, but not the actual repository url! Changing my url parameter to reflect this

$ mvn deploy:deploy-file -DgroupId=com.austje.test -DartifactId=project -Dversion=1.0 -Dpackaging=jar -Durl= -DrepositoryId=MyReleases
fixed the issue, and I was able to deploy successfully.
Of course, this is not the only way you could screw up the url parameter. Among many possibilities, one tricky one I’ve seen is using http instead of https as the protocol.
Extra tip: If you fix the URL and are now getting return code 401, your credentials are incorrect. Try fixing them in your settings.xml file. You can test the credentials by going to the Nexus GUI and logging in. If those work, and you’re still not able to deploy via the command line, make sure the <id> in your <server> section of your settings.xml matches the <id> in the corresponding <repository> element.