Just curious if any Dopers out there have ever built any kind of working robot for whatever reason. What was it? What did it do? Is it fun at parties?
I’m actually starting work on building an R2D2 replica. (It’s amazing: there’s a whole subculture on the 'net of people devoted to building R2 replicas.) This will probably take me at least 2 years and run into the thousands of dollars…oy. But hey, it’ll be great at parties (I’d love to build Jabba’s drink tray for him) and I bet I could earn some cash back by renting it out.
I’m working on one at the moment; in a nutshell it’s going to be a robot guard dog, but people get the wrong idea when I say that.
It’s about 2 feet long by 18 inches wide and roughly elliptical, driven by two geared steppers at the midpoint of each side, driving 5 inch wheels with rubber tyres, it has free-rotating castors at front and back.
It is powered by a bank of 4 12V sealed lead acid cells slung underneath the baseboard for stability.
It will be controlled by an old Pentium 133 that I bought surplus and will have a wireless network card to communicate with a base station (which will share some of the AI and storage of sensory data). It will be equipped with range measuring devices (haven’t made up my mind between IR or Ultrasonic yet), directional sound light, passive IR and heat sensors, a digital camera and spotlight, an electronic compass and whiskers to prevent collision with anything that the range sensors miss.
The idea is that it will be left to patrol a warehouse at night; to start with, it will explore it’s environment and generate an internal map of which parts of the warehouse are accessible and the best routes to get there, it will then set itself a patrol route and wander about listening and looking; if it detects anything unusual, it will move toward it and attempt to capture video footage (this footage will be transferred wirelessly to the base station in a secure area, so that it will be preserved even if an intruder should destroy the robot. The base station can be set up to alert the keyholder or the authorities as necessary.
Most of the mechanical stuff is built ready to assemble, I have some good ideas about the software and data, it’s just a case of putting it all together and working the bugs out.
Neat! I hope you’ve got a patent pending on that thing if you can pull it off.
Is the video feed somehow connected to the robot’s internal map? In the few robots I’ve built…ok, ok, it’s from a Lego Mindstorms set…you can build something with a predetermined path, but if anything bumps it out of the way, the program won’t know to account for it and it’ll keep moving as if it were still on that course.
I have built many robots. In fact, I put one together just a few hours ago. Of course, I am an engineer for a robotics company. That’s probably not what you had in mind though.
When I was a kid I painted a cardboard box and taped it on top of a radio controlled car, then I put a walkie talkie in it’s head so it could “walk” and talk. Does that count?
I’d go with both. I’ve used small robots that have both on them, and there are situations where their usefullness overlap, but most of it doesn’t. The ultrasonic is very good for getting fairly accurate distances off relatively flat surfaces that are ~3 to ~15 feet from the sensor. IR isn’t very good for the longer distances, nor is it good for surfaces that don’t reflect IR back at the sensor.
The bots I was working with also had passive CDS on it (light sensing) which also had it’s uses. If your device will be meant to function in areas where the lights are off, passive light sensing would make it able to chase people with flashlights, or respond to a light turning on somewhere.
I’m not sure it’s all that original an idea; probably the best thing to do (if I get it working) would be just to try to get it into production, but I’m not too bothered; it’s just a pet(no pun intended) project.
The video feed won’t be (image recognition is quite a hard thing to implement), but the other sensors will be; it will start off with a blank map (or perhaps I’ll tell it where the absolute boundaries of the building are) and it will attempt to fill in the detail itself, mostly with the range sensor.
Internally, the map will be represented by a set of ‘nodes’; in it’s very simplest form it would work like this:
The robot is placed at a known datum and it creates the ‘origin node’, it chooses a (cardinal)direction and attempts to move 1 metre in that direction, if successful, it creates another node in it’s database, along with route information describing exactly how to move between the two nodes. This process is repeated; any particular node can be examined to see if there are any unexplored directions from any of the nodes; Assuming that the direction chosen for the second leg of the exploration is at right angles to the first, an ‘assumed link’ can be created (by trig) between the origin node and the third node, but the machine will have to test all of these assumed links in case of obstacles.
Once the network of nodes is created, moving from one side of the building to the other (or between any two points) becomes a case of the classic travelling salesman puzzle, which is quite easy to solve by algorithm.
Mangetout, are you sure the travelling salesman problem can easily be solved? IIRC, it becomes exponentially harder as more nodes are added to the map. I’m not a mathematician but the problem is discussed regularly in the New Scientist due its difficulty. (www.newscientist.com)
Good suggestions Wikkit; the passive light sensor will require almost no extra electronics, so there’s no reason not to.
Some of the new IR range finding modules are really rather good, having a range of up to 15m and detecting anything except a mirror, but there’s no real reason why I couldn’t implement both; ultrasonic is less directional and better for detecting small obstacles.
Interestingly, quite early on in the design it became clear that all of these sensors need the ability to be aimed; originally, the robot was going to be perfectly circular, so the aiming could be done by rotating the whole machine, but that would have made it too wide to fit easily through a standard doorway, so I had to make it narrower, which in turn means that attempting to rotate on the spot carries with it the slight risk of grazing against a stationary object, so I’ve decided to mount all of the sensors in a cluster on a rotatable ‘head’ (makes more sense anyway; if you’re following the line of a wall, you don’t want to have to keep stopping and turning to see if it’s still there).
I’ve solved the travelling salesman puzzle using SQL.
(Well, alright, actually, I haven’t because the issue I’m facing is much easier; get from A to Z by the most economical route only - the travelling salesman puzzle requires that you visit all of the nodes en route)
(although of course all the methodology actually consists of is trying every possible combination, it’s just that the user never sees the poor results).
A suggestion. Instead of trying to compute the best route from node A to Z, why not always go via B, C … X and Y. The computer will map the location as it explores and in so doing creates a route map where every node is on the optimum route to the next. When patrolling (after mapping the location) the robot will pick some random node and travel to it along its already known route. When there, it selects the next node and goes to that one. If you have a route from Z to A, then you have the option of reversing direction as well.
The only computational exercise is to get from node Z to A directly. Even then, you only have to do it once and store the route. The problem becomes one of selecting a route rather than trying to compute one.
It’s like the old maze solving robots – the fastest is a machine that tries every route with blinding speed rather than trying to work out one correct route. Such machines are, IIRC, banned these days form robot Olympics.
Another possibilty would be to select routes to travel at random and ‘score’ them on their efficiency, the machine could then be made to favour high scoring routes (although it would have to try a few untravelled ones or else the potentially best routes might never achieve a score - kind of programmed curiosity).
the problem with computing optimum routes from one node to all adjacent ones is that it is inefficient on a larger scale; it seems to me that this approach might miss a shortcut route that involves an initial step that isn’t optimum.
I assume the key parameter is how many other nodes a given node connects to. If you limit the number of connections allowed to a single node, then you can optimise your robot’s routing knowledge. You don’t need a route to every other node, just enough to run a patrol pattern. (But the robot may need to know waypoints between two nodes not directly connected.) Also, if the robot is patrolling, it doesn’t necessarily need the best route between nodes. I would suggest that it needs a route that covers the minimum amount of territory for a useful patrol pattern but does that route need to be particularly efficient? An inefficient patrol pattern is harder to predict, making the patrolling robot better at its job (assuming intelligent intruders). The main requirements for a patrol pattern, IMHO, are having no blind spots and being unpredictable.
By the way, my expertise is in financial systems, so I am not in the slightest equipped to help design robot patrolling software. But I have an opinion…
Do two, with at least 15 degrees between them. Since the input from them is really simple, having two makes some programs a lot simpler.
[quote]
Some of the new IR range finding modules are really rather good, having a range of up to 15m and detecting anything except a mirror, but there’s no real reason why I couldn’t implement both; ultrasonic is less directional and better for detecting small obstacles.
[quote]
I should get back into robotics. Expensive stuff, though. The new IR sounds interesting; I wasn’t working with really high end hardware.
Makes good sense. On the bots I was working with, the IR was mounted so that it had one pointing slightly to he left and one slightly to the right. The robots also had a problem with going straight, because of some drive bias problems. So it could see the wall while driving beside it, but just barely, and when it was that close it’d tend to either run into the wall or veer off and lose the wall.
One thing that I found makes every program easier: feedback. The bots I was working with had wheel counters, so that you could find how many times each wheel had rotated. However, the stupid programmers wrote the base probram so that when you read from one of the buffers, it zeroed it, but not the other. Drove me batty, and the counters didn’t even work all the time.
There isn’t any design limit on the number of interconnections between nodes, but I can impose one if I want; the key is that the links are all straight lines, so the layout of the floor will limit them to a certain extent.
Because the absolute position of the nodes will be stored (the robot will keep track of itself), it can examine pairs of nodes within a certain range of each other and attempt to travel in a straight line from one to the other, establishing a new link if successful, establishing an ‘antilink’(to prevent wasting resources testing the route again) if unsuccessful; since the length of the routes is calculable and this will figure in the route plans, new links that are more efficient than old ones will be favoured.
You’re right about making the patrol plan difficult to predict -something I had completely overlooked - thanks.
There is though a situation in which it is desirable to travel from one point to another by the most direct route: when an incident occurs.
