Ellipse Stencils

Just picked up my first laser cut acrylic design! nothing too exciting – just a set of ellipse stencils [for much cheaper than you would find at an art store] made using ponoko/vectorealism. Even though this was dreadfully simple, it gave me a fresh reminder of that special feeling you only get by bringing a design into the physical. Its an addictive feeling.

In case you want a set of these stencils for yourself, you can purchase the finished set on Ponoko, or just download the design file for free here (it is creative commons licensed after all)

PS yeah i know , its been waay too long between updates.. remind me and i’ll come up with an excuse for that later

 

Battery Roundup part 2: now in 3D!

 

 
As a continuation of my quest to overanalyze the purchase of a big lithium battery pack, i decided I’d write something up to give me a better feel for the actual physical size of the pack. Though i’ve started to learn Rhino 3d v4, I decided do this with sketchup/ruby because 1) the scripting capabilities seem more powerful 2) im already fairly comfortable with sketchup as a CAD program. Rhino 3d v5 supposedly has a Python API, but afaik there is no trial for v5… This is my first Sketchup plugin, so comments are more than welcome. You can download it from:
 
http://www.hardwarewasteland.net/shared/draw_batt_1.0.zip
 

The script constructs a rough 3d model for all the batteries described in the Google Spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0AtZJWDjB-E4xdDVETlFTOFNwUGswcjVFYkU4Wk85NUE#gid=0 (stored locally)

The purpose of this is to give people researching EV parts another tool to compare the approximate sizes of battery packs.

To use simply extract the contents of this folder to your Sketchup Plugins directory (generally something like C:\Program Files\Google\Google SketchUp 8\Plugins) and restart Sketchup. Click Plugins>Draw Batteries and the webdialog should appear.

Santa BarBot 2012!

 
~12 days ago i read this:
 

http://robogames.net/barbot.php

 
A San Francisco Cocktail party where the drinks are mixed by robots?!? There were 10 days remaining before the event, just enough time to build one, i thought…
Late that night I sent out a frantic email to the ever so special cross section of my drinking and geeking buddies, asking who wanted to partake in the build. At t-184hours the dreamteam had been assembled; we held our first meeting and [mostly] converged on a design:
 



 
Mechanical:



 

Friday parts were purchased, and Sat/Sun we took over another good friend’s [well equipped] garage for the build party.
Most of us also have regular (or semi regular) jobs to balance with this, so in the following week we had quite a few very late nights of coding, fabricating, mounting, testing and drinking! (had to test all the recipes of course)
 
At t-6hours we had it pretty much all together though there was still some coding to be done on the ride up to SF, and some of us were still recovering from rigorous testing the night before. We didn’t get to Parisoma until around 7, and did not have our robot entirely setup until after 8 when the venue had already become good and crowded. On the ride up a few pieces became bent/broken and had to be fudged back into place. Runs ended up making a royal mess and nailed our first customers with a dose of lime juice to the crotch.. counter to our engineering intuition, the ‘danger’ factor associated with our robot helped to make it all the more a crowd pleaser.
 

 
Overall the event was one hell of a good time, and I’d do it again in a heartbeat. There were 14 robotenders in service and enough of a turnout to piss off a firemarshall. We got a bit of a kickback to help cover transportation, but the majority of the proceeds go to student involvement in robotics and the robogames’ main events. We were also encouraged to sign up for Roboexotica, an event that is supposedly bigger, badder, and Austrian. I will certainly be looking into this

 

Shown above are the core team members (minus 1) and our Santa Barbot. I’ve gotta say, I really regard myself as fortunate to have such a slick bunch of engineers as friends. I think the fact that in ~1 week we went from idea to f****** awesome robot that takes a voice command (Siri) to make a Pan Galactic Gargle Blaster, speaks for itself. Cheers friends, I think we’d have done Douglas Adams proud.

 

 

 

 

 

  

 

Also seen on the Make Blog!

Battery Roundup

As I am now back in SoCal I’ve been doing a lot of thinking about how I’m going to eventually upgrade my motorcycle. What it needs most desperately is a lithium battery pack, charger, and BMS. First step is to get up to speed on whats available; this is what I came up with in my first bout of research. Also , because i have a fetish for visualization, i whipped up a quick sketch to create a series of “DDR Difficulty” graphs based on the 5 most relevant of these metrics: Specific Energy, Energy Density, Cost per Watt Hour, Continuous and Peak Discharge rates.
 

 
You can download the source here. To use it you will need Processing. Download the spreadhseet (linked above) as a CSV, make sure it is named battData.csv and is located in the data folder. There is a “Compare in vis” column in which you select 6 batteries to compare. If you want [to be awesome and] contribute to the list of batteries request edit priviledges on the google doc and i’ll approve you.
 
