Post Index:

Adding a new SSD to your EeePC 901

I meant to document this months back, when I actually performed this operation on my "FrankenEee", but I guess I was just in a post funk.  No harm done, I shall make up for it tonight!

I decided that the one thing I wanted to change about my EeePC 901 was the tight storage, and happened to hear promises of significant speed boosts as well from ActiveMedia's "SaberTooth SS" mini SATA SSDs.  At the time, I hadn't heard much about them, as everyone was scrambling for information on the hot new Runcore SSDs.  I bit the bullet, and picked up a 32GB drive for I believe around $129.

Shipping was fast from Amazon.  Came all nice and double wrapped.

Standard anti-static bubble packaging keeping the drive healthy through it's trip.  Which is great, since these things are not exactly cheap.

Installation was really simple.  Two screws under the Eee hold the access cover in place.  Simply remove them, pop the panel off with a small screwdriver, and you have access to RAM, the WiFi card, and the SSD.  Two more smaller screws hold the SSD in place.  Remove them, and carefully pop it out.  Then simply replace it with your spiffy new one.  I also took the opportunity to swap out the RAM for a 2GB Kingston stick.

Ignore the crazy antenna wiring off my NIC, I had previously swapped it out for an 802.11n band card compatible with Backtrack4 for playing with wifi injection, and added an external RP-SMA connector.

Now replace all the screws, and close the panel back up.

Now was the part I hit a small snag.  Upon booting, the BIOS would not detect the Sabertooth drive.  I disabled the internal 4GB SSD, and rebooted.  Entering the BIOS again, I now couldn't see either SSD.  After a few minutes of head scratching, a helpful post on the EeeUser Forums suggested I try resetting the BIOS to factory defaults.  Once I did that, both SSDs were detected, with the Sabertooth as primary (as I was hoping for).

I installed Eeebuntu 3 Base, and checked out my new storage options.

After all was said and done, I now sport a tri-booting Eeebuntu/WinXP/Backtrack 4 laptop that weighs next to nothing and fits very comfortably at the bottom of my backpack.  The extra space is a wonderful change after getting used to fitting my whole system on the 4GB drive, and there is a noticeable speed increase for both reads and writes.  I couldn't pin down a standard benchmarking tool that everyone would agree was valid and would run under Linux, but I can definitely tell the difference.

In short, this is a simple and effortless upgrade to your netbook, and it's even easier to afford nowadays with SSD prices dropping.  Plus while you're in there you can bump the RAM up past the 1GB limit Microsoft is imposing on distributors, and maybe even upgrade your WiFi capabilities.


Modifying Servos for Continuous Rotation

Originally posted January 17, 2008:

In my recent delve into simple robotics, one of the major pains in the rump has been modifying servos to spin a full 360 degrees, making them into little cheap gear motors to push my little creations around the house.  The biggest hassle to the process is getting the servo potentiometer to stay at the "90 degree" position, tricking the internal electronics into stopping the motor when I send it a pulse to head for 90 degrees.  The standard method involves cutting out the mechanical stop on the final gear, drilling out the tab that locks the same gear to the potentiometer head, and gluing the pot in place after adjusting it to the proper position.  The issues that are inherent in this process are many, but include having to break apart the glue and re-adjust the pot if your voltage source ever changes, and having it dry just out of position, as these pots (at least in the HS-311 servos) are really, really touchy.

When I went looking for a better solution to the problems I was seeing, I found a number of people that recommended using a pair of 3.3k resistors tied together to produce a three legged fixed resistor network in place of the pot.  In theory, this would mean that the resistance from the center leg to either other leg would be equal, fooling the control circuit into thinking it had a perfectly centered pot.  I thought this an ingenious approach, and that fact that it would be immune to bumping and such was a great bonus.  In practice, finding two exactly identical resistors, soldering them perfectly so as not to add undue resistance, and accounting for the internal resistance in the rest of the circuit that apparently throws things out of whack was a major pain in my bootie.  I needed a better approach.

