What Dr Joe Wants for Christmas...

[Dave Flowerday]

Originally Posted by Al Skierkiewicz

A looping serial bus would kill those teams that have trouble with the PWMs now. One wire would kill their whole robot, potentially.

It should be possible to do the "looping" at the RC if that is a concern. Instead of PWMs 1-16 we have now there could just be 16 (or whatever number is reasonable) bus taps. That would allow flexibility to wire either in a daisy-chain or star configuration or a combination of both (as I suspect would be most useful).

Originally Posted by billbo911

There a MANY teams that have difficulty with what FIRST has provided already. Completely changing the design will require some phase in time, maybe in the order of years.

Definitely a concern, but how big of a change would it be, really? I suspect if something like this were attempted, the speed controller by default could be programmed to react basically the same as today's Victors. Thus, the only real change would be in the way they are wired to the RC, but as I said even that could be minimized. This seems potentially much less disruptive than the move from PBASIC to C for the RC (which I thought would really hurt many teams, however it appears the impact was negligible).

[Al Skierkiewicz]

Mostly true, Dave.
There were so many teams with multimotor designs that needed help getting them hooked up correctly during inspections, I was just being lazy for next year. More than one team looped the PWM cables underneath other structures and eventually had them connected back to another output on the RC while the two motors had PWMs connected together. This is one area where we need to _____proof the design of components. I am sure that the IFI guys came across much more than I did.

[Joe Johnson]

Concerning alternatives to CAN:

My experience (limited I know) is that I2C and SPI can work just fine with reasonable jumps to piggy back boards. We may have to slow down the clock speeds, but we are still lightyears ahead of the current situation.

Concerning 1 wire failure vs. the current 16 PWM wires:
I know which failure I would choose. With 1 wire on a serial wire at least you get feedback if a Victor goes dark. There are a lot of times when we don't know if the Victor died, or the PWM cable unplugged or the motor lead came undone. It would be a relatively simple matter to set up a dashboard program tell you "lost Victor N" rather than having to go to each Victor to look for for a solid orange LED. Also, with only one connector to the RC you may actually be able to have a connector housing that ensures good connections and perhaps even a positive locking feature.

As doing absolute position feedback with the back EMF method:
I think that end of travel switches can help calibrate the integration. Also, even without such as sync switch, this is no different then having quardrature decode on our wheels. Without a "zero" point, you can't control to absolute position. While I am on the topic, the folks on Charmed Labs claim that the drift from the integration of velocity to position is on the order of what they see from wheel slip when they use encoders. I don't know if I believe them but at least that is their claim.

As to the speed of the motors that they are controlling:
I am more impressed that they can make it go slow to be honest. From a controls point of view, I think the signal to noise problem is worse making an ungeared or lightly geared motor go slow that going fast. There are limitations to be sure. The limit on the duty cycle of the motor is definitely going to cause problems in some applications as will drift, parameter tuning etc. But on balance, I think that there may be something worth exploring for future FIRST robotic applications.

Good discussion in any case.

Joe J.

[Gdeaver]

Closed loop control systems are wonderful but, they present 2 problems introducing them into the FRC. They add complexity and cost. Remember, these are high school students and they are getting hit hard with allot of advanced concepts. First they have to master the pic IDE and c as it applies to the Pic 18. Then there is the default code and the basic electrical wiring. It's amazing that every year even rookie and bare bones teams get something working as it is now. Not ever team has access to EE's.

Then again there are teams that have students and mentors that are capable of adding closed loop control to the robot. I would be in favor of keeping the base FRC and motors as they are now. RS485 ports could be added to the controller and the rules changed to allow a coprocessor to drive the victors directly. Some basic coprossesor function libraries could be added to simplify and standardize the communications. This could be done with little added cost to the FRC.

This year a magnetic sensor was included in the kit. The year before an Allegro current sensor was included. How much would it cost to integrate the magnetic sensor or an output shaft for an encoder or photo interrupter into this years gear box? It wouldn't take to much time or money to close the loop on what we already have. It could be an out of the crate solution that all teams could use. The down side is that it would introduce interrupt hell in to the default code.