THE HORROR! THE HORROR!

[Gregor]

Originally Posted by thinker&planner

We had to reduce the resolution of our camera because the control system was delaying so much that we accidentally fell over.

What?!?!

[Jared Russell]

Originally Posted by Kevin Sevcik

I'm told many problems at Lone Star were caused by multiple teams trying to run cameras at 640x480 at 30fps. Or in one case, TWO cameras at that rate. Teams have been instructed to throttle down to 320x240 @ 15fps and things have calmed down a good bit.

I thought bandwidth caps were in place...?

[Kevin Sevcik]

Originally Posted by Jared341

I thought bandwidth caps were in place...?

I can only tell you what the FTA mentioned to me in passing. I'll note that he didn't say and I didn't say that the cameras were causing issues for teams other than the ones running the cameras.

[Nuttyman54]

Originally Posted by Jared341

I thought bandwidth caps were in place...?

Based on reports from this thread and others, it seems that the bandwidth limits are either not in place or not working, at least not at all events. It also seems that the Quality of Service packet prioritization is not working properly either. Several people have reported needing to turn off or turn down camera resolutions to resolve lag and loss of comms issues not only for their robot but for others in the same match.

I was not at any of these events nor do I know anyone personally who has reported these symptoms, so it's second hand information at best. The fact remains that turning camera feedback to the driverstation down or off seems to have resolved many of the issues at events. Hopefully FIRST will address this in some regard in an update or blog post soon.

[mtaman02]

Originally Posted by Kevin Sevcik

I'm told many problems at Lone Star were caused by multiple teams trying to run cameras at 640x480 at 30fps. Or in one case, TWO cameras at that rate. Teams have been instructed to throttle down to 320x240 @ 15fps and things have calmed down a good bit.

^^^
Had the same issues with the NYC Regional with the cameras. Once we tamed the settings the field ran the way it did the previous 2.5 days before. Also had to look for a couple of other things that tied up the comm bands.


I don't believe there will EVER be a comm problem free season. Thats the nature of technology. The field and FMS always gets heavily looked at both locally and through a remote connection whenever a field allegedly has issues. Nothing is fool proof - all that can happen is that it improves a little with each passing day.

[Jefferson]

Originally Posted by Kusha

What language did you guys program in? (Curious)

We use c++.

[Alpha Beta]

Originally Posted by animenerdjohn

A few times titanium was spinning in auto in Elims as well...

From what I've seen this is sort of a popular failure...why I wonder do all the robots react like that?

Our spinning was due to a failed battery. We had 2 separate instances in elims where batteries showed 13 volts on the charger and dropped to 6 volts within seconds during autonomous.

To the best of my knowledge we had no problems with the FMS in Hub City.

[Team23pitboss]

batteries showed 13 volts on the charger and dropped to 6 volts within seconds during autonomous.

Out of curiosity did you ever figure out why the batteries behaved in such a strange way?

[Tom Line]

Originally Posted by Team23pitboss

Out of curiosity did you ever figure out why the batteries behaved in such a strange way?

This is almost always a failed cell in the battery - or many failed cells.

We use the West Mountain battery tester to test our batteries. We found several this year that had normal voltages initially, checked good on our battery beak, but fell off after 5-10 minutes of testing fairly sharply.

[Kevin Sevcik]

Originally Posted by Tom Line

This is almost always a failed cell in the battery - or many failed cells.

We use the West Mountain battery tester to test our batteries. We found several this year that had normal voltages initially, checked good on our battery beak, but fell off after 5-10 minutes of testing fairly sharply.

On the one hand I want one of these. On the other hand I don't want to spend the money. Maybe I'll spend some time this offseason working out some software to use a Black Jaguar and some power resistors as a poor man's version of this.

[Ether]

Originally Posted by Kevin Sevcik

Maybe I'll spend some time this offseason working out some software to use a Black Jaguar and some power resistors as a poor man's version of this.

Hmm. You've got me curious. Can you give a general idea of what you have in mind? Is the purpose of the Jag to allow you to record data (via CAN) and shut off automatically so you don't have to babysit it?

[Kevin Sevcik]

Originally Posted by Ether

Hmm. You've got me curious. Can you give a general idea of what you have in mind? Is the purpose of the Jag to allow you to record data (via CAN) and shut off automatically so you don't have to babysit it?

Black Jags are serial controllable and have current control modes plus built voltage and current feedback. So all you would need for a battery tester is a serial port (or USB-Serial adapter), a serial to Jaguar adapter, a Black Jaguar that most every FRC team has 1 of, and a power resistor you can get at Mouser or your local electronics surplus store. Battery on the input side, power resistor on the output side, tell the Jag to dump X amps into the resistor, then record and plot your feedback. Primary difficulty is making the program to control the Jaguar. Either I'd need to figure out how to generate the FRC heartbeat, or you'd have to flash the Jag with custom firmware.

[Alan Anderson]

I remember one work session where a robot decided to "spin out" as soon as it was enabled. It did not respond to any control inputs. The cause turned out to be a disconnected gamepad. Pressing F1 on the Driver Station brought things back to normal.

[Ether]

Originally Posted by Kevin Sevcik

I'd need to figure out how to generate the FRC heartbeat.

Is that documented somewhere, or would you have to put a sniffer on the line to analyze the traffic?

[Kevin Sevcik]

Originally Posted by Ether

Is that documented somewhere, or would you have to put a sniffer on the line to analyze the traffic?

I have no idea. I've put zero effort into the project at the moment. I've run serial sniffers before for various work projects, so I have a reasonable idea how to go about it. I'm hoping it's actually just documented somewhere, though.