DPRG and Robot News

Posted on 23 June, 2004 by steevithak

At the DPRG RBNO last night, I worked out the basic design for my robot power supply with the help of a few other DPRG folks. The plan is to use 4 of the Maxwell 350F caps to store power from solar cells. (Someone was asking about the cost – the single unit price of the caps is $25). One hitch to using multiple ultracaps is that you have to dynamically balance the voltage between caps. To do this you need a simple circuit made of an op-amp and a couple of resisters. You need one balancer at each connection between caps so, for four caps in series, you need three balancers. John Drummond helped me track down the TLC25L4CN low-voltage op-amp. It works on as little as 1.4v (which equates to .7v per cap). That gives me an operating range of 2.5v to .7v per cap or 10v to 2.8v for the entire power supply. Once I get the parts and test it, I’ll post a schematic.

In other DPRG news, the DPRG mailing list upgrades have been completed. The list now has better spam and virus filters, email address munging, and a shiny new searchable list archive going all the way back to 1997.

Robot Software Success

Posted on 3 April, 2004 by steevithak

I mentioned in my last entry that I’d been experimenting with the Not Quite C programming language for use with the Lego Spybotics brick. The hardware hack we made for line-following combined with a few lines of NQC code allowed one of the robots to successfully complete the line following course at Roborama 04.A (it took a last minute application of duct tape to block out some light leakage that was saturating the sensor). I still intend to write up the whole thing but I’m already contemplating further robot experiments that will likely involve a few of those new Maxwell 350F “D Cell” ultra capacitors.

Linux NQC for the Lego Spybotics Brick

Posted on 31 March, 2004 by steevithak

When Frys was dumping Lego Spybotics hardware a while back for $29, quite a few DRPG people grabbed one or two of them. So we have a whole pile lying around and nobody knows quite what to do with them. The Spybotics brick is a bit more limited than the original RCX brick and, to make matters worse, they come with a Windows-only “visual” programming environment. I’ve been setting up programming environments on a Linux box at the DPRG Lab for various microcontrollers and wanted to figure out something useful we could do with all our Spybotics bricks.

I had wired my brick up to one of the Linux boxes and started experimenting when Ed Paradis noticed it and we got to talking. It turns out he’s been doing some work on robot swarm behaviour using Spybotics robots. He suggested we try Not Quite C. NQC compiles C-like source to the Lego bytecode format used by the RCX and Spybotics bricks. This is cool because you can write code in a familiar language. Ed gave me a copy of v2.5 and I started playing with it. There is also a newer version 3.0 but it’s still beta and didn’t compile on Linux or OS X. After a little hacking on the makefile and code, I got 3.0 to compile just fine. (patch submitted to the maintainers of course!)

Like most converted toys, the Spybotics units are not exactly ideal for real robotics use. They lack any sort of sensors that would allow odometery and, after a couple of weeks of trying, we could find no way to make them go in a straight line or do any sort of remotely accurate dead reckoning. On the other hand, a minor hardware hack turned the optical serial link used for programming into a tolerable line-following sensor. And the robot-to-robot IR communication makes them a cheap way of playing with swarm behaviours.

I’m told this month’s issue of Circuit Cellar includes an article on hacking the I2C bus on the Spybotic’s motherboard to allow more sensors. If it’s not too much work, this could make them a lot more useful.

Sobig.F Robots Pacman and SCO

Posted on 22 August, 2003 by steevithak

Sobig.F fun

The W32/Sobig.F worm seems to be creating transient email logjams all over the net today. Even though we’re running Linux and not directly affected by the worm, we’ve seen a lot of really strange email traffic the last couple of days. Periods of no email at all will be followed by a huge burst of traffic as if the mail servers at other ISPs are alternately crashing from the load then being restarted.

Robots

Tuesday evenings these days are being spent at the DPRG warehouse, helping with network administration and doing robot-related software work. The debate about what to call the warehouse continues. I’m still in favor of just the “DPRG warehouse” or maybe the “DPRG lab” but a few folks prefer calling it the “clubhouse”. That word brings to mind old episodes of The Little Rascals more than cutting edge robotics. Meanwhile, we held the vote for moving the DPRG to an official 501(c)(3) non-profit group and it passed. So we’ll be working on getting the final tweaks to some new bylaws and other documents soon.

The Pacman OS

