New R/C Chicken or the Egg
 

There has been some discussion concerning the new First control system. recently there was the survey and Kevin Watson's post about a Linux R/C.
Question, Do you pick the programming environment and then choose the hardware to fit the programming environment or do you design a hardware platform and choose the programming environment to fit the hardware? To me this seams like the chicken or the egg problem. I expected to see posts debating the architecture or form of the new controller. Instead the focus has been on Linux, RTOS, .net, windows CE, plain old C, etc.. There has been no discussion of the control paradigm.

Maybe we should forget the software, step back and think about how we want to control our robots 5 years from now and what kind of games our robot will be playing. Do we want more autonomous play? Do we want more human remote control type games. Personally, I always thought robotics was about removing the human from the loop.

I think the first choice to be made for the new control system is do we go to a distributed serialized control with intelligent peripherals or keep all the processing in the controller and stay with cheap dumb peripherals. First could stay with a system like we have now and just go to a more powerful processor. Or, go to a distributed intelligent serialized control. Think of todays modern cars. The wind shied wiper is a intelligent peripheral. There are intelligent door modules, lighting modules, electronic steering Modules, dash board modules, cooling Modules, hvac Modules, etc all connected by a buss (usually can or lin or combo). Look at the ST micro automotive site for an example of of what i"m talking about. Cars are 12 volt robots, we can borrow allot from their systems. Think of the pneumatics system as it is now. If you wanted to have 8 dual solenoid controlled cylinders, think of the mess you would have with all the spikes and single solenoids. We could have a pneumatic Module. Have a serial buss connected pic controlling a intelligent high side switch for the compressor, the pressure switch connects to this pic and 4 quad intelligent high side switch chips drive the solenoid coils. The pic is sent commands over a serial buss to control the solenoids. From a software perspective the pneumatic subsystem is an object with properties and methods. Add a manifold for the solenoids and the pneumatics are now a smaller neater subsystem more easily removed or added to the robot. In a serialized system the victors have to get smart. That means they would also take serial commands and effect the commanded actions and also would have feed back. There would still be a master RC handling the supervisor, safety and communications routines. The big question is where to put the master control program (user routine). In a laptop at the player stations or in the master RC on the robot. To me this is the first choice to be made. Stay with or current system and make it more powerful or serialize it. Comments?

Re: New R/C Chicken or the Egg
 

While it's definitely an interesting concept and would probably be more extensible than a centralized controller, it suffers from one major flaw. Almost everything we interface with the system would need to be custom-designed for FRC. I'm pretty sure any currently existing intelligent peripherals out there are going to be a hodge-podge of interface standards specific to their industry. So we face the daunting task of having to specifcy an interface standard for all of our devices and then start designing all the devices themselves, and then paying for our new incompatible-with-the-world solenoid valves to be manufactured and.... Well... I think there's a reason this paradigm is more commonly seen on cars. I don't think FIRST is big enough to handle the extra costs this would entail without ruining the extensibility by designing to 4-5 industry standards and ending up with a port for pneumatics, a port for victors, a port for spikes, and basically a port for each individual subsystem and look out if one of those ever changes.

Re: New R/C Chicken or the Egg
 

One minor change that I think would help the peripheral issue would be the addition of an I2C or SPI interface. You can get almost any kind of sensor for I2C, and the bus can support many, many devices at once.

Just my $0.02. :)

Re: New R/C Chicken or the Egg
 

I would vote for having an I2C/SPI interface, or two, available
on the robot controller.

If we get a "real OS" for our robot controller, I have a question.
Will a LCD display be included to display the rotating beachball?

Eugene

Re: New R/C Chicken or the Egg
 

I'm not exactly sure what you're saying in some parts, but I think I have it right...

This would involve having entirely new solenoids, relays, speed controllers, etc... being manufactured, wouldn't it?

All of those are currently Off the shelf, and usually from a manufacturer that makes their money outside of FIRST. To have someone produce all these new, and rather unmarketable products seems a little much.

I know someone will have the make the controller anyway, but making the controller vs. an entire custom control line not marketable outside of FIRST is kind of different.

Please correct me if I'm wrong however, my reply was based entirely on my interpretation of your post.

EDIT: I think Kevin and I are making the same point.

Re: New R/C Chicken or the Egg
 

In the real world, most people choose a programming environment in which they are comfortable, and then select hardware to meet the requirements. Only if the hardware is lacking do we decide to adopt (resign to live with?) a new programming environment, and then the selection process gets reversed (hardware first then tools).

My 2 cents

Don

Re: New R/C Chicken or the Egg
 

