<body bgcolor=#000033"><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener("load", function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <iframe src="http://www.blogger.com/navbar.g?targetBlogID=4830160160028833890&amp;blogName=DanShope.com&amp;publishMode=PUBLISH_MODE_FTP&amp;navbarType=BLUE&amp;layoutType=CLASSIC&amp;searchRoot=http%3A%2F%2Fblogsearch.google.com%2F&amp;blogLocale=en_US&amp;homepageUrl=http%3A%2F%2Fwww.danshope.com%2Fblog%2F" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" height="30px" width="100%" id="navbar-iframe" allowtransparency="true" title="Blogger Navigation and Search"></iframe> <div></div>

Tuesday, November 24, 2009

Syncing up SolidWorks

As a man on the move who needs access to my data from many different machines, I had struggled to find a good solution to access my SolidWorks files.

The Requirements
  • Should be free or low cost (hopefully not subscription based)
  • Should synchronize files with minimal user input
  • Just works, never needs me to doctor it
I've worked with the professional solutions like Activault, but didn't need quite that level of functionality for my personal use. A subversion utility was intriguing, but generally required too much interaction (commits, updates, etc) for my general workflow.

After manually copying files onto thumb drives, remote desktop-ping, and trying to get a network drive up and running I decided enough was enough. So began a journey through several sync solutions.



Dropbox was my first solution, and worked nearly flawlessly. Updates were transparent, and I could share with other users as well as keep certain folders private. The versioning system was pretty nice and saved me some hassles a few times. I finally ran up against a few limits with the Dropbox service: storage capacity and directory limitations.

Dropbox Storage
You only get 2GB free, which is pretty sweet, but not really enough. My only other option was to purchase a subscription plan, which starts at a hefty $10 per month for 50GB. That's the same as my web hosting, which gets me unlimited storage!!

Dropbox Single Directory
One of Dropbox's most annoying limitations is the use of a single catchall folder. I wanted to retain my file structure which is a complex of files spread across multiple partitions. The more I relied on the service, the more this limitation made the service unusable. It just interrupted my workflow.



This service didn't quite get the full treatment as I was already a little jaded from my Dropbox experience. Overall it was a major step forward - I could impose my own file structure, syncing was seamless, and there were the nice versioning and web-interface features.

Syncplicity is a fantastic service, and probably cuts it for most people. It's gotten rave reviews, it just wasn't the right product for me. If you want access to more than 2 computers, you have to upgrade, again with a monthly subscription fee. It is also Windows only (for the moment)...

Which brings us to the winner,




Not quite fully cross-platform, this service allows syncing between PCs and Macs. Much like Syncplicity, you have full control over directory structure and updates occur immediately when machines are connected to the 'net.


The web interface needs a little work, but for the most part was snappy enough to keep me happy. The syncing occurs fast enough that I get versions of the little temp files (~XXX.sldprt) that SolidWorks creates while you're working. If you've just synced a large number of files and they aren't yet downloaded, double-clicking on the placeholder file will bump it up in the queue. Nicely it also alerts you when the file gets downloaded to your machine.

I found that full versioning control wasn't really necessary for my daily use. A nice trick occurs when you delete a file (this can be done from any synced machine, not just the creator). A deleted file will get moved to the recycle bin on any synced machines. This is generally enough of a safeguard to recover accidently deleted files.


End Result? Happily synced files! I've been using this for the past few days, and it's been quite amazing. I have to remind myself that I can access my files from anywhere. Best of all? It's all free!

Labels: , , , , , , ,


Thursday, November 12, 2009

Autonomous Platoons: Brought to you by Over-Engineered Solutions

