Robot Building

I am a computer engineer, and we are currently building a robot for one of my classes. Do any of you know of any good resources that describe the overall layout of an autonomous robot? Like basically what components would be required to build an autonomous robot? I can obviously tell the major basic components such as power supplies and microcontrollers, but something with more specific advice would be greatly appreciated. Also any advice any of you may have would be greatly appreciated as well. Thank you.

I highly recommend Mobile Robots. It’s a well-written and relatively comprehensive look at robotic systems and design, aimed at the independent experimenter.

We did once with Lego Mindstorm. You can program in java, compile and transfer it into the robot’s JVM.

Are we talking something like a handyboard or mindstorms robot? Or something less embedded (like an activmedia or evolution robotics)?

I’m an AI guy working with the latter. I get the sense that you’re talking about the former, however. At any rate, here’s some links to check out (most are open source):

ActivMedia Robotics
Dave’s ROS
Lego Mindstorms
Modular Controller Architecture (MCA2)
Evolution Robotics
Python Robotics

Seattle Robotics is also a good place to look. They also have a mailing list where you can ask pretty much any question and get an answer.

I honestly don’t understand what you’re asking, but the robot is for SeCON 06. I am not sure if any of you are familiar with this, but basically it’s a competition where senior electrical and computer engineers at universities across the southeast build a robot for a class. Each class then competes with the other classes at their university and the best one gets to go to SeCON 06. Then about 40 universities compete in Memphis, TN this year.

The robot is supposed to simulate a FedEx shippping loader. Basically packages will come one at a time with a bar code on them. We then have to scan the bar code to determine which plane (actually just a box) to load it on. There are 12 packages: 4 have to be loaded within 3 minutes, 4 within 4 minutes, and 4 within 5 minutes. You don’t know the order they will come in so you may have to sort them first.

Basically that’s what I, along with 5 others, am trying to build.

Thanks for the links. They should be really helpful.

Sorry I wasn’t more clear, and no, I’m not familiar with SeCON. As I said, I’m an AI guy, so I work with the software on essentially pre-fabbed robots (i.e., those that come already assembled and have laptop(s) on or in them), which is a far cry from circuitry or mechanical design. Oh, and my main concern is with autonomous, mobile robots. It sounds like you’re working at a level much closer to the hardware (and hardware that’s different) than I’m used to.

I hope the links help you out; I think a bunch of them will be too high-level for your purposes. I’d specifically look at Orocos and MCA2. If you can’t use any of the available code, at least it might be educational or inspirational. I might be able to provide a bunch more information, if you have other questions – although again, I may not have the requisite familiarity with robots of the sort you’re working with.

How “autonomous” does it have to be? Do you mean it has to be mobile and walk around like that scary-looking Honda robot? Or simply that it has to be able to work on its own? Since the “packages” would be arriving on a conveyor, the simplest thing hardware wise that you could possibly build would be a gantry robot. Yeah, I know, they’re not cool looking like 6- or 7-axis industrial robots, and they don’t walk around and climb stairs, but they can reach an x-y-z in space. If you consider the massive amounts of mathmatics involved for an articulating robot versus a gantry system, you’ll find the programming to be a lot easier, too. (Note, I’m not a robotics expert of any type).

What’s a gantry robot? [url=]Here’s* a simple example found via Google images.

Okay, because you’re handling boxes, you can avoid lots of further complication on the end effector. You don’t need to worry about roll, pitch, and yaw. You don’t have to worry about approach vectors. Just have a fixed tool capable of lifting your boxes. One or more suction cups could be perfectly adequate, and you don’t have to worry about box orientation. Palletizing your packages at their destination platform can be done with a vision system.

There are a lot of small conceptual details I’m leaving out, but it seems like you shouldn’t have too many problems building this type of system.

A walking robot is cool, and articulating arm robots still can hypnotize me to this day, but remember that in industry, the simplest, cheapest, easiest to maintain system will always be preferred above the wow! factor.

It has to be able to move from a starting position over to the “conveyor,” pick up a box and then put it in the appropriate box by following black tape. The only thing we can to is power it on when we get the signal. The starting size requirements are 8"x8"x12".

Key to your choice of control hardware will be your preference of programming language; the choices on offer typically consist of:

  • Microcontroller devices that only run machine code, which you’ll generate with a compiler (or an assembler if you’re experienced, or brave, or both)
  • Single board (or single-chip) computers that have an onboard interpreter

What programming language would you most prefer to use for this device?

Personally, my favourite device for rapid prototype development is OOPIC - it has its drawbacks (chiefly that its complexity makes it not the most blisteringly fast device; not that this matters for most applications), but has some incredible strengths; the compiler can be switched between C, Java and BASIC syntaxes, the device incorporates a very good mix of different I/O lines and (the biggest selling point), it’s object-oriented - a library of predefined objects (for purposes including stepper motor control, polling IR or ultrasonic rangefinders, serial communication and keypad input); the objects can be linked together to form ‘virtual circuits’ so that an input or event can be processed to result in a specified set of outputs, without your program loop having to worry about it at all.
It’s considered a ‘toy’ by some, but it’s an incredibly powerful one; not something you’d look to embed in a marketable robot, but a first-class controller for rapid, no-fuss, flexible prototyping.

Regarding the microcontroller, I kind of assumed we would use the 68HC12 as we have had an assembly programming class using it already. I will look into the other microcontrollers as programming microcontrollers in assembly isn’t the easiest thing to do (at least for us ;)).

I am personally more comfortable with Java, then C, and then finally Assembly for the 68HC12 if is was absolutely necessary.

How much constraint (if any) is there on your choice of components?

BTW, another solution you might like to look at is the Javelin Stamp - basically a single-board computer, crammed into a 24-pin DIP package - programmable in (a subset of) Java.

I don’t think there are any constraints (besides buying a prebuilt robot) other than size. Starting has to be 8x8x12 and opened can be 14x14x20 (sizes in inches).

OK, I held myself back for the serious replies, but I can’t believe nobody else has asked yet…

Is it a gir robot?

One of these, eh? :stuck_out_tongue:

Do any of you know anything about encoders (you put them on a wheel and they are used to judgle velocity and distance traveled)? My main question is that, in general, how accurate are they? Like after 10 feet of driving could the encoder tell you have have only traveled 5ft, 9ft, 9ft 10 inches, etc? How much would this change with turning (right angled turns).

Here are some of the examples I am looking at:

Thank you.

Encoders on the CNC seam welders I used to work with were good down to 0.0001 mm.

Encoder accuracy is determined (at least partially) by the number of “ticks” on the wheel and the wheel diameter. For instance, I think the wheels on the page you linked to have 44 ticks. The ActivMedia robot I commonly use has 66.

Due to wheel and motor slippage, dead-reckoning is notoriously inaccurate, as the error continually accumulates over time. You might want to read Borenstein’s paper “Mobile Robot Positioning: Sensors and Techniques” (Journal of Robotic Systems, 1997) for an academic treatment.

Encoders are great, but unless the machine is on tracks that include some kind of datum, dead reckoning isn’t going to be enough over any reasonable length of operation.
GPS is actually quite an achievable (and not even horrendously expensive any more) solution for position sensing now.