New Robot Control System!

[John Gutmann]

Where is have you thought about laptop size? the fragile LCD screen on it? Cost? a way to mount it. A operation system that will run without error, which means perfectly with a higher efficiency. This means no linux, no unix, no mac, no windows. they all get errors occasionally.

An embedded device is for more then controlling a microwave......there is is embedded devices in more things then you think. Cell phones and PDAs have said "embedded devices" in them. So if a PDA can have one why not a robot? If you give me a really good reason. I would certainly change my view on the subject, but until then I still think embedded is the way to go.

-John

[Protronie]

I have to say this topic has me scratching my head. I know just next to nothing about programing. My skills are in the nuts and bolts of things and quick fixes that get the job done.

I've been struggling to learn some C programing. Info here and from the young people I've work with have begun to help me understand programing.

I would hope that FIRST would take things slow and thoughtful before changing the programing languish .
I'm sure I'm not the only one that feels like a blind man in a room full of sharp objects when it comes to programing.

I would love something where all your would have to do is type:
Robot go forward 20 feet, turn right 90 degrees, go forward 10 feet, stop.
And it would do just that.

I know its a dream but its my dream so hey...

Your never too old to learn new tricks, but some old dogs just take longer to learn them.

Well thats my 2 cents on this.

[Alan Anderson]

Originally Posted by Protronie

...I would love something where all your would have to do is type:
Robot go forward 20 feet, turn right 90 degrees, go forward 10 feet, stop.
And it would do just that.

I know its a dream but its my dream so hey...

I helped develop an autonomous scripting system for our 2005 and 2006 robots that does exactly what you're dreaming of. We didn't use it this year because it seemed more important to make everything driven by camera feedback instead of by a prewritten script.

If things go well in our off-season software training this fall, I'll consider polishing it up for publication here.

[Qbranch]

Originally Posted by Alan Anderson

I helped develop an autonomous scripting system for our 2005 and 2006 robots that does exactly what you're dreaming of. We didn't use it this year because it seemed more important to make everything driven by camera feedback instead of by a prewritten script.

If things go well in our off-season software training this fall, I'll consider polishing it up for publication here.

Ditto. Team 1024's programming group calls ours RALFF... even has a (slightly unstable ) GUI compainion software that allows easy compilation of autonomous scripts by anybody on the team. RALFF was installed on this year's robot however its sensors never worked so it didnt show off like many saw on our amazing 2006 autonomous modes...

I'll have to write a whitepaper on scripting languages sometime... ehh... sometime...

And eh, again, on the whole x86 based robot controller thing... to make it work (and no, the HDD would NEVER take the g's)... you'd need a heck of alot of hardware... see previous post for an estimate.

-q

[ThomasP]

Originally Posted by John Gutmann

Where is have you thought about laptop size? the fragile LCD screen on it? Cost? a way to mount it. A operation system that will run without error, which means perfectly with a higher efficiency. This means no linux, no unix, no mac, no windows. they all get errors occasionally.

An embedded device is for more then controlling a microwave......there is is embedded devices in more things then you think. Cell phones and PDAs have said "embedded devices" in them. So if a PDA can have one why not a robot? If you give me a really good reason. I would certainly change my view on the subject, but until then I still think embedded is the way to go.

-John

Have you heard of cheap laptops? I went to Dell just now and saw laptop for $550, only $100 more than the current RC. If Dell became a sponsor, I'm sure they could knock another $100 off the price to match the other RC...

P.S. - I think my cell phone runs code a bit higher up than C... and I know it runs Java.

[Kevin Sevcik]

Originally Posted by ThomasP

Have you heard of cheap laptops? I went to Dell just now and saw laptop for $550, only $100 more than the current RC. If Dell became a sponsor, I'm sure they could knock another $100 off the price to match the other RC...

P.S. - I think my cell phone runs code a bit higher up than C... and I know it runs Java.

Erm. The issue with slapping any random laptop on the robot is that it doesn't DO anything. Not by itself. Laptops have no way to communicate with remote joysticks or speed controllers or anything else. Don't think for a second that all the analog, digital, PWM, and special serial I/Os that we want are going to come cheap. That kind of hardware will run you atleast another $300. And that's not covering how the heck you talk to the joysticks.

Also, since when do we programmers start begging to get off easy? The mechanical side of things may have more motors and parts options than ever, but they still have to cram everything into the box and get it under weight. I think it'd be a bit unsporting if the programming side of the equation suddenly had effectively unlimited hardware resources.

[Qbranch]

Originally Posted by Kevin Sevcik

...Don't think for a second that all the analog, digital, PWM, and special serial I/Os that we want are going to come cheap. That kind of hardware will run you atleast another $300. And that's not covering how the heck you talk to the joysticks...

...I think it'd be a bit unsporting if the programming side of the equation suddenly had effectively unlimited hardware resources.

I couldnt agree more. Just to reinforce, here's a sample price list of just SOME of the stuff you need to interface the CPU with a robot and a remote control pannel:

1) First, the previously mentioned laptop... $550