I could still improve the visual, as there are two things are potentially misleading.
1) every manafacturer seems to want to rate their batterie’s Ah capacity at different discharge rate. ie one 60Ah battery may fall to 40Ah when discharged at 1c, while another may only fall to 55. As 1c is closer to reality in an EV application. I’m considering editing the table to use approximated 1c capacities, as opposed to the advertised number. Such guestimations i think would still be more accurate than strictly following the advertised numbers.
2) As the batteries are directly contrasted with one another a value may seem low, while in reality it is quite adequate. For example Headway cells seem to have a rather low constant current and pulse discharge rate, however 5c/10c is plenty for most applications. At 5c the entire pack is drained in 12 minutes! this only seems low because there are also much higher discharge rate discharge batteries available.

Conclusion: Turnigy Lipos pretty much clean up. I’ve also heard good things about Hyperion, though I have yet to find a supplier; so they are not in the spreadsheet. Very impressed with whats available now, compared to when i first did the conversion in ’09. I just need to figure out how to keep those RC batteries well balanced and make sure they don’t explode. you know, the details xD

EV Talk

Had a good time last night at the Tokyo Hackerspace giving a short  talk on Electric Vehicle  tech and how to convert a motorcycle. Slides can be downloaded here,

 

 more about my conversion in the original post

–Z

ROS & Robovero

 

Working in the UCSB Robotics Lab  I’ve had the fortune of getting to play with one of those adorable little chewable linux computers , during the ~week before my move to Japan. While unfortunately I wont get to see it though to its installation as the nervous system on a hoping robot,  I’ve had the adventure of getting it all up and running with the ROS (Robot Operating System)  toolchain. I pulled a bit of hair out during the process, so hopefully this post will prevent others from having to do so.

 

 

 

As of now, this blog describes the process of getting Gumstix to boot Ubuntu Natty from an SD card , autoconnect to wifi, and subscribe to a  ROS topic.
I’m using a Gumstix Overo Fire COM, 8GB SD card, and the new Robovero daughter board.

You don’t need that exact hardware, but at minimum:

• -Gumstix Overo Air/Fire/FE

• -Micro SD card (8 GB in these examples)

• -Overo daughter board (could be pretty much any one)

• -Computer running Ubuntu

• -A wireless (or wired if you have the right Gumstix daughter board) network that both the Overo and Host computer can connect to

 

Creating the Bootable Ubutnu SD Card

First grab a copy of rootstock – a nifty tool we will use to create our armel ubuntu image:

# apt-get install rootstock

cd to someplace where you dont mind making a mess:

# mkdir gumbuntu
# cd gumbuntu

Now to generate the image:

~/gumbuntu# rootstock --fqdn overo --login robot --password temppasswd --imagesize 8G --seed wget,vim,linux-firmware,wireless-tools,wpasupplicant,usbutils,build-essential,tmux,openssh-server,lynx,python-yaml,cmake,subversion,wget,python-setuptools,pkg-config,python-dev,ntp,libboost-dev,libboost-all-dev,libapr1,libapr1-dev,libaprutil1,libaprutil1-dev,liblog4cxx10,liblog4cxx10-dev --dist natty --serial ttyS2

You may want to edit this somewhat. For more info on rootstock see https://wiki.ubuntu.com/ARM/RootfsFromScratch

This is bound to take a while. So in the meantime crack open a new terminal session and get your sd card formatted and bootable by following the directions here. STOP after copying MLO u-boot.bin and uImage to the boot partition, because we will be using our own rootfs image. You can download MLO u-boot.bin and uImage from here.

Once rootstock has completed unzip everything to the SD card’s root partition (lets call it sdroot)

~/gumbuntu# cd /media/sdroot
/media/sdroot# tar xvaf ~/gumbuntu/armel-rootfs-[creation date].tgz

This will also take a while. Make yourself useful by getting your Overo ready for the next step. The Ubuntu image we are building unfortunately does not have built in support for the Overo’s wifi chip, so we are going to swipe the modules and firmware from the nand image (which we know works). You could probably also find this stuff on the interweb , but this way is a pretty simple one stop shop for everything. If your kernel versions do not match you may be better off extracting the stuff from one of the Gumstix images to avoid compadibility issues.

 

 

Copying Modules and WiFi Firmware

Plug the daughter board into your desktop as you would normally to get to the serial console, give the boards power and let the Overo boot into the NAND Angstrom distro. We will be connecting to a wifi network to transfer files, becasue afaik there is no reliable way to do this over the serial connection. From the console (in a session thats not extracting files):

$ screen /dev/ttyUSB1 115200
[you will see the overo booting into Angstrom]
login: root
# ifconfig wlan0 up
# iwconfig wlan0 essid [your SSID]
# dhclient wlan0
# /etc/init.d/sshd restart

If you use encription you are going to have to set up wpa_supplicant.conf , but I’ll trust you know how to do this. The sshd restart probably isnt strictly necessary, but can’t hurt. Also don’t forget your Gumstix’s IP address; lets pretend its 192.168.1.14