I was reading my news this morning when I stumbled across a new study funded by the European Union that got a little under my skin. (http://www.botjunkie.com/2009/11/12/truck-and-car-platoons-could-allow-for-autonomous-driving/).

The problem?
Drivers are lazy and can cause accidents.

Their solution? *European Union
Adaptive cruise-control vehicles that follow a lead vehicle on the highway. The lead vehicle is driven by a professional and the rest of the cars follow the leader while their drivers "take their hands off the wheel, read a book or watch TV."


There are a few problems with this. Overlooking the fact that trains have existed for decades, so this isn't truly a new concept, there are serious control issues that need to be addressed.

Follow the who?
How do you decide which vehicle is the lead? "Okay, so Bob is in front, and he's a truck, so I'll follow him. WOW! Bob is a terrible driver!" But I don't notice, because I'm sitting back, reading the morning newspaper.

Sure, you could have some smart software that decides Bob isn't going to get you to your destination safely, but if you're already going to have all that processing, why not just have full autonomy?

Make a left turn now!!
"Where am I?" Turns out Bob decided to take Exit 5, a few miles ahead of my actual destination. Since I wasn't really in control of my car, I lost time and fuel.

Perhaps there is some solution like pre-programming your route into GPS and letting the software take care of following its own path. But still, there's no guarantee that the driver hasn't fallen asleep when you need him to take back manual control.

Questionable Efficiency
The article cites a 20-40% efficiency gains from vehicles following closely, much like geese flying in a vee. What it fails to acknowlege is the fact that every member of this "platoon" has its own locomotion system. That efficiency calculation will probably tank when compared to a conventional train. There's also problems with wear and tear on each engine versus only needing to service a one or two engines, as in a train.

Conclusion to the Saga
There are definitely some interesting challenges to solve here, so I agree the study is worthwhile. It just seems like the focus is wrong -- a solution searching for a problem. And a problem that already has a better solution.

Mass transit isn't everywhere, and trains only work well on special tracks. The ability to travel in a train configuration while still retaining independent destination control is appealing. Our road systems and vehicle technology, however, do not have the necessary infrastructure to safely allow drivers to tune out while rolling down the highway at 60mph.

We've seen some great results from the recent DARPA Urban Challenge that alludes to the possible future of fully autonomous vehicles. I don't see a hybrid solution (people + robot) working out any time soon.

UPDATE: The NavLab at Carnegie Mellon did demonstrations of this technology back in the 80's.

Labels: , , , , , , ,


Friday, November 6, 2009

Extending the Scout robot platform

The Scout is a capable platform on its own, able to traverse rough terrain and avoid obstacles at high speeds. Even so, one of the main strengths of the Scout is its (rear) accessory interface.


Many research platforms were designed around a single purpose or only provide the ability for "expansion" cards in the form of networked printed circuit boards. Researchers working on the Scout platform won't be restricted to the current sensor/manipulation package, nor will they be constrained to fixed size add-on modules. The Scout provides power, data, and hardware attachment points to allow a variety of mechanical or sensor add ons. You can see the six threaded hard points in the rear of the vehicle, as well as a thrust bearing for pivoting accessories.

Dumb vs. Smart
The accessory interface attempts to be as non-restrictive as possible while providing both basic and advanced functionality to the designer. To that end we've denoted two classes of accessories, those with "smarts" (onboard processor) and those without. Both classes of accessories must identify their type/function as matched against an accessory database stored on each robot. This allows the OS to configure communications between the ARM and AVR at the bandwidth necessary for desirable performance.

"Dumb" Add-Ons
Dumb accessories are simple devices that only require power and access to an analog (input) or (2) digital I/O. This might be as simple as a wagon with a potentiometer for tracking position and a switch to indicate whether a load is present. Basic I/O pins are provided by the AVR.

"Smart" Add-Ons
A smart accessory has its own on-board microcontroller that handles all the low-level control. An I2C connection straight to the ARM9 processor is provided. Smart accessories can still access the AVR pins, although it should rarely be necessary. The forklift shown below is a "smart accessory" since it requires active control of the lift position and active monitoring of the RFID reader and loading.


Forklift/ Autonomous Distribution Warehouse
My favorite accessory to date, the forklift gives the Scout 0" to 6"+ lift capacity. Pulling tasks off the server, robots will autonomously move packages around, pausing to recharge when necessary. Mobile robots are already in use in semi-automated distribution centers, such as Staples.

The mechanism uses a three stage lift actuated by a cable pulley system. The RFID reader sits behind the carriage. When closed, the forklift does not extend into the sonar's sensing cone, enabling use of rear ranging data. The charging contacts also had to remain exposed so the robots can dock for battery refueling.


Dig & Haul/ Autonomous Excavation

Design to test cooperation between two or more robots, the dig and haul attachments provide an entertaining and challenging application of swarm robotics.

The designs both employ micro servos for actuation. Hauler also uses a load cell (force sensing resistor) to determine when the bucket is full and instruct the digger to halt loading.

Hauler could easily be implemented as a "dumb" accessory, but Digger requires it's own micro due the increased complexity of the control and positioning system.

What next?
Plans are in place to design a simple webcam interface, surveillance package, and a pan/tilt semi-automatic cannon. Have an idea of a sweet accessory? Add your concept to the comments below! I love hearing new ideas, no matter how radical.

Labels: , , , , , , , , , , , , ,


Thursday, November 5, 2009

Designing & Testing Robots: Colony Scout

Colony Scout Updated Design
Between classes, eating, and sometimes sleeping I've been hard at work refining the Colony Scout robot. The core feature set has remained the same -- four wheel drive, rocker pivot platform powered by a lithium ion pack. The sensor package includes a front bumper, dual sonar rangefinders, battery level monitoring, localization beacons, xbee communications, wheel encoders, yaw gyroscope, and three axis accelerometer.

Shown here in green (one of many colors), the Scout now sports a vented enclosure for the electronics. RGB (multicolor) LED "headlights" shine out the front hood, which is magnetically clasped for easy access to the processing board.


The team has been hard at work designing the Scout board, which runs an ARM9 core mated to an ATmega 128A as a coprocessor. The ARM9 does the heavy lifting but leaves the very important role of gathering sensor data and driving the motors to the lower powered AVR chip.

Board design is custom and includes components specific to the platform. We are looking into POE (power over ethernet), USB, and external charging to power the system.

Scout will run a Linux RTOS -- as yet to be decided. Linux brings a lot of functionality to the table but also has its own quirks that will be interesting during development and testing. We hope to have a first run dev board in testing by December.


Diagnostic Station
Testing and validating the robot design only goes as far as production. The diagnostic station aids the maintenance process over the lifetime of the robot(s).

I went for a pipelined design whereby tests are separated spatially to allow faster throughput with multiple robots. This results in an elongated testing platform, but it still measures in under a yard...so far :-)