I don't think I made my point very well. The problem with the current RC is that it controls everything. Say your 2010 robot needs to have 6 victors and 6 motors. On 4 motors you want to have velocity and acceleration control all independent of each other. The motors - trans are coupled to encoders. The other 2 motors - trans need to control positioning and are coupled to potentiometers. The robot controller as it is now has a problem. There are not enough counters to handle the encoders. Even if you add external circuits to cut down on the number of counters the interrupt processing time increases. Each PID control loop takes time. Add to that the ADC time and other processing time, the controller is loaded up and the program is complex. The victors already have a pic in them. Now it times the hobby style PWM signal from the controller and turns the H bridge Fets on and off to control the current. In a serialized system, we would send a command to the speed controller over a communication buss. The victor PIC chip would then control the H bridge to effect that command. The encoder is connected to the victor PIC and the PID runs on the victor PIC. This can now be a 2 way system. We can ask the victor what the current draw is, whats the velocity, how many encoder ticks has it measured, is there a fault condition, etc. Basically we have added a co processor. This is a link to an implementation of this.
http://www.pololu.com/products/pololu/0425/
If we go to this type off controller then the new RC will have to have many serial busses. I2c, SPI, and RS485 or can or something.
This link might also be helpful to see what I'm talking about.
http://www.roboticsconnection.com/pc...ontroller.aspx
The development of this type of controll can be very complex and time consuming. The pay off is the ability to encapsulate the complexity and communications. Programming actions can be very simple. I program these type of systems all the time. I do not write or compile any code. I just whip out my trusty index finger and go down a menu specifying actions and parameters.

Re: New R/C Chicken or the Egg
 

I think it would be cool if you could daisy chain the speed controllers and each one would just have an address like 0x00, 0x01, 0x02.. etc. But as mentioned this basically makes the speed controllers FIRST specific or at least not as easily interfaced as they are currently

Re: New R/C Chicken or the Egg
 

Well, and then you'd have a requirement for people to learn I2C or SPI or CAN or MODBUS or something to run the victors...

-q

Re: New R/C Chicken or the Egg
 

The comunications can be encapsulated by a high level launguage . There would be no reason to write to the spi port directly unless you were adding code for a unsupported device. On todays controller if you want serial ttl control you have to write to the pic hardware. Kevin Watson did this for us with his driver code.

Re: New R/C Chicken or the Egg
 

Perhaps you did make your point well, but nobody responded to it the way you expected because your point does not reflect the reality of the controller. I've successfully had the RC reading four quadrature encoders simultaneously, and I could have added two more if necessary, without using external hardware. The number of potentiometers is simply not important, as long as you don't exceed the number of analog inputs on the PIC.

Complexity is not a major issue if all you're doing is duplicating existing components. That's what happens when you add more encoders or more PID-controlled motors. If you're programming your PID control well, all the "loops" take place at the same time, and the only thing to worry about is how much of that time is left to do other tasks. I've done a little measurement of PID processing time, and it's not a problem with the current RC -- I believe it could handle as many separate PIDs as there are PWM outputs without getting anywhere close to running out of CPU cycles. The ADC time is already a non-issue if you set it up to do measurements in the background. I agree that you do have to watch out for interrupt service saturation, but choosing appropriate encoders will take care of almost all of that.

Re: New R/C Chicken or the Egg
 

Yes, fiinnaly someone is starting to debate the platform advantages and dis advantages. Did a high school student write that code?

Re: New R/C Chicken or the Egg
 

If you're talking about using four encoders and three potentiometers simultaneously, the answer is no, a high school student did not write that code. Kevin Watson wrote it, carefully documented it, and made it available for everyone to use. A student/mentor team merely integrated Kevin's code into the program.

Re: New R/C Chicken or the Egg
 

As Alan has suggested, I think we understand the point rather well. The issue is that you're asking to move from developing and debugging a single powerful general purpose RC to developing a powerful RC as well as several powerful peripherals to accompany it. My best guess at the moment is that you'd need to design a new H-bridge motor driver, a new solid state relay, new servos, and new solenoid valves, since you mentioned. Not to mention new sensors and such.

If you'd like to beg off completely redesigning hobby servos, then the controller should still have some hobby PWM outputs on it. And we'd still need general purpose digital IOs. And I'd think some analog inputs would still be good just so we don't have to make up an SPI A/D interface when we want to sense something that might not be controlling a motor. In fact, I think that leaves us with our current RC, plus robust serial comm options. Which everyone is clamoring for anyways. The only difference would be that forcing an immediate move to decentralized serial control would push all the development effort right to the front when we could develop these peripherals one at a time as we thought we needed them.

