Serial to CAN Gateway in new Black Jaguars?

[Vikesrock]

Originally Posted by dmcguire3006

As far as CAN being a liability because of single point failure (as opposed to independent PWM line), I'm sure that no one has built in redundant motors so the net result on a cable failure would be the same between CAN and PWM.

This depends on what motor is connected to the controller with the failed cable. If a drive motor PWM fails, odds are it's the same, but if a manipulator PWM fails then the robot could still drive with PWM, but with CAN you're dead in the water.

[dlavery]

Originally Posted by dmcguire3006

As far as CAN being a liability because of single point failure (as opposed to independent PWM line), I'm sure that no one has built in redundant motors so the net result on a cable failure would be the same between CAN and PWM.

Actually, there are some very significant differences between the failures. If you lose a PWM cable used in the traditional configuration (and honesty, there are probably very few teams that have NOT had a PWM that came loose or someone forgot to plug back in at one point or another), at most you lose one motor. In almost every case, the robot is still operable, although with reduced functionality. If you lose a CANbus cable, or have a single device at the head end of the bus catastrophically fail, you can lose access to every motor connected to the bus.

The risks associated with these two options are substantially different. Whether the risk profile is a reasonable trade given the benefits that come with the use of a CANbus configuration is something that each team will have to assess for themselves. Based on your tolerance for risk and your ability to take advantage of the added capabilities of CAN, this trade-off may or may not make sense (personally, I think that for most teams it certainly will make sense, and I would expect to see a lot of teams using the CANbus configurations this year - they just need to understand the risks of doing so).

-dave




-

[Kingofl337]

You can also add fault tolerance in you code/wiring, and with the flip of a switch go from CAN to PWM as a fail safe mode.

[Tom Line]

Originally Posted by Kingofl337

You can also add fault tolerance in you code/wiring, and with the flip of a switch go from CAN to PWM as a fail safe mode.

I'm not sure it will be quite that easy - no one except the can-beta teams have played with the CAN code that has been written for this year.

In addition, remember that CAN will not be officially supported (even if it IS legal to use).

[Gdeaver]

I believe that the serial-CAN implementation does not allow on the fly choice of Can or PWM. The PWM cable provides a heart beat since the jags are operating in untrusted mode. Also my understanding is that there is a different C-RIO FPGA image for can vs PWM control. There are some good threads on Chief Delphi and the First Beta forum on the CAN situation. Also, Luminary Micros have documentation that can be downloaded. 1 week to go until the kick off. Much should be reveled then. In the mean time if a team is considering using CAN, do some homework now. If the serial rate is 115k then there could be update rate concerns especially if there are many jags on the bus. It's not the bit rate alone, Have to consider latency issues. I can remember Dave giving a warning about serialized communications last year when the new controller was being speculated on. I would definitely head his warnings. The serial and Ethernet Can solutions both allow experimentation with out the C-RIO and the driver station by directly communicating with a PC. This brings up safety concerns because there is no E-STOP button in the loop. BE SAFE.

[Al Skierkiewicz]

Originally Posted by dmcguire3006

Good thing about CAN is that you can monitor motor voltage and current and hence computing a running energy expenditure tally would be quite simple.
Energy = Power*Time = Voltage*Current*Time

D,
Dave has covered the single point failure response so I won't add to that. Computing energy usage as you suggest may be a little more difficult than you expect. Current spikes and voltage dips occur in short pulses that require frequent monitoring in order to be accurate. To spend a great deal of time gathering data and totaling the same may actually reduce your effectiveness in driving and accomplishing game goals. Should your samples occur at the rising or falling edge of a pulse and you were to calculate energy remaining on such data, you can imagine the result. Dependent on the load, motors draw full stall current each time they start. That current may be sustained over several brush commutations dependent on the motor in use or it may be present for a significant length of time. At any rate, there are other variables that come into play which would interfere with your calculations that are not monitored by the can bus. The most significant in my mind is battery temperature and it's effect on internal battery resistance and output current capability.

[dmcguire3006]

Since the A/d converters for the Voltage & Current sensing are embedded in the MCU, and since they are sampling at 15Ks/s (see data sheet), and hoping that the design engineers applied appropriate lowpass filtering before the A/D converters, I don't thing that the erratic nature of voltage & current will be a significant factor. I did notice that the accuracy of reading voltage is +/-.3V and +/-1A, meaning the accuracy in power measurement in 0.3 Watts, but this should be insignificant given the average power consumption of the robot would be approx 300W.

Another advantage of CAN is this mode (from the Black Jag data sheet):

"Position Control Interface
This set of commands is used to configure and operate the motor controller using position control mode. The motor control position commands consist of enable/disable of position mode, setting the motor position, setting the PID loop control parameters and setting the source for detecting position. Position control is managed through the use of an externally attached optical encoder combined with the motor controller’s encoder inputs or through the use of a potentiometer."

