New R/C Chicken or the Egg

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

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

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

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

[Kevin Sevcik]

Originally Posted by 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.

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.

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

[Dung H Cao]

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.

[Dung H Cao]

Originally Posted by Dung H Cao

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.

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.

[Gdeaver]

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.

[Cuog]

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.

[Qbranch]

Originally Posted by Gdeaver

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.

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

[Gdeaver]

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.

[Adam Y.]

Originally Posted by Qbranch

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

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.

[Alan Anderson]

Originally Posted by Adam Y.

In this case I doubt it [using CAN/LIN] 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.

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