Back to Sensing

Finally had some time to tinker again.  This time working on the distance sensing function of eventual autonomic robot.  I turned to a good ol’ Arduino for the physical IO.  I got a Nano, and this is a sweet little microprocessor.  All the functions of an Uno crammed into a little DIP from factor.  For testing things out it is stellar.  Just plug into USB port of PC and run your IDE of choice and your off.  I decided on a Seeed Studio ultrasonic rangefinder.  This is pretty much the same as a Parrallax Ping sensor, or the SRF-05 rangefinders.  This Seed studio unit has 1cm resolution and pretty inexpensive.

My goal is to get the forward focal point more resolution (like a telescopic lens vs. a fisheye).  Ultimately I could and should use a laser rangefinder, but this approach is quick & dirty and ripe for tinkering.  My thinking was that perhaps I could narrow the dispersion of the ultrasound at least on the transmitting side.  I knew that because the sensors are separated by about an inch, narrowing the input or receiving side would reduce the amount of echo reception perhaps too much and give haphazard results.  Ultrasonic waves travel in a more focused pattern compared to audible waves in the first place.  So by creating a smaller source of waves, I believe the “beam” will be narrower.  My thought was to cover up the exposed area of the transmitting speaker  – they are little speakers in there (like whizzer cones in old automobile full-range speakers).

Nano-focused SONAR

Upon testing, I found that the stream of data (microsecond time) was pretty consistent with stray numbers that were off the chart determined to be the reflected ultrasound inside the chamber getting out through the hole.  By filtering that out in the Arduino sketch, I could get reasonable results.

SONAR Output

Since the above output was centimeters, I think the resolution is decent enough.  Before the lens mask and filtering, I had all kinds of values in a pretty wide range.  My guess it was from the transducer dispersal pattern catching an object behind or to the side of what I thought was in front of the rangefinder.  I will modify the code to test output in a graph to test the narrowness of the beam on real world objects.  I will either grab the values and put in Excel or write some code using Processing  (www.processing.org) to show the graph realtime.

Speaking of Processing – I love that software suite, platform, IDE or what ever you want to call it.  It uses the same format and syntax as Arduino sketches right down to the graphic interface.  So if you know “C like” sketches, using Processing will come to you quickly.  I found this awesome sketch by Lucky Larry in the UK who wrote a sketch for his pan-tilt rig using a rangefinder.  He wrote a graphical radar-like realtime screen output from the rangefinder and it is pretty slick.  I modified it a bit for my purposes, but kudos to him for the original sketch.

Graphic SONAR output (Processing)

So that is the screen you see while Processing is running the sketch.  Basically, you run your rangefinder sketch on the Arduino – make sure the serial output screen is not open.  Then you run the Processing sketch which reads the serial stream.  I modified the code to show “ping” reflections as dots instead of polygon areas.  I also changed it sweep only 4 degrees on either side of 90 degrees.  I can see a lot of potential with Processing and the Arduino family of processor boards for physical computing feedback.

Posted under Robotics,Sensors

Dipping into Alfresco

For our office, I needed to incorporate another collaboration site for our team on a project.  I had already used MS Sharepoint on a previous 3 year project.  The interesting thing is the users could never warm up to Sharepoint on that project.  Yes, Sharepoint is customizable, and I did a minimal amount with logo changes and the like.  But I think folks just found useability a little bumpy.  The main place for collaboration on that project?  Ended up being a plain old FTP site (which we always had) with one virtual directory/site as an upload area, and another virtual directory/site as the read-only repository.  Of course, that meant I had to do the moving of permanent documents and files to the ‘download-only’ site.

Enter ‘open source’ solutions for collaboration.  There a a few out there that do collaboration and ECM/WCM, like Drupal and Alfresco.  Based on the reviews and forums, I chose Alfresco.  Alfresco has two forks for end users: Enterprise paid-for model that is stable and comes with support, and the ‘community’ version that is pure open source with GPL and the whole 9 yards.  The community version is a little bit on the bleeding edge.  For instance the ‘beta’ which is available for download now is 3.4e, where the somewhat stable version is 3.4d (which I am using).  All-in-all, I am very impressed with collection of coding that is essentially java-based with a ‘spring surf’ model as the framework.

