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?
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.
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.
Buzz’s dance was not due to FMS. Due to possible programming issue plus the fact that we had to keep safety pins in to keep the feeder up ans therefore within starting envelope. We did not have enough pressure in the system after the last match and refs would not let us power up to recharge.
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?
Team RUSH 27 ran into Smart Dashboard issues at Northern Lights that spammed our cRIO and ran our processing to over 100%. Blame was originally on 7Mbps but after further investigation, NI advisors suggested it may be an issue with the smart dashboard itself. This caused major issues that hindered our robot for 3 matches. Any other issues similar?
They were simply failing batteries/cells that managed to emerge at the worst possible time. You can be sure we are taking measures to ensure that does not happen again.
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.
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.
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.
If you roll your jaguar back to the factory firmware (available at the bottom of VEX’s product page), the “trusted mode” heartbeat isn’t required. Last I heard, the trusted mode stuff isn’t documented to prevent people from replicating it (the code is in the closed-source NetworkCommunication library. Security though obscurity I guess). AFAIK, the factory firmware is functionally identical to the FRC one, minus the heartbeat.
You can also find the source code for a slightly older version of both the factory firmware and bdc-comm in TI’s RDK-BDC24 package. I have no idea whether VEX plans on making a similar release with the newest code.
Wow, that is an absolutely brilliant idea I think that our electronics guys would probably be interested in trying something like this out at some point. It also give me something to do with all the ancient computers with serial ports I have floating around my house.
We use c++.
You can turn those ancient computers with serial ports into test equipment, like for example a poor-man’s logic analyzer to inspect the timing of digital signals like encoder pulses. Or DIO set by tasks to inspect scheduling timing and jitter.
You can turn those ancient computers with serial ports into test equipment, like for example a poor-man’s logic analyzer to inspect the timing of digital signals like encoder pulses. Or DIO set by tasks to inspect scheduling timing and jitter.
I recently turned an old PCI-X sound card I had in an old gateway into a low-voltage oscilloscope and it happens to have a built in mic input and radio antenna so I can analyze radio and sound frequency as well (if I ever have the time to really muck around with it). I have never actually used a serial port for anything so my lack of familiarity could be a bit of a hindrance as far as creating makeshift equipment is concerned, but maybe over the summer…
In the two regionals I’ve attended so far, I have only ever seen one robot lose comms. I didn’t watch every match, but it’s been one of the best years for this sort of thing since 2009 in my experience.
624 was having comms problems at Lone Star, but they definitively tied it to a radio reboot under heavy current draw. Unfortunately, they’ve swapped out everything, sometimes twice, in their attempts to fix it. I know they were fine in their last quals match, but I don’t know if that stayed that way during the elims.
Borrow Jan Axelson’s book Serial Port Complete at your local library. It will get you up and going in no time.
If your local library does not have it, use inter-library loan to get it.
Or buy it.
The demo code and code examples downloadable here show how to read and write some of the RS232 control pins, and how to read the Pentium’s RDTSC 64-bit nanosecond timer.