Assuming the robot can navigate to the station, it will ascend the ramp and proceed through the three stages. All tests and robot maneuvers are controlled by the Colony server, which handles scheduling and task assignments for all the robots.


Stage 1: Chassis Dyno & rBOM Tester
The motors and encoders are tested across the speed range of the robot. A sequence of tests is also performed with loading on the dyno rollers. This simulates the robot driving across different terrains.

Stage 2: Cliff Bridge
Between the two larger stations, the bridge tests the three cliff sensors through several cycles (see ladder-like design). This comes after the encoders/motors are calibrated for straight line driving. We don't want robots to go splat during a maintenance run!

Stage 3: Gyro & Accelerometer Station
The final and most complex station latches onto the robot and spins it for gyro testing. Accelerometer tests are also performed by spinning and tilting the robot. I'm still designing the internal mechanisms -- should be interesting.

Dyno Station Mock up (who doesn't love Legos(R)?)

Other News
I've also been working on the design and function of the charging station. So far it's pretty sweet with a low profile, modular design. I'll try to post some renders and details up soon!


Labels: , , , , , , , ,


Wednesday, June 24, 2009

Sharp IR Rangefinders and Arduino: Make your Robot Smarter

Adding distance or proximity sensors to your robot is a great way to start exploring your environment intelligently. Rangefinders allow a non-contact method of “seeing” obstacles and can be employed in mapping and maze solving as well.

The Sharp family of infrared (IR) rangefinders is very popular amongst hobby roboticists because they are low-cost and easy to interface with (Voltage, Ground, and Signal). These hook up to a single analog input pin on the Arduino or similar microcontroller systems. There are a few caveats to watch out for though.

If your application is very time sensitive and needs tightly controlled, you’ll want to find out how long polling your sensor(s) takes. The Sharp sensors output an analog value (as a voltage), but microcontrollers only understand digital values (1 or 0), so that analog value has to be converted. Analog to digital conversion is pretty fast, but it can introduce some delays.

The sensors are also very noisy, meaning the analog output signal has a lot of "jitter" -- 20cm does not always equal 280, etc. Your code will have to account for this jitter, so you'll need to collect some real-world values to build your sensor model. This problem is exacerbated by the next issue, but can be overcome with a little bit of thought and time. I don't provide you the solution here because it's really dependent on your application. There is, however, a tool to help you evaluate your sensors (see below).

Moving on, take a look at this graph:

You’ll notice something interesting here – the graph has a weird curve and isn’t linear at all. This becomes tricky when trying to teach the robot to understand distance from the analog output of the sensor.

There are a few ways to get around this. If all you want is a simple threshold say “nothing closer than 20cm” then you can simply run a few tests with an object placed 20cm away from the sensor, and then hardcode that value into your program. Generally it’s a bit more complicated, if you want the program to understand varying distance.

Method 1:
Approach: Find a best-fit curve (generally exponential or polynomial) using a statistics package (Excel, R, Minitab)
Pros: Easy to implement, gets you started fast.
Cons: Requires floating point math, which isn’t natively supported by most microcontrollers. You can still use floating point, but it’s slow and inefficient in most cases.

Method 2:
Approach: Gather some data points and create a look up table of values. Your code will linearly interpolate values between each data point (ie, 5cm=600, 10cm=300, etc).
Pros: Uses integer math which is fast and efficient
Cons: Takes up more memory and doesn’t give exact values

Method 2 is the preferred approach as most embedded system developers take great pains to avoid floating point math. You can have some floating point math on the Arduino and be alright. I have a large (6KB) program right now that has floating point littered all over the place (it’s necessary for this code) and execution time runs just fine.

To help with gathering your data for both method 2 and simple thresholding I wrote a quick little application that interfaces with the Arduino’s serial connection. This app will pull your data in and calculate some basic statistics such as standard deviation, mean average, and range of values. You can store the data for future computation and reference.

Download the IRanalzyer at http://www.danshope.com/calton/ir.html

To use the IRanalyzer you need to send values from the Arduino. Here’s a sample sketch to get you started:


#define SerialSpeed 115200 //typical values are 9600 or 115200
#define SampFrequency 10 //sampling frequency in Hz (cycles per second)
#define AnalogPIN 0 //define your pin here

int mDelay;

void setup()
{
Serial.begin(SerialSpeed);
mDelay = 1000/SampFrequency; //calculate delay for proper sampling rate
}

void loop()
{
delay(mDelay); //delay in milliseconds
Serial.println( analogRead(AnalogPIN) ); //reads the analog port and prints value over serial
}

Labels: , , , , , , , , , , , ,


Wednesday, June 3, 2009

Inside the $400 Colony Scout: Robot on a Budget

Now that I posted some videos of the Colony Scout in action, I’ll discuss the platform in a little more detail.

The basics: It’s a compact (4.75”x6”), four wheel-drive robot equipped with an array of IR distance sensors, automatic recharging capability, and other features yet to come. The current talk is to use an ARM7 based board running at 40MHz, paired with an unspecified ATMega for additional I/O.

Some background: The goal of the Colony project at the CMU Robotics Club is to develop a low cost swarm robotics platform capable of structured coordination to carry out tasks too difficult for a single machine.

Colony has been around for several years and has made great strides with a few robot upgrades along the way. The team is prepping the Scout as a potential replacement for the current ATMega 128L based robots.

The goal: The Scout is a deviation from the 2-wheel differential drive robots used in the past. While a common and versatile form factor, the two wheeled platform balked at any non-level terrain. Even driving up ramps or over wires can become an issue. Scout is designed to expand the exploration options beyond level and rectangular environments.

What’s new? Faster processors and an efficient code base will permit the Scout to actively respond to a complex environment. The new sensor array extends the current 5 IR sensors to 7 for additional range and cliff detection. A bump switch returns for the front bumper to detect obstacle collision (useful when purposely pushing objects).

Each of the Pololu wheels comes equipped with a quadrature encoder that gives ~3mm linear accuracy. The 10x12mm micro metal gearmotors are lighter, faster, and stronger than the Solarbotics GM8s on the current robots. Using four motors does draw more current, so the battery is upped from a 6V 2200mAh NiMH pack to a beefy 7.2V 4000mAh Li-Ion pack.

Conclusion: The Colony Scout is a tough little machine that can cross rough terrain while employing a multitude of sensors, all for a sub-$400 cost per robot. Plans are in place to make the robots “smarter” than ever before, and able to respond to the environment faster and in a more coordinated manner.

Summer 2009 is all about prototype testing – learning about the platform and its capabilities and limitations, so stay tuned – More videos and posts will be coming your way!

What do you think? What types of functionality, from line sensing to 3D mapping, do you think a cheap robot should have?

See http://www.danshope.com/blog/2009/05/putting-colony-scout-robot-through-its.html for more pics and vids on the Colony Scout.

Labels: , , , , , , ,


Sunday, May 31, 2009

Putting the Colony Scout robot through its paces

The new Colony Scout platform was up and running for a few hours today as I continued testing the AWD system. Scout is a prototype platform for swarm robotics at the Carnegie Mellon Robotics Club.


We remade the baseplate out of 6061 aluminum on the CNC mill as the previous handcut plate was too soft and imprecise. I wanted the alignment of all the motors/wheels to be as consistent as possible for straight tracking with minimal correction from software.

The headers you see sticking up beside each wheel are for quadrature encoders - the encoders give the robot about 3mm linear resolution, which is decent for a vehicle of this size.


Another exciting component added today was the rocker, which allows the front and rear axles to swivel (vertically). This allows all four wheels to contact the ground during most terrain crossing, improving traction. The updated platform outperforms the Scout of two days ago, which featured a rigid baseplate.


The new components have a high degree of polish accomplished by good design and machining practices. Our club machine shop allows us to turn out quality parts and have a fast turn around time from concept to prototype.


Click through to http://www.youtube.com/watch?v=ePaPGyjW2uk to watch the video in HD.

There's also some great tests on http://www.youtube.com/watch?v=fyRmg570KJw from a few days ago.

Keep tuned for more updates this week!

Labels: , , , , , , , , ,


Subscribe to RSS Feed
Subscribe to DanShope.com
Who writes This Stuff?
Daniel Shope is the site owner and moderator of DanShope.com, a portal dedicated to robotics and engineering. Dan is currently a student at Carnegie Mellon University and is pursuing dual degrees in Mechanical and Biomedical engineering.

View Daniel Shope's profile on LinkedIn
Advertisements