What are the main reasons I chose Alfresco?  Main reason is the Sharepoint compatibility.  Your Microsoft Office apps do not know the difference.  It works seamlessly from within the Office apps, or from the Alfresco server using “inline” editing.  Another reason is cost.  Well, that is a gray area.  Sometimes when using open source with no official support, you are on your own and a production environment can be at risk of strange things (this is the case with Alfresco too – more on that later) happening.  But the cost of the Community Edition is nothing.  The hardware is up to you (I have a 64-bit Linux box running Ubuntu 10.04).  To get basic Sharepoint functionality, I would have had to get Windows Server 2008 Web Edition (minimum entry costwise), and configured the Sharepoint Foundation (sharepoint services) to work for external token-based security logins, as I am not using our Active Directory.  Why?  because this project, like the last is a statewide project that involves people outside our organization.  Sharepoint does work that way using form-based authentication, but it wasn’t easy out-of-the box.  I setup a testbed version of Alfresco with the binary installer and it works with external users from the get-go.

Up and running:  It took two installs to get Alfresco running properly.  The install uses a binary ‘.bin’ file that aparently works on many versions of Linux (did I mention Alfresco is also available for Microsoft X86 and X64 boxes?).  My first install failed because I already had Tomcat on my box and it conflicted horribly.  That was the main reason, another was my SMTP server which was Zimbra.  So I uninstalled Alfresco, Zimbra, Tomcat, and MySQL.  I now had a clean Ubuntu server which still had Apache2 (I also deleted all virtual web sites for good measure).  Then I reinstalled Alfresco using defaults (I chose to have it install MySQL).  Once installed, it resided in /opt/alfresco directory.  I liked this idea better anyway, especially if this box was only used for this collaboration site/server.  All pertinent files are contained in one directory tree.  Nightly back-ups simply backup the /opt/alfresco directoty and everything gets saved like a bare-metal backup of a complete server.  If something goes horribly wrong, a simple replacement of that directory tree brings everything back the way you want it.  If you set it up as a service, then you have a script in your /etc/init.d directory to start it up and that would be the only other area related to Alfresco involved in getting it running.  If you don’t want it running at boot, you run from script (/opt/alfresco/alfresco.sh start).

Next I had to get my SMTP server installed.  I chose Postfix for simplicity.  There are a number of things you must do to get your email server to work with Alfresco for mailing out invites (the default model for getting users on the share site).  These are mostly taken care of in the global properties file (alfresco-global.properties).  Depending on your install, the best way to find where it is is (in Linux) “find -name alfresco-global*”.  You must set the server to know your email setup.  Like this:

##Email Outgoing ####

mail.host=your.server.org
mail.port=25
mail.username=anonymous
#mail.password=
#mail.encoding=UTF-8
mail.from.default=alfresco@yourdomain.org
mail.smtp.auth=false

The interesting thing about those settings is the default “from” does not work.  You have to go into the actual template in your repository to make that change.  You have to log into the share site as ‘admin’ to do this.  This is the file you want to change under ‘data dictionary’ in repository:

Email Invite

That should take care of email invites.  One other thing that is catastrophic if not taken care of.  In all the install and setup blogs, I did not see this mentioned.  It is pretty major.  It may be a moot point after the next version, but version 3.4d remains broken in the install binary.  It is this:  All goes well for your share site (days, weeks even) until someone uploads a PDF that messes with the java library.  Apparently not all PDFs cause the issue, but all it took is one with our site.  This can actually bring your site to its knees.  After that nothing works, including Tomcat.  If I had known about this beforehand, I would not have a live site come down (took 5 hours to find and solve issue).  What you get is an Apache page that says the ‘service is temporarily unavailable’ with ‘due to maintenance downtime or capacity problems’.  It happens after the upload and then if any user navigates to the ‘document library’…..boom! everything is hosed.  The real tricky part is getting it working right again.  If it was early in the day, a restore of the Alfresco tree would be a simple cure, but underlying problem still has to be corrected.  In my case it was in the afternoon and all the morning data would be lost.  restarting Tomcat throws errors because it died without getting rid of the ‘pid’ file in the tomcat ‘/bin’ directory.  What I did to get it back on its feet to do a proper shutdown was delete stop alfresco with alfresco.sh script (with errors).  Then I deleted all files in /opt/alfresco/tomcat/temp and delete catalina.pid and catalina.out in the /opt/alfresco/tomcat/bin directory.  This can get the site up and running again after running start script.  Of course, site goes down horribly the moment a user goes into repository again.  Boy, I wish I knew this information before site went live.  Anyway,  it has to do with two files – the pdfbox and fontbox files that relate to the java JDK files in the library.  Alfresco 3.4d shipped with version 1.2 of PDFbox and Fontbox.  A number of people on the net said that installing or upgrading to ‘openjdk-1.6’ vs. Sun or other versions.  Well that is exactly what I had, so that wasn’t the issue for me.  It is the actual PDFbox and Fontbox .jar files.  here’s the weird thing, replacing with current version 1.6 does not fix it, in fact it really screws up Tomcat and all the log files show tons of errors.  I like to delete current logfiles after each fix so I get pure output from current fix.  The key for me was replacing the .jar files with version 1.3.  That fixed everything – all stable again.  You get them here (go to older release section for 1.3):