So it looks like the CAN interface can make the CIM (or whatever) motor, attached to an position encoder or potentiometer, operate as is it were a servo: the user can command the angular position and the Jag will close the servo loop to seek to the desired position.

[Al Skierkiewicz]

D,
I was referring to the amount of data that would need to pass through the buss from each controller and the CRio. Those reading this thread should also remember the switching frequency of the controller is 15kHz and is not synchronized with other controllers. Pulses of high current do last considerably less than the rep rate for switching and data samples in some cases. Also designers need to correlate data with discharge rates on the battery. High current demands reduce the capacity of the battery significantly but with the variable nature of a match, one can only guess at the effect on battery life vs. current usage.
I can give you some data on first hand observation over years of play. Some teams will completely drain a battery in a two minute match (2009 excluded). Some teams will draw down the terminal voltage of the battery enough to interrupt voltage supply to the gaming adapter and/or the Crio causing some loss of game play while systems reboot. Some designs are more critical of battery operation and some designs will produce loads in excess of 400 amps in turns on carpet. All designs will draw near max current in a pushing match or when a driver is lodged against the field borders. There exists enough resistance in most designs to discount power readings at the controllers from being used to predict battery life.
And finally, Al's Rule of Thumb for robot design (derived from observation)...If your robot can't play at least two matches on one battery, your mechanical design and/or driver strategy needs some rethinking.

[s1900ahon]

Originally Posted by Gdeaver

Also my understanding is that there is a different C-RIO FPGA image for can vs PWM control.

Same FPGA image. The cRIO FPGA is unaware of CAN.

BE SAFE.

Absolutely.

[Kingofl337]

In C and Java all you need is to kill the Instance of CANJaguar and Construct PWMJaguar. You will also have to let your code know not to use the advanced features in fail safe mode. I will double check with Brad to see if this will work.

Edit: Also on Al's note, I'd go as far to say if you can't run your robot for 4 minutes on a battery it may spell trouble. especially with the MK batteries. If your team grabs a weak battery and your on the edge of power consumption you may find yourself dead on the field at a critical point. It stinks to loose a key match to a weak battery.

[Tom Line]

Originally Posted by Kingofl337

In C and Java all you need is to kill the Instance of CANJaguar and Construct PWMJaguar. You will also have to let your code know not to use the advanced features in fail safe mode. I will double check with Brad to see if this will work.

Edit: Also on Al's note, I'd go as far to say if you can't run your robot for 4 minutes on a battery it may spell trouble. especially with the MK batteries. If your team grabs a weak battery and your on the edge of power consumption you may find yourself dead on the field at a critical point. It stinks to loose a key match to a weak battery.

Regarding the weak battery - it depends.

During overdrive, many teams were pushing the batteries VERY hard. So hard that during the practice matches, they were dieing at the end. This includes a number of top teams. I had the luck to watch the battery voltage on one of the world champion teams during a regional competition, and at the end of the 4 minute period they were in the 6's and 7's voltage wise while trying to hurdle.

I know we would never have made it through 2 matches without performance degragation. We started to lose simultaneous lift + drive ability after 3 minutes. (4 cims + 2 fish running near stall during the lift + turn).

That's why we rank all of our batteries on a battery tester (the one Al recommended I believe) and only use the top ones at regionals.

[dmcguire3006]

This thread has gone incredibly off-topic, which is good because I have learned a lot that would never have occurred to me otherwise (mostly about batteries in competitions). I would like some specific information on battery testers, such as manufacturers and costs. I think qualifying your batteries before a competition is an excellent idea. Does Al still recommend this one:
http://www.westmountainradio.com/CBA_ham.htm

Thanks again for the all of the valuable info.

[Tom Line]

That is the one we bought. It seriously opened some eyes when we used it - batteries that we thought we ok tested horrible, and a battery from 2+ years ago tested as our best !

Very helpful and highly recommended. I never did thank Al for the great recommendation.

[Al Skierkiewicz]

Originally Posted by dmcguire3006

Does Al still recommend this one:
http://www.westmountainradio.com/CBA_ham.htm

Thanks again for the all of the valuable info.

Yes.
West Mountain also sells a higher current device for those who wish to test at really high currents. I would recommend a high current test be carried out only once or twice a season. We also save the battery tests to a file and overlay the battery with a new test next season.

Please remember that even under the best conditions, the manufacturer specs the battery at 400 charge/discharge cycles. I would guess under our use, that is 300 for teams with the two match or better usage and 200 or less for those that drain a battery in one match.

[ajlapp]

Are the CAN connectors on the Jaguars able to pass data through if they have no power. Are they simply unions or is the Jaguar doing something with the info?

From my experience with automotive CAN bus layout, we always have a main trunk with a terminator. Each CAN device then has a direct link to the trunk...nothing is daisy-chained. Would this help eliminate failure concerns, excluding losing the main Black Jaguar or the trunk line?