New Robot Control System!

[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

[BrianBSL]

Originally Posted by Qbranch

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

Most FPGA companies have a soft-core microprocessor solution for it. Xilinx has the MicroBlaze, with hard-core PowerPC's on some of their FPGA's. Some pre-synthesized "master code" could be provided as the hardware description for part of the design (including the motor IO), and then teams could optionally add digital logic as necessary, or use the pre-provided logic. Then, they could program flash directly that would hold the microprocessor code. Pretty much, this allows them to ignore the digital logic part and just use the microprocessor if they would like, or have the ability to add digital logic to the FPGA itself. Cost is an issue, however. For example Xilinx's EDK sells for $1000 or so - although if you only needed their SDK (just a port of eclipse) and gcc, it may be significantly less.

[artdutra04]

Originally Posted by Salik Syed

...We can slap a laptop onto a FIRST bot very easily ...2-3 lbs extra is marginal, battery consumption is also very low...

I'm sure the hard drive would love all those high gee impacts.

[Eldarion]

Originally Posted by Qbranch

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

Actually, that is the same misconception that prevented me from working with these powerful little buggers for quite a while.

The software (compiler, IDE, etc.) is completely free (download the Xilinx WebPack). The development board that I am using for my vision system is "only" $150, and comes with a programming cable and power supply.
EDIT: If you don't need as many gates as I did (you probably won't) you can get the same kit for $99. That's less than the cost of a microcontroller development kit and compiler!

So , on the contrary, they *can* be used for fun projects... :evil laugh:

[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.

[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.

[ThomasP]

Originally Posted by BrianBSL

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.

I was just throwing that in there to support the use of high level languages on embedded devices since a few people are complaining about the possibility of using a language like C# or Java instead of C.

[BrianBSL]

Originally Posted by Eldarion

Actually, that is the same misconception that prevented me from working with these powerful little buggers for quite a while.

The software (compiler, IDE, etc.) is completely free (download the Xilinx WebPack). The development board that I am using for my vision system is "only" $150, and comes with a programming cable and power supply.
EDIT: If you don't need as many gates as I did (you probably won't) you can get the same kit for $99. That's less than the cost of a microcontroller development kit and compiler!

So , on the contrary, they *can* be used for fun projects... :evil laugh:

Yes - I own both the Spartan 3 and Spartan 3E dev boards (although my Spartan 3 is currently non-functional, thanks to me accidentally putting 12V at an IO). The 3E would be a very capable starting point as it can easily hold a MicroBlaze and plenty of other logic, and has the SPI A/D etc. I had considered developing an interface to one of these for our robot this year, but there simply wasn't a need for it with autonomous being so worthless. The Virtex 2 Pro and Virtex 4 boards with the built in PowerPC's are quite out of our reach as far as price, however.

As far as the cost of software - the synthesis tools (ISE webpack) and simple simulation tools (the free ModelSim) are free. However, the EDK - which lets you setup the microprocessor inside the FPGA (includes the logic for the MicroBlaze and the stuff to setup the PowerPC) is expensive ($1000). I think that would be a necessary part of any FPGA system for a robot controller, as writing your autonomous in Verilog or VHDL would just be a pain, not to mention the synthesis time, whereas 64+ megs of DDR memory and plenty of flash memory with an Eclipse SDK and gcc and g++ would be a welcomed change. I've had 20+ min synthesis times on a Virtex 2 Pro project I was working on, which I simply don't think will work for FIRST applications.

[Eldarion]

Originally Posted by BrianBSL

As far as the cost of software - the synthesis tools (ISE webpack) and simple simulation tools (the free ModelSim) are free. However, the EDK - which lets you setup the microprocessor inside the FPGA (includes the logic for the MicroBlaze and the stuff to setup the PowerPC) is expensive ($1000). I think that would be a necessary part of any FPGA system for a robot controller, as writing your autonomous in Verilog or VHDL would just be a pain, not to mention the synthesis time, whereas 64+ megs of DDR memory and plenty of flash memory with an Eclipse SDK and gcc and g++ would be a welcomed change. I've had 20+ min synthesis times on a Virtex 2 Pro project I was working on, which I simply don't think will work for FIRST applications.

I agree with the need for an embedded microcontroller. I wonder if any of the open-source ones listed on this page might do? http://www.opencores.org/browse.cgi/by_category

[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

[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.

[Tom Line]

Wow.

I'm always impressed with the level of technical knowledge that First folks have.

However, I sincerely hope that First does not go in many of the directions you guys are suggesting. Linux operating system? Math coprocessors? Different computer langauge? Multi-threading? What percentage of the world uses Linux? What percentage of the world knows how to deal with all the complicated options you guys are talking about?

Right now we have a very "simplistic" system. One that I would venture to guess that 90% of the teams couldn't get a camera, encoders, or potentiometers running without Kevin Watson's code or the appropriate Easy-C pre-coded libraries.

I've done C-Programming since high school 18 years ago. But holy-moly! I can't think of a single person I know (and I work in a manufacturing environment where I spend millions of dollars a year working with contractors) who has a sufficient level of hardware interface knowledge to be able to code things like interrupts etc. This is pretty specialized stuff folks - and it becomes even more so when you move away from a very common langauge to even more exotic options.

I would be very disappointed if First moved in a direction that basically threw out all the work that has been done to date. Our team would end up back in the stone age - turning PWM's on and off would be pretty much all we could do.