http://pdfbox.apache.org/download.html   You simply replace the old 1.2 versions with the 1.3 versions (do not rename them, leave as 1.3), but you must remove or delete the 1.2 versions.  I left the 1.2 versions in with ‘.old’ appended to name and it didn’t work, so I moved them to an inert directory.  Where are they in the Tomcat tree?  Right here:  /opt/alfresco/tomcat/webapps/alfresco/WEB-INF/lib

I hope this helps you before you get into trouble like I did.

Posted under Applications

Blender gets a facelift

I have been using Blender since version 2.40 and have just gotten used to it.  It was always way different from other graphic user interfaces (GUI), but features outweighed the awkwardness of navigating around.  That has all changed with the almost released version 2.5X.  I applaud the massive effort that went into the recoding of the interface.  Although there will be a learning curve to get used to it, gladly the control sets and panels remain similar enough to 2.49.  Some things are just going to be different, but that is part of the improvement process – change is inevitable.  One quick example is the view window control.  Before (in 2.49), you could see what view was chosen in the pop-up menu – perspective or orthographic.  Now you just have the same functionality as the keypad toggle.  However, what you chose is displayed on the screen in the upper lefthand corner with white letters.  Yes, different, but pretty cool in the long run.

The new redesign is becoming more mainstream and looking more like other 3D applications.  My particular favorite is the ‘scene’ panel in upper right corner (default) which shows the objects in the scene.  This is very much the norm in other 3D apps.  I have some examples below.  You can see the difference between 2.49 and 2.56 first, and then some other 3D apps.  Notice how PovRay is way different with raw code as its interface – the least friendliest GUI.

Blender 2.49 (old GUI)

Blender 2.56 GUI

DAZ Studio 3.0 GUI

Vue 9i GUI

POVRay 3.6 GUI

Posted under 3D Modeling

Beagleboard + Ubuntu 10.10…Sweet!

Things are just falling into place with this Beagleboard.  The Ubuntu distro, although slow on installing packages is pretty damn robust.  I have installed a bunch of packages without a hiccup.  X11VNC works without any issues, and can access with ultraVNC without much screen lag.  My UVC webcam (which can be seen in motion in earlier posts) works perfectly due to great kernel library and UVC driver that was already in distro.  I added extras like “gUVCView“, which is an awesome webcam app.  I have installed “motion” and “UVCCapture” as well.  The goal is getting OpenCV on here and getting some video recognition algorithms going.  From what I have seen with Beagleboard, I have no worries.  The video pipeline on this board is pretty spectacular.  There is even a camera header installed on board for those ‘board cams’ which have 15-18 wires connecting them.  I will be boning up on my Python and then OpenCV will be a big chunk of my robot ‘to do’ list.

You can see below the beagleboard and the future enclosure body (torso) with the camera head aimed at the keyboard.  It actually defaults to 640×480 and I reduced the size in the .guvcviewrc file (found in user directory) to 320×200. For my testing and vision processing experiments, this quarter-vga format will be fine to cut my teeth on.

Ubuntu on Beagleboard-XM

Posted under Operating Systems,Robotics

New Tangent – Vortex86SX is History!

OK.  Why spend so much time on a frankly, underpowered system board.  Chalk it up to learning experience I guess.  That Vortex86 may have been the cat’s pajamas (pulled that from nowhere) about 5-10 years ago with 300Mhz, but the lack of FPU or math coprocessor cripples it nowadays.  Less operating systems will use it, and the workarounds for Linux and extra compiling are not worth it for a base system to hang other applications and projects on.  Now there are still many SOC and processor evaluation boards out there that do not have FPU capability, but the processing power (speed, memory) and community support make up for that.  Case in point: Beagleboard