2) (1) NI DAQcard-DIO-24 card providing 24lines of digital i/o... NEARLY replaces the 16 digital i/o lines leaving 8 lines of I/O left for pwm... $199

3) (1) NI DAQcard-6024E card providing 16lines analog input and 8 lines digital i/o (to replace remaining 8 pwm pins)... $699

4) (opt) To get all the nice brought out pins the FIRST controller has, you'll need a breakout board, two of them, for a total of... $300

5) (2) USB->Serial converters, one for TTL port to a vision system or other peripheral, one for communication with the radio... $20

6) (2) XBee-PKG-R RS-232 Radio Modems for communication between the robot and the operator interface... $218

7) (1) PICDEM HPC Explorer board to make your own Operator Interface... $59

8) (opt) PC board for breakout of pins from the HPC board to your joysticks n such (optional if you want to make your board look nice)... $20~50

Provided you have your own joysticks and everything, this brings the sum total of this control system to $2065 as opposed to the current control system's price of $1147. I might also add that the components listed above would also need a safe haven in which to rest within the robot, which would add a large amount of weight and fabrication time to robot designs.

Well... that was a fun research project.

C code just because it's lower level doesnt mean it's bad, it just means it lets you operate closer to the actual control hardware than other programming languages. Also, I'd rather have a controller that weighs less than a pound and takes up very little space than a laptop which weighs several pounds and takes up a lot of space. Plus, the premade IFI operator interface pannel makes constructing an OI pannel a whole lot simpler.

Have a good weekend folks,

-q

[BrianBSL]

Originally Posted by Salik Syed

I don't see what the big need for an "embedded device" is ... why limit our selves to using chips that were designed for controlling microwaves? The way I see it the only thing these types of chips should be doing is communicating low-level data -- PWM values, sensor inputs etc.

It makes sense to use these chips if you have a very small robot or a flying robot that cannot wirelessly communicate to a master processor, and needs a computer which is light weight and low on power consumption. The robots we build for FIRST do not fall into this category. We can slap a laptop onto a FIRST bot very easily ...2-3 lbs extra is marginal, battery consumption is also very low.
It would be nice to be able to do more object oriented programming instead of having to deal with simple low level constructs. It would open a whole new world of possibilities.

I know others have covered this, but I absolutely cringe at the prospect of a general purpose PC as the primary robot controller.

By embedded controllers, no one means 8051's to control microwaves, we're talking about Xscales and such that run your pocket pc phones and DSP's that run your TV's and digital cable boxes. We're talking about full size ARM/DSP/etc 32-bit processors which are designed for embedded systems and not general purpose computing, which is exactly what we need. We don't need video, we don't need IDE, chances are we don't even need a PCI bus, which on a x86 system require external northbridge and southbridge controllers which are just excess. In addition, the price on them is far more than necessary for our platform, and they typically have a much shorter lifecycle than embedded microprocessors. What happens 4 years after the launch when Intel has EOL'd or obsoleted the chip that was chosen? We're stuck modifying the system in some way to support whatever we can get. Not to mention the fact that they often lack GPIO and extensive external interrupts, as well as other things that are 100% necessary for our application. Nor do we want to have to worry about some fancy DC-DC system to provide 4 different voltages to stuff.

