Gryo, Camera, Accelorometer, Ultrasonic, and Gear Tooth Sensors in one program

[EHaskins]

I am considering running a vex or EDU controller to handdle most or all of the sensors on next year's robot and want to have it working on this years robot this summer. What i want to do is have a serial cable runnign between the VEX and FRC controllers that would send all the sensor data mabe ten time a second. Idealy the VEX unit would know what pwm values were being sent to the motors so it would be able to say change the camera values as the robot starts to move. or be able to tell if the accelration is from the motors or if the robot got hit. So is it posibal to run this kind of program on a vex? How hard would it be to run Kevin's serial port code on a vex controller? And, i still don't have any good Gear tooth code.

If anyone has any ideas or suggestions i'd like to hear them.

[jerry w]

you are making things harder by adding another controller.
the FRC controller can handle every sensor mentioned here. our team had several potentiometers in addition to the items in your list. the gear count sensors were the only problem for the FRC controller. i would suggest using a quadrature controller for rolling measurements.
our 2006 team had wiring problems. so not all the sensors were active. but the code was in the controller. we are currently fixing the wiring so as to demonstrate the optimized control.
we would be glad to share our efforts with you.

jerry w

[Matt H.]

I'm not sure if another controller is the way to go. I'm very much in favor of keeping a robot as simple as possible leaving less chance of error. While I believe it would be possible to use a vex controller I'm not sure why you would want to.

[miketwalker]

I'd suggest going with the 2nd-gen EDU bot. That runs the same way as the main controller I believe. The VEX, like everyone else has said, will just be a hassle. However, the EDU bot will handle it just like the FRC one will. However, since it is the older chip, you'll have to just compile the code in the same way you did 2004/2005 controllers. But, in theory once you've developed your code you can just compile it the way we had to this year for the 2006 controller without any issues. Either way you look at it, if they are making changes for 2007 (which if you've been reading the rumors floating around, there's definitly a possibility of this occuring) you may have a total revamp or just a basic "change the compiler" thing like this year. Sticking with the EDU should keep you in the ballpark with your code to easily transfer to whatever they throw at us next year though, definitly more than the VEX. Good luck with it!

[jgannon]

Originally Posted by EHaskins

I am considering running a vex or EDU controller to handdle most or all of the sensors on next year's robot

Out of curiosity, what problem are you trying to solve by adding a second controller to your robot? I have an EDU, a Vex, and a Gumstix in my collection of robot stuff, and I would love to slap one onto my team's robot, but I don't really know why I would. The only justification I could use is if you needed more than 18 I/O lines, or more than six interrupts, but I can't possibly imagine what you would be doing that would necessitate that.

[JamesBrown]

I thought the EDU controller cost too much for this application, does it fit into the rules? I would reccomend a Gumstix, teams in the past have used them to do higher level math so it doesn't slow the controller, you get more for your money this way.

[EricS-Team180]

Based on our past 3 years experience of using interrupt driven events to count shaft encoders for speed and distance, I'd say that a 2nd processor would be useful for off-loading that task from the FRC. Sampling accelerometers also comes to mind... It all comes down to the sensors you plan to use for a particular game, the accuracy you think you need, and the resources you have to pull it off.

...my 2 cents
Eric

[Richard Wallace]

Originally Posted by JamesBrown

I thought the EDU controller cost too much for this application, does it fit into the rules? I would reccomend a Gumstix, teams in the past have used them to do higher level math so it doesn't slow the controller, you get more for your money this way.

Because of its $249 list price on the IFI site, the EDU controller would not have been a legal COTS electronic component under <R49> in the 2006 robot rules:

Originally Posted by <R49>

The total cost of all non-Kit items may not exceed $3,500.00 USD. No individual COTS electronic component shall have a value of over $200.00 USD. ...

A separate controller might be useful -- just be sure your solution will be allowed at robot inspection before you invest a lot of time/money.

Thanks for the tip on Gumstix. These look interesting, and the pricing looks good, too.

[EHaskins]

First the VEX controller is almost the same as an edu controller it runs two 18f8720s and is programmable with mplab and IFI Loader. also the VEX controller is under $200 if bought separately from vexlabs.com.

what i wanted to do is run a second controller that could handle most of the sensor software. Part of the reason i want the sensors on a separate processor is so when IFI does update the robot controller i can leave all the sensor software and just write the new software for the master controller to interpret the serial signal from the VEX/EDU/Gumstix. I have considered the possibility of the master controller to power the VEX off one of the Digital Outputs and have the Main Processor be able to reset the VEX if it stops responding.

Edit: Jerry W if you would be able to e-mail me a copy of that code i would appreciate it. haskinseric@hotmail.com