I picked up a revision B XM version of one of these little nuggets and I am quite impressed.  What kept me from getting one years ago was the lack of VGA output.  All the other boards I tried at least had that.  This has s-video (usually crappy at best) and HDMI out.  I got back one of my old monitors which has a DVI input, and then I made the plunge for the Beagleboard.  Glad I waited, as the XM unit has a 1Ghz processor (TI Omap 37XX) and 512M RAM.  Pretty awesome for a board that is 3 inches by 3 inches (smaller than PC104 form factor by a smidge).  Here’s the bonus:  it comes with a 4-port USB Host connector (a hub, technically) soldered to the board, as well as a RJ-45 ethernet connector (smsc95XX), and the serial port is now soldered on as well (DB-9).  It comes with a 4G microSD card which is always recognized as an MMCblk0 device.  Many headers are also part of the board now, so no crazy tight-space soldering if you want to attach a daughtercard!

Beagleboard-XM

These ports and connectors make it very easy to work with.  Pretty much plug-and-go!  Important to get a 5V adapter, as this board is flackey if relying on power from USB OTG port.  Still, this 5V supply can power many devices on the onboard USB ports like (in image above) a mouse, keyboard, and 2G thumb drive!  And it still consumes less than 2 watts of juice.  I see a great future with this little board.

MAKING IT USEABLE

The SD card that came with it had a demo image for testing right on it.  This shows that it can boot up.  It is not, however, setup for a working system.  It comes with a recent Angstrom build which worked completely in ramdisk.  The only partition formatted was the 80M bootable fat.  The rest of the card was unpartitioned.  I copied the the contents of fat partition to a safe folder on Vista machine fat32 hard drive (USB) and proceeded to boot up one of my Linux live distros – can’t remember which one, but it was probably Puppy 5.1 or Debian Lenny.  Then I setup the Beagle SD card with Gparted.  I made a bootable fat at 90M, EXT3 at about 3G, and an EXT2 storage for the rest.  I suppose I could have put back the saved MLO and u-boot.bin, but I ended up going to a Texas Instruments site and used the MLO and u-boot.bin from their Android Froyo site.  Yes, I installed Froyo, and it worked, but it was pretty lame on a machine with no touchscreen and a mouse/keyboard.  If I got a touchpanel daughtercard, then perhaps.  Anyway, the packages and layering of the operating system is different (OK for phones, but not so much for a development robot system).  So, I kept the bootloader files and proceeded to test other systems.  I installed Angstrom and it worked great, except the package ‘universe’ was not that large.  i hit brick walls when trying to get things I thought I might need – like luvcview or uvcview.  Sure I could compile them for my kernel, but I was too impatient.  I tried Debian netinstall, but my kernal did not match my rootfs, because there was only one netinstall rootfs on debian ARM site and it was for 2.36.29 kernel, and I had 2.36.34……  You would think it would work (yes it booted and all, but installing modules for devices or adding packages kept spitting out ‘invalid format’ errors).

I ended up with Ubuntu 10.10 (Maverick I guess).  With help of Robert Nelson images, I manually installed the boot images with mkimage in Debian, and the rootfs on the second partition (untarred it).  Anyway, after altering the boot.scr a little and saving with mkimage, the Beagleboard boots right up.  If the serial port is connect to PC with a terminal program running (PuTTY for Windows, picocom for Linux) at 115200-n-8, it displays on both terminal and DVI output (LCD monitor).

Beagleboard DVI

Xserver didnt work after install because the distro image was a ‘minimal’ one – perfect!  I would like to be responsible for my own application bloat anyway.  So I proceeded to install X Windows server (apt-get install xorg) and windows manager – fluxbox (apt-get install fluxbox).

One note:  the ethernet did not work right away, which was really a setup issue.  For some strange reason, the ethernet installed on USB1 instead of USB0 like it always did before.  This might be because I had a thumb drive in the port.  Ethernet is really a USB ethernet.  So using ‘ifconfig’, I set a static ip, and used ‘route add’ to set gateway.  Pinging outside site confirmed working ethernet.  Very next step after that was to update package list (apt-get update), which had to be done before installing anything else like X windows mentioned above.  At last count, on this little board, I had 22,800 files and directories installed (from apt-get feedback).

PERFORMANCE

