New R/C Chicken or the Egg

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