Searching Digi-Key, I decided to try a large turn pot that would allow me to fine-tune the resistance as perfectly as I could.  I settled on this guy here, a 5k 25 turn pot small enough to fit comfortably in the case.  After posting about this plan on the Society of Robots forums, another poster suggested to drill a hole in the side of the servo for the screw adjustment to protrude though for easy access to adjust later.

Once the parts came in (always fast through Digi-Key), I popped open my servos and cut out the stock pots.  Soldering the original wires to the legs of the new pot, I ended up with a nice, simple mod.

Then I simply drilled the hole for the screw to poke into, and closed everything up after a quick test.  The pot is held in place internally with a little bit of super glue (use the gel type, it won't flow everywhere), and the mod looks very clean.  You can see the small gold screw adjusters from the back of ADAM.

These are now super easy to adjust when testing, and with the amount of changes I'm always making, a really nice time saver.  The bonus to doing this in the future to other servos is not having to drill the plastic out of the center of the large gear riding over the stock pot, since the pot can be completely removed with just one screw.  Some servos have inserts for this gear that can be popped out easily with a screwdriver, but the HS-311 does not.  Total time from a stock servo to a sweet cheap gear motor with this method: less then 10 minutes (plus dry time for the glue if used).  I wish I had done this sooner.


Flashback: ADAM MK2

Continuing with my post re-posting, here's most of the details of the ill-fated MK2.

Originally posted December 30th, 2008:

Wow... 2 months since I did any kind of project worth blabbin' about here.  I blame the holidays.  And maybe Fallout 3.

About a month back, I was inspired by Admin (Yeah, that's the name he goes by) of and his project "ERP", the Experimental Robot Platform.  The idea was to build a reusable base platform that could easily be changed and built upon to try out new algorithms and mechanical designs without having to build a new (and basically the same) platform each time.  This was the idea behind the ADAM project as well, but that proved to be kinda ill conceived on my part.  I placed a good deal of emphasis on the breadboarding section and headers for ADAM's first incarnation, and I really didn't need/want all of that after all.  Sure, it was great practice, and a fun first attempt at something useful to keep me occupied and geek-saturated, but I know I can do better.  SOR's Admin has WAY more talent for this then I, and does a great job of planning, sketching, modeling, and documenting his projects.  His site and forum are easily the primary reason I decided to finally build in the first place.

In the spirit of continuing improvement (possibly through repeated failure) of ADAM, I came up with a MK 2 design to enhance my fun.  And in the spirit of a filthy, filthy zombie, I cannibalized the hell out of ADAM MK 1 to build him (and took his brains now that I think of it...)

The plan is to swap out the AVR micro for a full Arduino Decimilla, cut the form factor down by about half the size, replace the silly RC car salvage wheels with RC aircraft tires (again, thanks Admin!), and add a 2 deck design for plenty of space to add servos, sensors, arms, etc.  The upper platform could be easily swapped out completely for new ones if need be, and the whole thing will just look more professional then a crappy Radio Shak board on a piece of crappilly cut plastic. (6/7/2010 EDIT: Boy was I wrong! Haha!)

Deciding I'd like to place the servos underneath the lower platform, I needed some quick brackets to hold them in place.  Firing up my scroll saw for the first time since I bought it (finally!) I cut up 2 little "C" shaped brackets out of trusty HDPE.

These I could mount on the sides of the platform to hold the servos.  ADAM MK1 used a load of Gorilla Glue directly on the servos for this.  I don't recommend it, as it makes one look both unprofessional and lazy (not to mention impossible to fix right if a servo burns out).  I also realized that glue + HDPE is not an easy marriage to work through (although in a pinch, E-6000 is absolutely GREAT).  A few minutes drilling pilot holes and I was in business.

The main problem I had with ADAM MK1 (besides the fact that I wanted to switch to an Arduino) was keeping him straight.  I couldn't tell if it was programming and servo calibration, the recycled RC wheels, or the el-cheapo caster on the front that was making him swerve all over unpredictably.  Besides the nice RC plane foam tires I'm using in MK2, I ordered up a pair of omni-wheels.  This would reduce drag to an absolute minimum up front, as omni-wheels can easily move in any direction with little friction.  I haven't quite figured out how I want to mount them, but the idea is to drop down a piece of HDPE on either side of the lower platform up front, and run an axle between them. (6/7/2010 EDIT: Don't do like I did here and mount TWO omni-wheels on the same axle.  The added point of contact is unnecessary and hurts performance.)

So that's where I'm at after tonight's fun.  I still need to find standoffs for the second platform to mount on, and I'm thinking about battery placement for the servos.  I'm planning on either using some of the empty portion in front of the micro and 9V casing, or just velcroing the pack to the underside, since I have about 2 1/4" of clearance, and the pack I'm using is about 1/2" thick.

So far, I'm pretty happy.  It's WAY more professional looking, and should be easy to play with after I've figured out the upper platform.  Once I find a few standoffs and mount the omni wheels, I should be driving this lil' guy all over the house.  First planned project: mobile web-controlled camera to screw with the cat from work.

Originally posted January 4, 2009:

Further work has gone into the improved ADAM platform.  So far, this includes:

- Mounting the omni-wheels to a front axle (a threaded rod with hex nuts to hold everything in the proper place)

- Mounting the axle through two HDPE brackets screwed into the chassis

- Adding standoffs to the base chassis to hold the Arduino board

- Mounting the 9V battery holder and switch, as well as the 6V battery pack (between the servos on the underside)

To easily wire in the servos, I placed a small breadboard in front of the arduino to act as a power/signal bus.  In the future, this could be removed and replaced by using a Roboduino instead of the Arduino.  Maybe in version 3...

One issue I've run into is the differences in how the servo control signal is pulsed between my old AVR code and Arduino code.  If I tell the servos to stop (i.e. rotate to 90 degrees for an unmodified servo), they continue to rotate.  I've dissected the servos and readjusted the internal pots to keep the wheels from rotating in that case, so I'll have to keep an eye on that.  The servo pots are so sensitive that I may have to go back in and replace them with a set of fixed resistors instead in the future.

The other lesson learned was signal noise messing with my servo setup.  Apparently, if I connect the ground from my 6V battery to the ground of the Arduino, the noise can be eliminated, and it seems to have done the trick.

Hopefully, this means I'll have a finished bot sometime within the next few days.  After that, I'll need to work on the wireless control system.


Well, the MK2 incarnation wasn't a total failure in the end.  He's been pretty dead in the water the last few months as I got wrapped up in other projects and "real" life.  Here's the one pic I could scrounge up taken before I cannibalized the parts for other projects:

Final thoughts:

-Use ONE omni-wheel on the forward axle.  Two causes drag when you take a corner.

-Mounting servos perfectly straight is hard.  Making sure the wheels are also straight on the servo horns is also difficult.

-I have problems properly cutting HDPE into usable shapes without mangling it.  I blame my jigsaw, which I have recently discovered is SUPPOSED to cut crooked.  Grr...

-Try to use separate power supplies for your microcontroller and the servos.  Line noise and voltage drops add to troubleshooting issues.  But remember, tying all the ground lines together helps to reduce noise.



Flashback: ADAM MK1

I really hate having to transfer my old projects over here.  Rather then pretend I'm adding any of this fresh, or trying to hack apart old descriptions, I'm going to take the lazy route and add a bunch of photos of the older projects here, with descriptions.  At least I'll have an archive of something I've accomplished that way!

Originally posted July 3, 2008:

For the last few months, I've been toying with the idea of building myself a little robot.  I figured it would be fun to build, and also be a great platform to learn more about the Atmel AVR microcontrollers I've been experimenting with.  A few weeks ago, I decided to take the plunge, and bought a few servos and a sheet of HDPE plastic to mount on.

Long story short, I designed and built the thing pretty quickly considering it's my first 'bot.  So without further adieu, I present ADAM v1.0:

He consists of:
- 2 HiTEC HS-311 servos modified to spin a full 360 degrees
- An Atmel Mega8 AVR Microcontroller
- A custom 5v DC regulated power supply powered off of a 9V battery
- A soon to be replaced 7.4v Li-Ion battery pak I stole from one of my RC choppers (Need a 6v pack for the servos)
- A custom PCB consisting of 4 servo sockets, a pin breakout for the AVR, I/O headers, and a 5v power header
- 2 awfully large wheels I stole from an old RC car Kate found at a thrift store

Total cost: Roughly $50 so far.  Could have probably built it cheaper, but I wanted nice parts so I wouldn't have to worry about them breaking down.

I have a Maxbotix LV-EZ2 sonar rangefinder headed my way, as well as a mini breadboard to mount in the empty space on the PCB.  Should be fun to build on this guy this summer.

Originally posted July 10, 2008:

As previously posted, I've got me a little robotics project on my workbench to keep my brain functioning when I get bored with TV.  Which is, like always lately.  It's designed to be a platform to learn with and grow with, and man, has that been kickin' my pasty geek bootie the last few days.

First, the wheels turned out to be mounted pretty badly.  After a few failed attempts at getting servo horns attached, I finally made them stay on well enough to make me feel great about it.  But once I got the first servo test program up, I realized they were just off center enough to make the chassis ride funny.  Can't have a faulty platform, now can we?  So I ripped those puppies off pretty quickly until I come up with plan B.  (Actually, Plan B is drying as I write this.  Should be centered better now, but we'll see tomorrow...)