I ran across a Freshmeat.net announcement for Alpaca today. Alpaca is a multitasking OS that runs on Z-80 based Packman arcade boxes. Probably useless but it has a very high cool factor.

Time for an etoy-style SCO counter-attack?

This whole SCO thing is just getting out of hand. I’d like to see a much more organized opposition to SCO. The attempt by SCO and their lawyers to lay claim to code that isn’t theirs is very much like the attempt by etoys.com to lay claim to the etoy art group’s domain. The etoy counter-attack came very close to putting the company out of business and forced them to drop their lawsuit. Imagine a site that could act as a command and control center, organizing a counter attack against SCO designed to put them out of business. Planners could develop attacks which might include convincing SCO employees to quit, educating SCO ISVs and customers about better alternative products, organizing protests that coincided with SCO marketing events, and providing information like 800 numbers and fax numbers of SCO offices for those who wished to express their opinions to SCO directly. Volunteers could sign up for specific tasks and report back on the results.

More on Walking Robots

Posted on 9 September, 2001 by steevithak

I went to a regular DPRG meeting for the first time in several months yesterday. It turned out to be fairly productive. Eric and I did a little empirical research with his walking robot (which we’re likely to use as a starting point for the CF Walker design). We verified that it can travel up a handicap ramp. It would need some software changes and possibly some modifications to the feet to maintain balance on steeper inclines (or a sensor on each foot that could measure the inclination of the ground with each step and adjust the tilt of the leg accordingly).

We timed it moving 8 feet (2.4 meters) – it took about 20 seconds. That translates to 8.3 seconds to complete a meter (compared to our goal of 1.4 seconds per meter). We guessed there was a lot of software and hardware optimization that
could be done with the existing robot and I wouldn’t be suprised if we could drop it to 4-5 seconds per meter pretty easily. To get better speed than that would probably take more significant redesigning of hardware. Hopefully I can crank out some drawings shortly so we can start cutting parts for a 1/3 scale model in the next week or two.

Otherwise, this weekend has been spent pondering more corporate and “intellectual property” issues. Disney and the recording industry are making a major push to take away more consumer rights with the SSSCA, a new bill they bought from Senators Frizt Hollins and Ted Stevens. The bill hasn’t been passed yet but they’ll be pushing hard to get it passed this year. It’s sort of a sequal to the DMCA which took away our fair use rights to “intellectual property”. As many of us did when DMCA came up, Susan and I will be writing letters and doing what we can to stop the SSSCA bill from passing. But, of course, it’s very hard for citizens to interfere with corporate control of the government these days.

Slashdot has an article about the EFF OAL, yet another free music license. While the OAL looks interesting, I’m afraid what’s needed to fix the problem is something more than just another license. I have some thoughts on a possible solution that have been swirling in my brain for a couple of years but I haven’t quite managed to work out exactly how to make it work yet.

Thoughts on a Walking Robot

Posted on 4 September, 2001 by steevithak

In the spare moments between work today, I’ve been thinking about rough design parameters for the CF Walker biped. To get some initial numbers, I started with the fact that it has to complete a 10k walk. Jim and I decided on 4 hours as being a reasonable target to complete the walk (it takes the average human about 2 hours to walk 10k). To travel 10k in 4 hours, the robot will have to average 2.5kph or .69 meters per second. If the robot has a stride of 1 meter, it would need to complete one step every 1.45 seconds. I think a 1 meter stride is possible – Jim is thinking of something more like a foot (about 1/3 of meter).

Due to the time constraints, we’re unlikely to be able to do anything that requires dynamic balancing, which limits the design further. We still have several ideas for making it work but haven’t come up with one that we feel is a sure thing yet. Originally we were thinking we’d just scale up Eric’s Little Toddler since it doesn’t require dynamic balancing, already works, and they’ve mastered the software algorithms needed to turn it smoothly. It presents two problems for us though: 1. It can’t handle the non-flat surfaces that we’re pretty sure CF Walker will run into such as handicap ramps, curbs, and possibly pot-holes. 2. The gait of the current design is much too slow.

The speed issue can be partially dealt with at the cost of higher power consumption. But with a limited payload capacity, that means more stops to rest (recharge from the solar array), so we’ll need to find the best balance between speed and efficiency. We’ve also got a possible trick or two to tackle the problem of curbs but at the cost of giving the robot a very non-human gait.