One mention on performance.  Ubuntu 10.10 is not a speed demon on this board.  Angstrom is much faster.  It is due to a combination of things – sheer file number and system footprint, SD card capability and format, and the fact that the kernel command to restrict CPU speed to 800 from 1000 (this will be fixed in a later update).  But I sacrifice speed for functionality at this point.  Afterall, I was going to be setting up a 300Mhz system before – so this is still like heaven.

Helpful Links:

Posted under Operating Systems,Robotics

Back to Linux

It has been awhile sinced I posted on this.  My wife and I have been travelling and other projects have been sandwiched in between (like a whole diversion into circuit building and green energy, etc.).  Anyway, I am back to hacking processor boards for robot integration. I am blogging about this because it may help others who may have hit stumbling blocks with a certain board for something seemingly simple as getting it to boot a fairly recent Linux kernel.  In the end, and looking back, it might have been easier to use another board afterall!  The board I am referring to is the Vortex86SX.  On paper, it sounds like a packed board, and indeed the DX version is already marketed as a “roboard” for robot building.  But, sometimes the fun is in the challenge and learning experience.  I also picked up the board on EBay for about $70.  It has all kinds of I/O and a regular VGA port and 2 hi-speed USB ports and runs only on 5v.  The problem…….no math coprocessor.  Pretty much cripples it with most OSs.  You can forget WinXP (even embedded version).  Win2K is just too old for getting current drivers.  It looks like Linux is the only way to go here.