Then I spent days trying to fight with funky programming issues.  I just wanted the thing to drive straight as a test program, and I ran into all kinds of issues with my compiler.  I'm using AVRStudio 4 and AVRlib, and had no idea how I was supposed to set up the header files to make them work.  It was weird.  I could compile my program, but it would only pulse one servo at a time, which would make ADAM jerk forward one wheel at a time instead of one smooth straight run with both wheels.  After several posts on the Society of Robots forums, I was about to give up for a few days to clear my brain.  But as a last ditch effort, I started from scratch, re-coded the whole thing, and now it seems to be working perfectly.  I have no idea what the hell happened, but I really don't care.  I have a functioning code base.  Yeeha!

Pulling further cowboy expletives from my throat, my battery pack, breadboards, and sonar rangefinder came in today.  ADAM's starting to finally look like he can be shown to others without having to answer "But what does it do?" every time, and I should be able to make him semi-autonomous in a week or two after I figure out this I2C stuff.  Sensor communication = big learning curve.  Anyway, here's a pic with the breadboards mounted and the current (super simple) wiring through the jumpers I've set up (sans wheels as they dry):

Also, because I always work on seventeen projects at a time, I've started picking up Python.  It's one of those geek skills that can potentially come in handy every day on your PC, and so far is so super easy it scares me.  It's like learning BASIC, but with street cred.  I can see why so many people are devoted fanatics.  If Jesus were a programming language, he may just have been Python...






