New R/C Chicken or the Egg

[Gdeaver]

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?

[Kevin Sevcik]

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.

[Eldarion]

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.

[eugenebrooks]

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

[AdamHeard]

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.

[DonRotolo]

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

[Gdeaver]

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.

[bear24rw]

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

[Qbranch]

Originally Posted by bear24rw

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

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

[Gdeaver]

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.

[Alan Anderson]

Originally Posted by Gdeaver

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.

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.

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.

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.

[Gdeaver]

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

[Alan Anderson]

Originally Posted by Gdeaver

Did a high school student write that code?

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.

[Kevin Sevcik]

Originally Posted by Gdeaver

I don't think I made my point very well.

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.

[DonRotolo]

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