ESP is a new robot I'm considering. "Considering" is about as strongly as I can put it. It's enough of a stretch for enough reasons that I don't know if it's possible. But that's what makes it fun, right? In the event that ESP gets built, it'll be a mini-sumo robot. (Love the format, love the challenges involved, so I like going back to mini-sumo.) It will have a single sensor, MAYBE edge sensing, though I'm trying to avoid it, and it'll have a holonomic drive platform. Details? Sure... The idea for this sprang up when I read about Terry Fritz's ThereminVision II system. It's a quad antenna e-field sensor that lets you know if another robot is around. The idea behind Terry's sensor is at least a hundred years old. But his is the first time, I think, that anyone applied it to remote sensing for a robot. Here's his URL: http://www.thereminvision.com It's a 360-degree on-all-the-time sensor that can give you heading and potentially distance to your opponent. It can also detect the edge of the playing surface, though I'm not sure it'll be sensitive enough to detect the 25mm drop in height off the edge of a mini sumo ring. Time will tell. Given that you always know where your opponent is and how far away they are, this opens up certain strategies for mini-sumo. For starters, there's no hunting. You know where they are. For another, if my guess is right you can potentially know not only what direction they're in and how far away they are, but with a little more smarts on-board you may be able to tell which way they're facing. You'll certainly be able to see which way they're moving, provided you can do some line fitting to your sensor data. Which is where the platform comes in. A holonomic platform can move in any direction up to 71% (or so) of the full speed of the motor. For a four wheel holonomic platform, anyway. For more info on this, try Googling the term and watching some videos. It's cool! It does work. It just requires omni wheels small enough to fit into a mini sumo. Thank goodness I do machining! I've got a couple of designs up for these wheels and for the molds I'll need to cast the soft urethane rollers for the wheels. (Hey, I learned my traction lessons on Shallow Blue!) In the end it'll be a platform with a good torque safety margin, speed equal to or better than Shallow Blue, and no need to turn in order to change direction. The combination is a robot that can tell where its opponent is at all times, how far away it is at all times, what direction it's moving, and where its sides are. It will also be a robot that can move in any direction, spin while moving, waste no time turning, etc. Since the worst situation for a mini-sumo to be in is to be near the edge and get side-swiped, that's its attack strategy: Stay away from the other robot until you know where its sides are, lure it near an edge, and whack it in the side. No more head-on attacks! Hahahahahaha! Well, that was good for a laugh. I hope you got to laugh, too. Did I make it look simple enough? Did you buy into it? Heh! So did I. Stepping off cloud nine and back down to reality, here's the REAL plan: I've got a ThereminVision II sensor system on order. I'm going to use either Shallow Blue or Black Dolphin as a test platform and stick the ThereminVision II system onto it. The OOPic II+ can't measure pulse width with the resolution I'll need, so I'll switch to an Orangutan or Baby-Orangutan from Pololu. The code for reading pulses is already in the library. Just need the timer code to measure duration (this is a one afternoon project.) If I can at least match the existing performance record of Shallow Blue or Black Dolphin, the sensor performs as well as or better than the IR rangefinders I've already got. Next is to test edge detection and see if I can do away with the edge sensors. This simplifies the mechanical design of the holonomic platform. Minor sticking point, but it'd be a major coup for Terry Fritz's design if it winds up being the only sensor on the robot. Next is to make some plastic-only 25mm diameter omni wheels. Before you scoff, understand the rollers wind up being pretty tiny. Roller axles are 1/16" or 1mm hardened steel pins. The rollers themselves are barely 5mm in diameter at the fat part. If the all-plastic omnis work out it's time to make new rollers and cast urethane over them. Considering four wheels eat up eight rollers apiece, that's 32 rollers for four wheels. Plus spares and I'm going to be CNCing 64 rollers and eight wheel shells out before I'm done. This will be a pain in the rear, so lots of testing along the way. Given the existing sensor set (Sharp IR rangefinders, Fairchild IR reflectivity sensors for edge detection), can the holonomic platform hold its own against Shallow Blue or Black Dolphin? There's some concern the answer will be no. Apparently omni wheels are notorious for slippage and traction losses. Those kill you in mini sumo. If it can't at least beat the existing platforms, preferably in head-to-head matches, it's not worth pursuing. I know, I know, the whole plan is never to BE in a head-to-head match. But plans rarely pan out in the end, so I expect it'll wind up in the worst-case at some point, no matter how well I design it. (And maybe just maybe its extra mobility will allow it to pull some robot equivalent of a Bruce Lee move that'll get it back OUT of a head-to-head.) In any case if it DOES work, the ThereminVision II and the holonomic platform will be mated together. Initially it'll use the same "find 'em, ram 'em" approach until the hardware and software glitches are worked out. After that the real fun begins. After that I get to find out if I can make a smarter, faster robot that can actually try to be sneaky for a change. I'll post as things happen. 11 Mar 2007 Update - I finished writing the count-down/up timer code for Orangutan-lib. (It really was a one-afternoon project.) It's not polished enough to be checked into Subversion yet, but it's at least functional. As soon as the ThereminVision II system shows up (and as soon as I build it, test it on a scope, blah blah blah) I'll try to read it out using the pin change interrupt code already in the library and the timer code I just finished. Ideally what I'd like is a free-running set of interrupt routines, preferably using code out of the library, that'll continuously read the TV II system and store the pulse widths in four variables. Another routine, called once each time through the main loop (i.e. NOT an interrupt) will do all the heavy-duty math to turn the four antenna values into actual direction, heading, and potentially cross-section. (You can tell I keep dreaming about this...) In any case the Orangutan code is all set. I've got a Baby-O and a serial level shifter stuck on a breadboard just ready and rarin' to go. Now all I need is for the mail to arrive! Back to CAD... 15 Mar 2007 Update - Mail's been weird again lately, so I wrote off to RobotLand, Inc. (the folks who sell the ThereminVision II system) to verify my order. Everything was good on their end, and it should be here this afternoon or tomorrow afternoon. So there'll be some good electronics fun this weekend, I hope! On the software side, after a couple of email exchanges with Terry Fritz on the ThereminVision Yahoo! group, it looks like my original approach to reading the TV II system is needlessly computationally expensive. He really did design an incredibly flexible sensor system. I think I can get the sensitivity I need with a blisteringly fast readout speed, but it'll have to be polled instead of interrupt driven. But that's ok! With the count-up / count-down timer code, having it poll the sensors every n milliseconds is entirely doable. Even so, there's more code to write! I'm still not convinced that my idea for measuring distance with the system is entirely a crock. Since you have a system of equations with a lot of knowns, six of which are distances (hey, I DO know where I put those antennas), I think you can determine not only direction and a real, physical distance, but also get a figure for effective dielectric area (a combination of dielectric constant and presented surface area... can't figure out how to separate the two). What this means is that for a given robot, after a little observation it should be able to tell you if the thing is square, round, whether it starts tall and flops down upon start, or whatever. If I can get a high enough sensitivity without making things unstable, I think it can detect a sudden change in aspect ratio on the opponent: if it's making a turn. Which would be cool, especially if I can characterize the motion of the holonomic platform WELL. For example, if the opponent is moving away from me, stops, and makes a sudden change in aspect ratio, I know it's stopped and is turning. Knowing the distance, if I also know how fast I can accelerate and close the gap, I can have the robot decide if it's worth taking the opportunity to attack. Catch is this gets into a lot of math. A LOT of math. Floating point on the AVR is doggingly slow. And I'll need something other than simple integer math to pull it off. Enter fixed-point decimal math! (I haven't done this since doing 3D graphics programming on a 4.77MHz 8088!) Most of the fixed-point libraries out there are a little too flexible for what I need. Even Pascal Stang's fixed-point code in AVRlib is prefaced with a statement from Pascal saying that his code is an example, and that the programmer should really hand-code something tailored for their setup. I'm tempted to use the same system I had on the 8088: Q8:8. Sixteen bit numbers with 8 bits on either side of the decimal. Math operations simplify hugely with that kind of setup, and integerizing is a matter of taking a 16-bit number, doing an 8-bit shift, and calling it quits. No progress on the omni-wheels, unfortunately. I forgot I'd torn down my mill's spindle speed controller and hadn't built the new one yet. A project for another weekend or a couple of evenings during the week. I'll be adding one of Peter Homann's DigiSpeed boards to the new controller, giving the mill computer speed control over the spindle. It'll be sweet. And it'll make building the omni-wheels even nicer. 19 Mar 2007 Update - ThereminVision II system showed up in the mail today. W00T! So I'll be busy with the soldering iron tonight, and hope to have a test bed ready for tomorrow (a 10cm x 10cm block of MDF with the boards and antennas mounted on it.) That and one of the mini sumo rings from the club should give me all the tools I need to find out if ESP's sensor system is going to fly or not, whether I need edge sensors or not, etc. I'll post more when there's more to be posted. 26 Mar 2007 Update - The test bed took longer than I hoped. To make the test platform I did a 1:1 printout of the ESP chassis CAD drawing, glued it to a 1/4" piece of MDF, and cut it out on the scrollsaw. Some drill press work gave me mounting holes for all the boards and mount points for the antennas. The test bed is put together. The boards were very easy to assemble. So easy I put them together one morning when I woke up at some awful hour and couldn't go back to sleep. Even in that frame of mind it only took me an hour. The wiring is a whole 'nuther story. Because of board size constraints, Terry Fritz was unable to come up with a two-layer layout that let him bring all the wires together on headers. So the wires between the sensor boards and the processor board look like spaghetti! It's awful! If you have issues with building robots with messy wiring, this is not for you. But if you don't mind a little copper pasta on your bot, solder away. I'll be testing the software over the next few days, and will begin sensor characterization shortly after that. I'm about to ship Shallow Blue off to the UNI mail-in mini-sumo competition. But once it comes back I'm going to pull the Mark III board off, tack the ThereminVision board on top, and stick on my Orangutan. And away we go. 30 March 2007 Update - Well, I didn't get to test until last night. Calibration software's done, and it can be tweaked to run the tests I want it to do. But in the meanwhile I have a problem. I plugged in the TV-II boards and just about burned up a 7805. Considering the device is designed to draw only a handful of milliamps in operation and much less when quiescent, I'm guessing my assembly left something to be desired. Next is to pop all the boards off, test them one-by-one, and find out what's going wrong. But for now the TV-II system is offline and testing is stopped until it's functional. 2 April 2007 Update - Terry Fritz rocks. I posted my symptoms to the Yahoo! mailing list for the TV-II system, and he came back with a likely cause and a solution. I hadn't noticed that the chip orientations on the controller PCB are not consistent, and that one of them is reversed. Chances are I have that chip in backward, which is what's causing the power drain. Next question is: Did I fry the thing in the process? Only way to be sure is to un-solder it, flip it around, solder it back, and test. Funny thing is, this is one of the first projects where I didn't socket every single little bitty chip. Usually I do. I have stacks of sockets for just that reason. But nooooo... I wanted to save on space and weight. Oh bother. Some day I'll learn. I'll post more once the thing is tested out. 3 April 2007 - Had to cut the chips off the board with angle cutters, then remove each pin individually. Pain in the rear. Those two chips now have sockets, not because they need them, but because if I manage to flip one around while soldering in the replacements, I might just throw this thing into the wall and call it quits. (I'm a little torqued off right now... I don't care how hard it is to route, I now understand why my boss goes ballistic if someone comes to him with a layout that has chips facing in opposite directions.) Digikey order first thing tomorrow. @#!$!!!! Tom
This project has the following developers:
- tbenedict is a Lead Developer.