Intermittent connection on field only

[techhelpbb]

Originally Posted by Mark McLeod

I think the Victors will survive.
I actually tested this hypothesis a couple of weeks ago and the 40amp breaker on the circuit will trip before the Victor suffers harm.

The order seems to be:

• Jaguars trip first (most sensitive)
• 40 amp breakers trip second

What this means is that swapping the Jag out for Victor will help in marginal cases, but won't do any good if the problem is more than borderline.
Some gear ratios just need to be recalculated.

I generally agree. The risk is not so much the incidental overload, but the cumulative damage. The auto-reset breakers are not very fast and they often finally open the circuit at currents much higher than their ratings. The Victors are well built and we've been using them for years with very low failure rates but I can see how repeatedly banging on those MOSFETs could result in eventual failure.

Gearing and box's were mostly KOP, one issue that could have occured was misalignment under full load, potentially binding a gear. I don't think this was the issue we will test and answer that. We had four jags simultaneously overload at once. Four wheel drive, i think the bot would continue to move even if only 1 motor was active, albeit in a circle. Victors and direct drive might be the solution.

[techhelpbb]

Originally Posted by DMike

Gearing and box's were mostly KOP, one issue that could have occured was misalignment under full load, potentially binding a gear. I don't think this was the issue we will test and answer that. We had four jags simultaneously overload at once. Four wheel drive, i think the bot would continue to move even if only 1 motor was active, albeit in a circle. Victors and direct drive might be the solution.

Can you clarify what you mean by direct drive?

[Al Skierkiewicz]

The Victor FETs are rated at around 40 amps each with three in parallel for each leg of the bridge for about 120 amps. This figure is continuous with peaks above that but must be derated as junction temperature goes up. Remember that neither controller has any heatsink for the power devices. The 40 amp circuit breaker can withstand up to 240 amps for short durations but will likely first trip between 100 and 120 amps. The trip point is reduced for each successive trip as the breaker heats up internally. When the breaker trips repeatedly, it buzzes and gets HOT!
The stated trip for the Jag is greater than 90 amps for just under 1 second, with 100 amps stated as the maximum current through the device. Following an over current trip, the Jag will wait about 3.5 seconds before re-enable. While the series resistance for the FET is lower than the one used in the Jag, there are only two per leg.

[techhelpbb]

Originally Posted by Al Skierkiewicz

The trip point is reduced for each successive trip as the breaker heats up internally. When the breaker trips repeatedly, it buzzes and gets HOT!

I just want to add that this means that it's hard to repeatedly overload the Victor's in a short duration of time when the 40A auto-reset breaker is protecting the circuit because the breaker heating causes them to trip at lower and lower currents.

However, each time you let the breaker cool off you run the risk again that the next overload will get a shot at cumulatively damaging the MOSFETs in the Victors because it's back to 240A max and 100A-120A normally.

The time frame between matches can reach that point. Also if you blow cool air on the breakers you increase the risks of this happening.

[Al Skierkiewicz]

Mike,
How did you couple to the wheels from the KOP transmissions? When you reached trip point were you driving straight or turning? Were you using the standard KOP frame with bolts for wheel axles?

All jags were independently powered from the distribution board, fused at 40 amps and wired with 10ga. Power consumption to each circuit should have been the max of 1 motor. Two front motors were Cim's w/ simbox and KOP gears and sprockets with #35 chain and 8" plaction wheels. Rears were the 16000 rpm AM motor coupled to a AM planetary with the simbox and KOP gears and sprockets, 8" omni wheel #35 chain. We realize there is a difference in RPM between front and back, testing under all foreseeable conditions proved it to be an acceptable setup. Our acid test was a %500 game cycle test at accelerated driving speeds. We are going to set the bot up and load test each circuit under varying conditions, this should provide us with some good data.

[Al Skierkiewicz]

Mike,
I am going to bet that the 8" wheels are really the big effector here. Have you calculated your final gear ratio and motor RPM?

[Alan Anderson]

Originally Posted by Al Skierkiewicz

I am going to bet that the 8" wheels are really the big effector here.

Good point. There's a team at Queen City this weekend having Jaguar cutouts on their drive motors, and they have CIMpleBoxes driving 8" wheels.

[Captaindan]

Team fusion did not change a single thing on their bot since the bayou regional, we went to lonestar unbagged the robot and put it on the field it connected and had no problems the entire regional

[tagayoff]

Originally Posted by stevep001

At 10,000 Lakes, our robot regularly had issues with getting connected to the FMS on-field.

The access point is mounted high in the robot, on Pleiglas at least 2" from any metal. We installed a new Ethernet cable as well. We have the DC-DC converter installed.

The solution that finally worked for us was cycling the power on the access point as we entered the field.

Has anyone had any experience using a shielded Ethernet cable? Was reading a bit about it here: http://www.l-com.com/content/FAQ.aspx?Type=FAQ&ID=4803