Once the files have finished extracting from the SD card you will want to do the following (from a fresh terminal ) :

# cd /media/sdroot/lib
/media/sdroot/lib# scp -r root@192.168.1.14:/lib/modules/* modules/
/media/sdroot/lib# scp root@192.168.1.14:/lib/firmware/sd8686* firmware/
/media/sdroot/lib# cd ..
/media/sdroot# scp -r root@192.168.1.14:/etc/network/* etc/network/
/media/sdroot/lib# cd
# umount -a

Your bootable Ubuntu MicroSD card is now all ready! plug it into the Overo and give it a go

 

 

Installing ROS

Log into your Gumstix Ubuntu distro with the username/pass you used in the rootstock command, connect to your router and install ros by running:

# ifconfig wlan0 up
# iwconfig wlan0 essid [your SSID]
# dhclient wlan0
# apt-get update #not really needed yet, but verifies that you are connected
# easy_install -U rosinstall
# rosinstall ~/ros "http://packages.ros.org/cgi-bin/gen_rosinstall.py?rosdistro=diamondback&variant=ros-base&overlay=no"

 

go get that cup of coffee.

 

now I’ll assume you can get your router to statically assign IPs , if not you will have to change things every time your router does.  Edit /etc/hosts to include the name of your desktop computer (which will be running roscore) lets pretend your desktop has IP address 192.168.1.4, and you want to name it desky

#echo "192.168.1.4 desky" >> /etc/hosts

#echo "source ~/ros/setup.bash" >> ~/.bashrc

#export ROS_MASTER_URI=http://Desky:11311

. ~/.bashrc

Now ROS is all set up! lets just configure the Gumstix so that it automatically connects to WiFi on boot.

 

 

Network Config

In /etc/rc.local put:

#ifconfig wlan0 up
#iwconfig wlan0 essid [your SSID]
#dhclient wlan0 -4

You may not need the -4 , but without it my connection would fail every few minutes and I would have to request a new lease.
Also if you are using encryption you will need to set up /etc/wpa_supplicant.conf and change the above lines to something more like:

#ifconfig wlan0 up
# wpa_supplicant -Dwext -i wlan0 -c/etc/wpa_supplicant.conf -B
#dhclient wlan0
Now your overo is all set! Unplug the mini-USB and reset the Overo. After about a minute you should see the outermost blue LED blink violently then remain lit. This means you are connected.
To make things easier on ourselves and ROS, lets make another similar entry in /etc/hosts. This time assume the gumstix is 192.168.1.8 and we want to name it gummy

#echo "192.168.1.8 gummy" >> /etc/hosts

no tricks there.  Now you can log into your overo wirelessly simply by running

ssh [user]@gummy

You can now run your ROS programs , and the two computers should be able to find each other seamlessly.

 

Radiation Map : work in progress

 
 A recent news article got me thinking about Geiger readings in Japan, after a bit of Googling I came across some cool things like an upcoming Geiger shield from the Tokyo Hackerspace, and an aggregate data feed from Pachube with nearly 500 live datapoints. Excited to have all this data I decided to whip up something simple (in Processing) to plot it all on a map. I’ve been looking into to applying a predictive modeling construct (perhaps something like an ensemble Kalman filter with an atmospheric dispersion model for Cesium 137), to be able to plot the theoretical radiation levels in all of Japan. I tried modeling it simply with exponential decay, but the results were pretty abysmal.. hopefully I’ll hear back from my environmental studies contact and have something legitimately cool to show you shortly.
 

Ubuntu’s boot time black magic

  

In the not too distant past I was a hardcore Gentoo geek. My computer was MY computer, and its speed and the extent to which it was custom tailored were personal points of pride. Over time more and more of my friends made the switch to Ubuntu, and urged me to follow suit. I resisted.

  

One day one of these friends challenged me to a boot race and my custom Gentoo kernel was pwnd by a stock Ubuntu build running on [slightly] inferior hardware. So I stopped resisting and agreed to give n00buntu a try.

  

Not having to untangle circular dependencies or spend hours surfing the forums to get my _____ device working, I’ve have grown increasingly fat, lazy, deaf, dumb, and blind to the inner workings of my system. I’ve become more and more content with the idea that Ubuntu is so fantastical because of black magic pixie dust sprinkled into the source code.

  

I was reminded again of this boot time wizardry again today while working with a Gumstix Overo board, when a rootstock generated headless Ubuntu build loaded noticeably faster than the Gumstix’s preloaded Angstrom image. Then I came across this forum post titled All about ureadhead :

  

  

from http://ubuntuforums.org/showthread.php?t=1434502

thanks Keybuk

Setting up for mechwars

silly

 

These are the things that keep me from getting the really good grades in school

 

Robot Fever from Z R on Vimeo.

 

Just got commands to push over zigbee, so I should be doing much cooler things shortly…