And, I've never found that we have 2-3lbs to spare to put a full size x86 system on our robots. In addition - embedded doesn't have to mean small, battery powered, low current consuming devices. I have some cards at work with what would be considered "embedded" processors on them that will far outperform an equal cost x86 system.

Just because it is what you are familiar with doesn't mean its the right tool for the job - luckily, hopefully, FIRST will have a team (IFI or someone else, who knows at this point) that can handle it, and we will adopt to whatever they come up with.

And as far as cost - just because Dells sells laptops for $500 (which is cheaper than the current IFI robot controller) doesn't mean thats what an integrated system costs. The two microprocessors on the RC cost no more than $40 total - when bought as single units (and get deeply discounted by bulk purchase, as well as the fact that Microchip might be kicking something in). I'd estimate the whole board has $100 of parts to it. There's some serious markup here, as there is some serious support and R&D that goes into it.

P.S. - I think my cell phone runs code a bit higher up than C... and I know it runs Java.

I'm not sure what you mean by that - I'm pretty sure that the OS in the phone wasn't coded in Java, unless it runs java byte code natively.

[Salik Syed]

Well I'm saying why not build an interface for transferring data between a x86 type system and a low-level controller such as a PIC. Then we could easily build libraries to program via any language we wanted.

I think it'd be alot easier to debug software problems when we can run development tools straight on the processor. Having an embedded device without extensive debug tools would be a nightmare. With a PC type controller I could run 3rd party debugging tools straight on the robot and know exactly why my code doesn't work. All that is necessary is driver libraries written for a few different languages.

Also what about external 3rd party libraries written for x86 processors? Do you think they will port over seamlessly to your embedded processor? What if I want to run some complex image processing or motion planning ... how do I do that without modifying code that was probably written only to work with a limited set of hardware (A PC!)?
I don't really care if an XScale provides the same processing capabilities as an x86... does it support the same freely available library code and development software?

Embedded devices are nice for 3 reasons: low cost, light weight and portability. If we look at ease of use and flexibility the fact is that PCs win hands down. Cost is certainly a factor, but we are not mass producing these robots and selling them so a few bucks really doesn't matter much, nor do our robots need anything tiny and lightweight to fit in a phone.

Almost all the robots I have seen in the Stanford AI lab have a setup similar to this... Take the DARPA car for instance. They have four servers running Pentium 4s with extra hardware to support communication with sensors and car controls. The "little dog" robot has an embedded processor only for motor control and PID on the joints. They connect it wirelessly to their workstations (running Solaris) to do the actual computations and decision making. The roboticists need ease of use and flexibility ... PC based processors provide that. You have easier debug support and an almost infinite collection of library software at your finger tips.

[BrianBSL]

Originally Posted by Salik Syed

Well I'm saying why not build an interface for transferring data between a x86 type system and a low-level controller such as a PIC. Then we could easily build libraries to program via any language we wanted.

I think it'd be a lot easier to debug software problems when we can run development tools straight on the processor. Having an embedded device without extensive debug tools would be a nightmare. With a PC type controller I could run 3rd party debugging tools straight on the robot and know exactly why my code doesn't work. All that is necessary is driver libraries written for a few different languages.

Also what about external 3rd party libraries written for desktop PCs? Do you think they will port over seamlessly to your embedded processor? What if I want to run some complex image processing or motion planning ... how do I do that without modifying code that was probably written only to work with a limited set of hardware (A PC!)?

Embedded devices are nice for 3 reasons: low cost, light weight and portability. If we look at ease of use and flexibility the fact is that PCs win hands down. Cost is certainly a factor, but we are not mass producing these robots and selling them so a few bucks really doesn't matter much, nor do our robots need anything tiny and lightweight to fit in a phone.

Except they aren't. They have bloat because they are designed for general purpose computing. Those 3 reasons apply to some embedded systems, but there are many high end embedded devices that don't fit those 3 reasons once so ever, and are used because they provide enhanced performance for the specific application, whereas a PC is designed to provide general purpose performance, and not for a specific application. We know our application, and therefore a general purpose solution is not optimal.