At the Central Valley Regional we had connection issues in all the matches except two. After changing all the electrical components and then some on the 9th match we started working but not at first. When our robot was brought onto the field the same connection issues were apparent (no connection dropped packets) Two FTA's went on the field and after they came off we were connected. After the match I asked the FTA what he had done and he said they connected the driver station to the robot when they saw no connectivity and it connected ok through a cable. But when he disconnected the Driver Station the radio would not connect to the field so he powered off the robot to reboot the robot. When it came back up we have connectivity for the entire match. Next match we make sure we do not connect the robot to our driver station by cable or if we do we power the robot off then on and so on our last match we ran again not perfect because of the code we had running but we ran the whole match with few lost packets. My guess is we were actually cycling power to the bridge as we entered the field as you stated above.

[techhelpbb]

I am NYC right not Philly, but students from Team 11 at MAR regional are reporting to me significant connectivity issues.

Apparently they are impacting even our team and we've participated in 3 other events without any issue.

Can someone confirm these reports?

[Deetman]

Originally Posted by techhelpbb

I am NYC right not Philly, but students from Team 11 at MAR regional are reporting to me significant connectivity issues.

Apparently they are impacting even our team and we've participated in 3 other events without any issue.

Can someone confirm these reports?

I can confirm this and they have all seem to have centered around RED Driver Station 1. I know 1712, 11, 25, 1676, and others have all had issues at Red driver station 1 and no others.

1712 has not had ANY connectivity issues in 36 of our 37 matches to date with the only failure today at the MAR championship. Our driver station laptop could not connect to the robot but as soon as we swapped out to the FTA's classmate we had no issue. This of course hurt us in the match as the drivers did not have their normal feedback for shooting but we didn't have any other issues. Returning to the pits we tethered up and had no issues at all with our normal driver station laptop and two different ethernet cords. Unfortunately the pits closed immediately after the award ceremony (huh?) and we were not allowed out to the field to work with the FTA to further troubleshoot/check the problem.

I have noticed a LOT more connectivity issues here at the MAR Championship than I saw at Hatboro-Horsham, Chestnut Hill, and Lenape all with the same MAR field (as far as I know). I'm not ready to rule out that something between our driver station laptop and FMS disagreed but the fact that this has only happened in one match, in one driver station, at one event, and to other teams in the same driver station really makes me wonder.

[techhelpbb]

Thanks I'll forward the observations to them. Team 11 has communicated that this has played a role in costing them 3 losses (when I last look they've lost 4 times...so it's safe to say they aren't over-estimating the impact of this 'phantom' problem). We've sent out the spare 4 slot cRIO FRC2, they are either close to or will have swapped the DC-DC converter for the D-Link AP. They've swapped the AP. They have reflashed the cRIO. They can swap the cRIO. The logs show communication and an 11-12V battery till the communication simply stops. I know for a fact from many test runs that the robot will remain in communication down to just over 9V on that measurment. They are rebooting the entire robot when they load it onto the field as a standard process (this includes the AP and the cRIO).

I've given them some TCP/IP related suggestions to try and now that you tell me this I'm gonna ask them to dump the registry settings on that laptop to get a comparison with one that works.

I don't believe in 'phantom' problems and while I can't say for certain that the problem isn't in that robot extremely little has changed between the MORT district even we hosted and this event. We are not under funded and a bad battery is extremely unlikely because of it. Therefore there's likely something wrong in wireless and if it's going to cost a place in eliminations at a championship I should think it should be a priority to find out what.

It's quite frustrating that we've had no apparent problems up until this point. That we've done basically nothing to the robot to start the problems. That we're not even using any high-bandwidth applications (no sending video) and here we are with problems. The control system on that robot is basically using PWM and if it's not communicating, to put it bluntly, this means that essentially there is no safe design to escape this mess. It's even more frustrating that I pointed out in these forums before these competitions began that we had problems just once before (with last year's robot) like this at a field at a small off-season event and during that time the process for troubleshooting it was hopelessly ineffective because the tools to do the troubleshooting simply do not exist within the context of the FMS.

Having had access to the tools we were offered to do this troubleshooting this year I can say again that the tools we've been offered are clearly hopelessly ineffective. In each case I've seen at the MORT district event and now here the only resolutions have come from trial and error not quantitative measurement. Trial and error means you get to forfit games to test one thing after another and since this seems to mostly effect the actual playing field and not the practice fields you are forfiting games you and your sponsers paid to play to troubleshoot problems you can't replicate on your own.

I'm not sure what frustrates me more. That we can't teach the students through this adversity more about troubleshooting and that technology or that we don't get to compete in the competition.

[rsisk]

Have you swapped the PDB yet? I know at least three teams that swapping the PDB has solved intermittent connection issues. Try to find a non-2012 PDB.