However, I've got a much better and more practical reason that FIRST isn't likely to make this move any time soon. They need the entire robot to shutdown at a moment's notice at match end or transitions. With hobby style controllers, they do that just fine if they don't get a signal. With serial devices, you'd either need a foolproof shutdown sequence in the RC, or you'd need to send a heartbeat or command to all of the devices at regular intervals or some other expensive solution.

Don't get me wrong, the independent peripheral solution is very powerful and useful in lots of situations. I just don't think FRC is one of them.

Re: New R/C Chicken or the Egg
 

A more powerful RC can be developed independently of the way we communicate with peripherals. Yes, an I2C or other bus would be a handy option, but one cannot and should not discount the advantages of all that R/C PWM-driven COTS stuff out there - specifically that it exists and is easy to use.

I agree with the implication that a system the average HS student cannot use isn't meeting the purpose of FIRST, but I also assert that a powerful system need not be too complicated to use.

I always compare our robots to those in the DARPA challenge, and find that the only significant difference is processing power. IMAGINE a robot that does the whole match autonomously, and actually plays well.... IMHO it is just a programming problem, the technology is there.

Don

Re: New R/C Chicken or the Egg
 

From the few who responded, I take it that a full blown serialized system is not wanted. The more I think about it the cost and amount of resources it would take to develop the system all at once in the time frame First has committed to would not be a good idea. However, I believe this is the future judging by the products being brought to market in the industrial process, automotive, and automated building markets. I strongly hope the designers do not boxes us in for the future by ignoring serial communications ability. I'd like to see a SPI port and an I2C port. RS 232 and RS485 support also apply to many devices. The can and other busses are a little more complicated to provide for. If the designers leave the controller extensible, there is the option for change. we will not see the controller till 09 and a 4 or five year life would be nice. Things are changing fast. What may seam over kill and not applicable to FIRST now may be very desirable in a couple years.

To scale it down a little, what could you do with these servos on a vex platform that you can't do with the VEX servos and hobby PWM.
http://www.crustcrawler.com/motors/A...ex.php?prod=63

In 2007 our team first loaded our code into the bot on ship day as we were fixing the crate. We finished building the robot on Thursday and spent half the matches Friday debugging everything. Still I'm very proud of our team. We built a robot under less than desirable circumstances and competed. If anything I posted lead to a more complicated system, I think my team would string me up. Easy-C is nice.

Re: New R/C Chicken or the Egg
 

I'm not really sure how that adds to the discussion. I would say as long as the students are motivated and interested in learning, it is irrelevant who actually wrote the code.

Re: New R/C Chicken or the Egg
 

I guess in today's headline news culture you can be excused for being impatient. But we all have job or school responsibilities, it is only pre-season, and some of us want to consider our answers before responding. In two days you've gotten some very good responses. I think this topic deserves some patience and might continue to generate some positive ideas.

I like the direction of the discussion - looking forward and keeping options open. I like the idea of digital control of servo controllers, remote I/O, and the opportunity to improve wire management that this presents. I've seen many teams have a disappointing match or demonstration because a PWM style or other connection came disconnected or was not fully inserted in the heat of pit repairs. I'd love to see locking connectors, but handling the I/O we've come to enjoy and squeezing decent connections on a central controller will definitely be a challenge.

How about starting with a main controller with improved capabilities and some I/O. In year one use one or two styles of I/O modules that handle relays, limit switches, or speed controls operating on a serial bus. Over the next few years introduce additional or improved modules to add to the bus. I don't think that custom boards are out of the question given the size of FRC and chip level support for serial communication standards. As already mentioned, there are a variety of standard buses that could handle this. Whether it's the automotive LIN bus, one of the industrial control networks, or something from the consumer electronics area there are lots of choices.

Lets continue this discussion and figure out if such a scheme would work or what type of system we'd like to have.

Re: New R/C Chicken or the Egg
 

As far as I'm concerned take the current system, upgrade the CPU to something with a little more performance, and bring out I2C / SPI and call it a day.

Re: New R/C Chicken or the Egg
 

I think for all intents and purposes, one controller is enough and can easily handle all the requirements of any FIRST challenge. I think integrating I2C or SPI into the controller would be too much work with no real advantage in FIRST's context. What I would like to see is peripheral self identification. This would be a great advantage to have because then the controller could remap outputs depending on the peripheral. This is great way to teach new students the different parts of the control system, and let them play around with things without doing any programming. Not only does it help teach, but it also mitigates those "I plugged the victor into the wrong PWM output" problems.

Re: New R/C Chicken or the Egg
 

I have to respectfully disagree. Providing easy to use, hardware supported, industry standard peripheral interfaces would be both simple and highly useful. There's tons of useful chips available with serial interfaces. Accelerometers, gyroscopes, digital compasses... Heck, you can get quadrature encoder counters with SPI interfaces. Wouldn't you like to use a ton of encoders without having to worry about interrupting on every encoder pulse?