It came with X-Linux which works, but the kernel is just old enough so most drivers are not rolled into it.  It seems to have lacked good ceveloper following.  For basic operation and if you want to brew your own drivers, it should be fine.  I wanted a little more main streamso I can get current apps and drivers.  First I started with SliTaz, which works great on my other 386 PC104 board, but it panics because of no FPU.  Then I really wanted Puppy Linux, but recompiling the kernel was tedious and threw all kinds of errors in my multiple attempts, just to get it going with no FPU.  I read another forum where someone had tried for weeks and got it to boot, but then had multiple failures to get a GUI working like X-Windows.  But I found another blog which solved my issues (http://choompon.exteen.com/20100128/howto-compile-debian-for-e-box-2300-sx).

My steps:

  • Downloaded the image (USB flash), which is way faster than recompiling on my own
  • using Puppy Live on my PC (or any other Linux variant)  I dd’ed the img file to a 256M thumb drive
  • using gparted, I set the boot flag of thumb drive
  • tested drive by booting to Linux on PC
  • put that thumb drive and CFlash IDE board (with 512M flash) onto Vortex board
  • booted Vortex board to USB thumb Linux
  • dd’ed partition of thumb to CFlash partition ( sda1 to hda1)
  • rebooted without thumb (Linux debian ‘Lenny’ comes up)

All is good!  I have a working PC104 board with lots of I/O, and the main reason……I plugged in my webcam (seen on previous posts moving with servors), and it recognized it.  It showed the sound portion of cam, which is a good start.  The next major thing I had to do was get the system to be ‘not live’, as the flash drive is essentially emulating a live cd system where the flash drive is like the cd.   I wanted to have apps and settings remain persistent.  This was accomplished by getting a bigger CFlash card (4G) and setting up partitions with gparted.  Partition 1 was 256M Fat32, 1 was 900M Ext3, and rest was Ext2.  I set boot flag to first partition and made it bootable with ‘syslinux’, which I think is way easier than Grub (no hd0’s vs hd1’s to worry about).  Made syslinux.cfg to boot with ‘rw root=/dev/hda2’ which made the second partition function as normal system.  Then I mounted the ‘live’ root system image as a new drive on /media directory, using “-o loop” at end.  Then while logged in as ‘root’, I cp’ed all the directories to the second partition (many are emtpy like /proc).  So now I had a huge user space with standard boot from fat32.

After putting new CFlash drive in board and rebooting, I had Debian system running on a writable partition and ready for app/driver installs.  By the way, the LAN port worked with kernel image, so using apt-get worked great after tweaking source tree and adding a few more like the archived builds from debian.org.  I had to setup network by editing the “interfaces” file – I used “auto eth0 inet dhcp” to get me going, then did network reset.

Posted under Robotics

ArcGIS 9.4 Beta2 (10) improved

I finally loaded ArcGIS 9.4 beta2 and I must say it works much better.  The install had a glitch with the new licensing format – something to do with the part that downloads the license directly to PC (different than before where you get a license file emailed to you and then you include it).  ESRI tech support worked through and solved the install, so it is running.  This is on my XP test laptop, so it wasn’t a Vista/Win7 issue.

Anyway, the issue I had before where VBA wouldn’t work at all with previously created scripts, now works as it should.  How it will work is VBA will be treated as an extension with an installable license.  This will be free and those that have to have VBA apps run on their PCs, will have to have the license and VBA extension installed.  Pretty much similar to Maplex extension with ArcGIS concurrent installations.  So I am happy with what I see now.  Interface still needs time getting used to – you do something for years the same way (since 8.2) with ArcMap, and then the icons and menus are moved around – it just is a little slowdown.  Of course custom menus can be set up to mimick the way the old layout was – I may mess with that  for goofs.

The bottom line for me is I don’t have to port my VBA code over to .Net as quickly.  The working VBA extension with 9.4 allows for more time to do the transition.

Posted under GIS

Main Board Regroup

I am starting to have problems with my underpowered x86 board I had already.  I kind of hit a wall when going further on the integration of cam for vision processing.  Even though the cam is recognized by USB port, the driver stack in Win2K does not handle the cam (I had tested it in a Vista notebook).  Driver on CD needs DirectX 9c – which will not load with this STPC processor (which appears to DirectX as a Cyrix).  I searched everywhere for a Win2K driver on the Web – no go.  If the damn board booted a more robust version of Linux than uLinux (which is bootstrapped on DOS), I would try the generic Linux Webcam drivers found all over the Net.  I tried using a driver for an old Logitec “eyeball” cam I had and ran the setup, only to hit another wall – bit depth of the video.  Since the only driver found with this board is a generic VGA, I only have 16 colors, even though I can get 800×600 out of it.  That was the straw that broke the camels back – Probably a great board for DOS or Win98, but nothing higher.

I have already purchased another PC104 board that will handle WinXP, has all the in-outs I need, as well as standard XP functionality.  I have already created my embedded version using NLite with an XP Pro disc I had before Vista.  Good thing I hang on to these!  I also bid on another board that will handle Debian Linux, so I will have that for possible parallel development.  Although developing in .Net Studio and dropping it into the PC104 board sure will be pretty uncomplicated.

Posted under Robotics

Pan-Tilt and Video Figured Out….

After much trial and error and success with PWM and the neck servos (Hitec), I found I was having problems getting the servos to work together using basic pulse width in the Arduino code. Each servo worked perfectly when singled out, but trying a pan-tilt at the same time caused servos slamming to the ends and losing all coordination. I finally found that downloading the MegaServo library did the trick. It was supposed be included with version 17 of IDE (which I have). Anyway, this library works great! The key is that it will allow all the pins to be used for servos, not just 9 & 10. My Arbotix board stops at 8, so I was out of luck with the default Servo.h library.

I had planned on interfacing a Panasonic CX161 board cam (have one already) to the STPC main board for the vision processing, but that would require a frame-grabber board or a composite vid 2 USB connector. After almost going with that 2nd choice, I remembered I picked up a $12 webcam at Staples around Christmas for goofs – I actually thought I could use it in a project somehow. This choice will cut out the video capture component because it is already built in! I mounted it to the pan-tilt neck assembly and will test interface to the Atlas STPC PC/104 board (with Win2K).

Pan-Tilt-Cam

Posted under Robotics,Sensors

Torso Box and Neck

I got the pan/tilt assembly from Servo City on Saturday.  While the unbelievable Packers-Cardinals game was on, I messed with prepping the Styrene box I had for the robot torso.  I drilled the holes and installed the STPC SBC towards the back, and the compact flash and power connector fit (wasn’t sure until I tried).  The nylon standoffs cleared the pins on the back of the board from touching case.  Then I assembled the pan/tilt with my HS-81 servos (less weight than regular servos, but with decent torque) and then cut a rectangular hole in the top of the box for it.  After drilling another hole for the tilt cable to go into the box, I was ready for testing.  Using the Arbotix controller (not yet installed into torso box), I tested the movement with a simple arduino sketch (AVI below).  Now that the  neck is figured out, I will figure out how to get my Panasonic board cam attached with its 5 or 6 interface wires.  I can always choose to use a USB cam and fill one of the STPC USB ports.

http://www.flynnmetrics.com/blog/wp-content/uploads/2010/01/CIMG54771.avi

 

Posted under Robotics
1 2 3 4