Originally posted July 11, 2008:

As a quick tip, I made a pretty silly mistake early on in my haste to get this lil' guy rolling.  If you're modifying servos so that they spin 360 degrees, make sure you power them from the same voltage source as they will be using once you mount them.  If you don't, you may end up having the issues I did with zeroing them out later to make them stay still.  Since I used a 5VDC bench top power supply when I initially zeroed mine (and am now using a 6VDC Ni-MH battery pack), I was pleasantly aggravated when I noticed that I could move forward, back, and turn...but couldn't ever stop.  He'd actually just slowly spin in an almost imperceivable circle to the right.  Well it was perceivable enough to bother me, so I had to pop my servos off the chassis and open them up again.

Let me tell ya, scraping gorilla glue out of these things with an awl is no fun at all.  On the positive side however, I've learned a pretty handy lesson for the future.

Originally posted July 11, 2008:

Tonight I started playing around with the LV-MaxSonar-EZ2 ultrasonic range finder.  It seems pretty easy to configure.  I just hooked in a +5V and a ground line, and a single analog output line to my micro.  The sensor outputs ~10mV per inch down the signal line, and I just have the micro sample the voltage through the analog to digital converter and program a response to various ranges.

As of tonight, my servos are still waiting for the glue to dry, so I just hooked up a signal LED to the micro on another output, and tested the sensor with a quick function.  When it sees an object at around 7 inches, it turns the LED on.  Otherwise, it turns it off.  That's one of the drawbacks to using an ultrasonic sensor in this fashion: there's a minimum range needed to bounce the sound off of something and have a meaningful return.  Here's a video of it in action:


Yep, my commentary is always that lame...:)

So now I just need to have ADAM react to the range data appropriately, and he'll be able to pretty much free-range about the apartment without smacking into the furniture/walls/Kate's foot.  I still really suck at development software-wise, so the next part may be a bit trial and error.

I also found a source for some female pin headers, and other misc. goodies to expand on ADAM's mainboard and make him even more modular.  I didn't think I really had to until I was finding ways to mount the EZ2.  I ended up just soldering male pin headers to it, bending them 90 degrees, and then soldering it right to the front of the board connected to a second header to run jumpers from.  Not exactly modular.

Originally posted July 13, 2008

So mechanically, ADAM's been pretty set up for a while now.  Sure, we had our misaligned servos, non-binding glues, and failed mounting brackets, but it's pretty much been up to me and my mad programming skills.  By mad skills, I of course mean that when other people look at my code, they decide I'm crazy.  Also I guess it makes me swear a lot.  My C is pretty poor at the moment, so it took me a few hours longer then I anticipated, but this afternoon marks the occasion of ADAM's first official run all by his lonesome!

A victory for me I say!  The important thing here is that I'm constantly learning something new about AVR micros and how to interact with them, so all in all mission successful so far.

The latest issue with my coding is that I can't seem to get functions to work properly the way I'm working my timing loops.  The code seems to just make its way into one, then get stuck.  It's totally something in the way I write out my algorithms, but I'll figure it out soon I'm sure.

As far as the platform goes, it tends to pull to the right a bit on carpet.  I think it's because the wheels I used aren't completely straight.  The plastic inside is fine, but the rubber tire portion seems to be warped a bit on the right side, causing a bit more friction.  I'll have to see if there's something I can do about that.


Remotely Enable Remote Desktop

Well, let's start this off with a pretty common one I've been asked about lately: How to remotely enable remote desktop access in XP/2003.

Sometimes, you just need to get to a server from deep within the warm recesses of the IT closet.  And as an afterthought, you realize you forgot to enable remote desktop on that beast.  Well, I've been there more often then I like to admit.  So here's a neat little registry trick to get you back in without having to leave that cozy spot behind the racks you took ten minutes to crawl into!  A quick word of warning: this involves going into the registry.  If you feel that this is uncomfortable, you're probably better off just walking upstairs and logging in locally after all.  But if you're careful (or recklessly comfortable with this kind of work!) you'll be fine.

First thing's first, you obviously have to have administrative access to the machine we're connecting to.  That said, start up regedit on your local machine:

Start -> Run -> regedit

Now right click the upper right icon where it says (local), and select "Connect to remote machine".  Enter the name of the server we're opening up, and you should be seeing its registry instead of local.

Next navigate to the following registry key:

HKLM\System\CurrentControlSet\Control\Terminal Server

Now double click the "fDenyTSConnection" key, and change the value to 0.

Now, we need to reboot the remote machine.  We can also do that remotely by typing the following into a command prompt:

shutdown -m \\<em>servername</em> -r

where servername is the name of the remote server we want rebooted.

That's it!  Once the server comes back up, you should have access through remote desktop.

Another quick note, Windows firewall may be blocking remote desktop as well if it's enabled.  I have yet to personally try this, but I'm told you can adjust firewall rules over the network by using the following command:

netsh firewall set service RemoteAdmin

Also, this can be used in reverse to close access once you're done, which is a good idea on a LAN you're not 100% unconcerned about security with.  Especially on customer sites!