While peripheral self identification would certainly be very useful, I think it would arguably take much more work to implement, what with needing to change and redesign all our peripherals to make it work.

Re: New R/C Chicken or the Egg
 

Yep. I can go for that too. CAN/FlexRay might be nice sometime in the future, but nowhere near the present. Another cool add in would be the addition of a flash memory chip on board... anymore, dropping 8MB or more of flash memory on a board isn't all that expensive... imagine being able to log an entire match's data for analysis.

Just like how Microchip got the finest in 8bit processors for this revision of the controller, perhaps IFI can upgrade to the finest in 16bit... maybe a PIC24HJ256GP610... *drool*..... :o

-q

Or... maybe the dsPIC33FJ256MC710 which has 32 bit timers... and 24 bit wide instructions... and hardware DMA access... plus with the right clock into your 32 bit timers you can get into the range of being able to measure time-of-flight for light... LIDAR anyone? :D

Re: New R/C Chicken or the Egg
 

BREAKING NEWS!!!

Today at Kettering Kick-Off competition's LabView workshop, an un-official revelation was announced to all workshop attendees that the new FRC controller will be the NI CompactRIO platform (http://www.ni.com/pac/crio.htm) and programming will be via LabView.

The official announcement should be out in about two weeks. Details are being developed for training and support for FIRST teams.

Re: New R/C Chicken or the Egg
 

Sorry for the mis-information about the controls systems. National Instrument is only growing its partnership with FIRST. I mistook it for more than the info given and took a best guess at the future.

Re: New R/C Chicken or the Egg
 

Well, That software-hardware combo would have made the chicken or the egg problem moot. It certainly would have left the system extensible and would have given the hard core mentors something to chew on. The drag, drop, wire and specifying parameter visual programming capabilities makes the MSRS VPL look kind of beta-ish. Factor in the cost and well. It's nice to dream.

As to the reason of my original post and hint a serialization, look at this link for a example of why extensibility in the new controller is important.
http://www.allelectronics.com/cgi-bi...OF_MOTOR_.html
This surplus motor is an example of what will be available in the future. Right now we can not access the power that is on that circuit board. If one new the buss and command structure, I bet one could do allot of neat things with that item. First has tapped the automotive industry for allot of our stuff. Van door motors, window motors, the cim. More and more of the Automotive mechanicals are becoming intelligent subsystems. We should be ready to tap their mass market design and production capabilities. ECM motors are the future. More and more automotive systems will be using them. With the recent release of several driver chips the cost is going down. We should be ready to tap these products in the future.

Re: New R/C Chicken or the Egg
 

While lots of serial interfacing for the motor controllers etc would be nice I don't really see it being very necessary. Yes it would be cool and perhaps have it as an option for easily adding sensors for input, but I still like the ease of use of having standard PWM outs with analog and digital inputs.

The things that I would want to see that aren't in the system now I will list in order of (as I see it) importance.

1) Programming interface: most of us use laptop and they are getting harder to find with serial ports. USB, flash memory, or even network programming connections would be preferable.

2) Raw speed: a few hundred MHz would be very nice and I see few teams that would come near maxing out the general processing power of something like an ARM9(just an example) also having a decent amount of RAM would be nice too.

3) Easily written and read memory: the ability to store and read logs from a flash drive. The idea of having an autonomous script written in .txt and readable from the flash drive then easily swapped for another drive sounds like a very nice option.

4) The pins. maybe .01 of an inch more space between them, I have no problems with the 3 pin interface although some extra space so that pulling one out doesn't pull out another, and maybe a locking mechanism as well would be nice.

5) Onboard Serial. I like the ability to connect serial devices to the RC such as vision systems or even an LCD printout screen(I'm sure there are many other useful devices we could use as well. What I'm trying to say is I like having 2 user accessible serial ports onboard.

6) Potentially USB for storage/transfer of code or just expanded flash memory.

Re: New R/C Chicken or the Egg
 

What is this thing, CAN? LIN? I'm guessing it is since your talking automotive specs... I agree it would be really cool to have CAN/LIN/FlexRay on board... CAN and LIN are both affoardable hardware wise too.

-q

Re: New R/C Chicken or the Egg
 

The problem with the motor I referenced is that there is no documentation for it. Being that it is a low priority device on a vehicle, I would think it might be LIN. Most CAN devices are of a higher priority.

Re: New R/C Chicken or the Egg
 

In this case I doubt it would be cheaper than the Victors we are using now. You need a microcontroller to be a man in the middle which means more code that needs to be created and maintained.

Re: New R/C Chicken or the Egg
 

The Victor has a microcontroller with code, so that's not a significant issue.