Adding a PIC to a PC only solves some of the problems with the current system - the lack of performance for complex algorithms and floating point math. However, it doesn't enhance the lack of serial IO for multiple sensors (no user accessible TWI, for example), nor the lack of vectored prioritized interrupts, among other things.

And cost certainly is a factor, no matter what you say. When you start with $300 in hardware, WITHOUT ANY GPIO, then you have a problem. Remember, right now we are starting with $40 in hardware, that already has GPIO. Do we really want a $1000+ robot controller?

What time of image processing algorithm isn't designed as a library or provided as source code that will compile with anything? It shouldn't be hardware dependent at all.

And as far as debugging, any real system would have a JTAG port or similar functionality. Plus with a RTOS you should be able to have serial console or other similar access. I don't really understand what a general purpose pc adds. Thousands of engineers every day work on controllers designed to do similar things to our robots, and very very few of them use PC's as the controller for it.

I'll say it once again, x86 is not the solution. Just because it is what you are familiar with doesn't mean it is the best solution. Everyone will stick with what they know being the only possible/best solution, but in this case it isn't.

[Eldarion]

I say everyone should get an FPGA and program in Verilog!
They are so much more powerful than general-purpose computers...

[Qbranch]

Originally Posted by Eldarion

I say everyone should get an FPGA and program in Verilog!
They are so much more powerful than general-purpose computers...

Yeah but you've been working with them to make your vision system for a long time!

Have to say though... the power and the parallel processing capability of FPGA's is enticing... though i've herd the compilers for FPGA's as well as the hardware itself is extremely expensive, little out of the range of most of us unless its for a 'real' project not a fun project.

Anyhow, the possibilities are interesting...

-q

[Adam Y.]

The "little dog" robot has an embedded processor only for motor control and PID on the joints. They connect it wirelessly to their workstations (running Solaris) to do the actual computations and decision making. The roboticists need ease of use and flexibility ... PC based processors provide that. You have easier debug support and an almost infinite collection of library software at your finger tips.

Thats really nice and all but rapid experimentation is the only purpose to little dog. In fact from what I understand the information gathered from Little Dog is ported into Big Dog. I honestly doubt that Big Dog is running a traditional computer.

[Salik Syed]

Originally Posted by Adam Y.

Thats really nice and all but rapid experimentation is the only purpose to little dog. In fact from what I understand the information gathered from Little Dog is ported into Big Dog. I honestly doubt that Big Dog is running a traditional computer.

What do you mean by ported into Big Dog? A robot can be used for many things... what you are speaking of is probably a single application that the little dog robot is used for. There are many different universities using the Little dog for very different research goals.

What they are doing at the AI lab is trying to create a knowledge model which allows multi-legged robots to traverse extremely complex terrains. The robot literally learns how to walk across different surfaces as it tries over and over (and often fails) to cross a certain type of surface. For this type of computation they most certainly DO use a traditional workstation for computation. Of course if we were to have an actual military robot or something an embedded processor would be the right choice ... but for experimentation it's easier (for them) to work on a computer.

In response to BrianBSL
Actually when I was talking about cost, I meant for an interface... Users would provide their own PCs so it wouldn't "really" be part of the cost ... everyone has access to a PC or Mac all that is necessary is the right hardware and interface software to make it communicate with a robot.

And now that I look into it more I can see where you are coming from... I still feel like it's not as black and white as you make it because we are still limited by tools that are compatible with the embedded chip.

I don't have much experience with embedded chips...So I think I should probably learn more about them before I say anything else.
Say I wanted to run some Python code to control my robot wouldn't I have to port the source code of the interpreter to work on the embedded chip... ?? Would this be an easier task then writing code to let us have access to the hardware interface?

[BrianBSL]

Originally Posted by Salik Syed

Say I wanted to run some Python code to control my robot wouldn't I have to port the source code of the interpreter to work on the embedded chip... ?? Would this be an easier task then writing code to let us have access to the hardware interface?

You can run linux on many embedded processors, including the intel Xscale, so it would be as simple as compiling the Python interpreter for that chip.