Re: New Robot Control System!
 

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.

Re: New Robot Control System!
 

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

Re: New Robot Control System!
 

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... :ahh:

-q

Re: New Robot Control System!
 

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.

Re: New Robot Control System!
 

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

Re: New Robot Control System!
 

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! :ahh:

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

Re: New Robot Control System!
 

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.

Re: New Robot Control System!
 

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.

Re: New Robot Control System!
 

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.

Re: New Robot Control System!
 

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.

Re: New Robot Control System!
 

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

Re: New Robot Control System!
 

Ditto. Team 1024's programming group calls ours RALFF... even has a (slightly unstable :o ) 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... :rolleyes:

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

Re: New Robot Control System!
 

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?

Re: New Robot Control System!
 

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.

Re: New Robot Control System!
 

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.