New Robot Control System!

[mathking]

Originally Posted by Eldarion

The fewer layers of abstraction, the faster the program will run, with assembly language being the fastest. However, this speed increase is offset by increased development time. I believe a good compromise is reached in the C programming language, as do many other robot programmers!

Assembly is only faster if you write good assembly code, and you are smarter than the writer(s) of the compiler. A good compiler with a lot of optimization can take high level language code create object code which runs faster than most of the code student programmers could write in assembly. One reason C became the language of choice for embedded chips was the creation of specific compilers which allowed for small, fast code.

[Eldarion]

Originally Posted by mathking

Assembly is only faster if you write good assembly code, and you are smarter than the writer(s) of the compiler. A good compiler with a lot of optimization can take high level language code create object code which runs faster than most of the code student programmers could write in assembly. One reason C became the language of choice for embedded chips was the creation of specific compilers which allowed for small, fast code.

In my post I should have stated that I was referring to the old assembly gurus who could code circles around the C compilers. I would not expect students to be able to code to that level (I cant either! )

[Bharat Nain]

I have been thinking about this and if FIRST was not going to use the IFI processor, here is what I would do if I were FIRST:

1) Research the different ready-made processors available in the market.
2) Pick out everything that is decent and buy them
3) Vigorously test each processor in conditions that real competition would require
4) Research the company and determine if it is a work-able partnership.
5) Work out details with the partnering company to provide adequate supply and support for all FIRST teams.

There are a lot of other things to figure out such as speed controllers, spikes etc.

So, even though we have all our wishes of the type of processor and its features, I am sure FIRST is researching this in a planned manner and will determine what is best for our applications. We might not get what we expect or like, but hopefully it is what is best for us.

[Storcky]

Originally Posted by Tom Line

Visual Basic and C are basic languages that most schools will teach (if they teach anything). Going too far afield with the language (C# or C++ comes to mind) will force quite a few folks to have to try and learn a new langauge. I don't think that would be in the best interest of the competition.

Our school only teaches Java (for the AP test). I had to learn C on the fly with our programming mentor.

[tjcasser]

Originally Posted by ThomasP

They have a .NET Compact Framework, Java Micro Edition, etc... with more processing power and memory, the new RC could easily run one of the newer languages just as fast as the current RC runs C and then it will only get faster from there.

Just let me recap something I mentioned earlier in this thread, IIRC.

Having played with robots programed in Java last week, I can tell you that Java ME does work rather well when it comes to developing software for small, power constrained devices. (You actually use the same interfaces that you use for writing programs that run on a Java-enabled cellphone.) .Net CF has a slightly larger footprint, but it too likely could handle the processors that I imagine FIRST is looking at using in the post-2008 era.

When they say 'support for multiple languages', that smacks to me of a device that's capable of running an operating system in some fashion, rather than just a simple processor... so it's back to the whole wait-and-see...

[mathking]

Originally Posted by tjcasser

When they say 'support for multiple languages', that smacks to me of a device that's capable of running an operating system in some fashion, rather than just a simple processor... so it's back to the whole wait-and-see...

I have been talking with some of our other mentors about this. I think that some sort of OS is the most likely alternative. The other possibility we see is a development environment which allows code from different languages to be compiled to processor readable object code.

I will also second the notion that Java has a number of features that do lend themselves to robot programming. In particular Java handles events and exceptions well. Just as a simple example, I made some code for the InteliBrain robot from Ridgesoft that uses the CMU cam and can find the FRC game light and move the robot to within 5 feet of it very quickly. If the Java code is used with an IDE that compiles the code efficiently, it will not be anything like Java byte codes. Something like xCode perhaps.

[Steve W]

Originally Posted by Covey41

This topic is less than 3 hours old and the Chief Delphi community is complianing already:

Let's not forget the 2007 radios! (No cell phones near the radio towers.)

I don't care who designed it, or who makes it, NO ONE makes anything perfect the first time, or for that matter everytime.

Lets disprove a new saying overherd at the VIP reception in Atlanta:
"FIRST - Technolgy building egos"

The process just started, give them a chance!

Gary F, the issue is that FIRST does not give us good products to start with. Such a major change is questionable. What is more questionable is what is not said. FIRST did not say tha "FIRST and ***** are designing a new controller" They did say that they are building a new controller, quote "We are pleased to announce we have begun development on a new Robot Control System". No other people mentioned. FIRST has told us many times that they are short staffed and how stretched they are. I question their ability to do justice to a new controller in such a short time frame. We do not need any more fiascoes!

I find it surprising that IFI did not make the announcement if they were the ones working on it. IFI has been the strongest point with FIRST suppliers. No one else has stepped up and made things run as well as IFI. I would hate to see them go.

One question that I do have, why are you quickly jumping on us for discussing? Are you involved with the new product?

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

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

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