New R/C Chicken or the Egg

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

[Tom Bottiglieri]

Originally Posted by Gdeaver

Did a high school student write that code?

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.

[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

[Gdeaver]

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.

[Mark Pierce]

Originally Posted by Gdeaver

From the few who responded, I take it that a full blown serialized system is not wanted.

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.

[Kingofl337]

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.

[Qbranch]

Originally Posted by Kingofl337

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.

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

-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?

[dragoonex]

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.