When l turn on almost all the motors on our robot, with a full-charged battery, l find that our robot can easily lose communication. l also find that when l turn on the two falcon on shooter at around 2000 rpm (this is an arbitrary “big” value), then my robot will sometimes drop off communication. l didn’t do any further to test in which situation will the robot lose communication. And l didn’t customize the can utilization in my code.
Can anyone give some suggestions on this strange problem? Thanks!
Possibly vibration if it isn’t power. How are you powering your radio. The barrel jack is notorious for coming out, you can hot glue it in. IF not using the rev RPM you can double power it with a poe cable and the barrel port.
IF it is draw how do your power usage graphs look in the DS logs right before it goes offline?
it is EXTREMELY unlikely this is your issue unless you are driving the bot into a wall or having high speed impacts with another robot in exactly the wrong angle . i recommend you do not disassemble your radio unless you are sure you will not damage or disconnect the antenna
Watch the radio lights when this happens to see if the radio is power cycling.
You can see the boot sequence to expect when you first turn on your robot.
You can also use your Driver Station logs to identify how long the radio communications took to return after a communications drop and it will tell you for sure that the radio power dropped (about 45 seconds on average).
The Driver Station log may also identify something else as the culprit, e.g., a ~30 sec recovery would point towards the roboRIO rebooting, a ~15 recovery might be a network switch mounted on the robot.
Coming from the electrical side, check that ALL of your electrical connections are tight. A bad electrical connection can cause a large voltage drop when pulling higher currents like when you run your shooter.
Using just two fingers, if you can rotate any of the cables on the battery terminals, the main breaker or the PDP/PDH, they need to be tightened until the cannot be rotated.
Perform a gentle pull-test on each end of every individual wire.
Notwithstanding the official advice, my understanding is that when you double-power the radio like this, only one will be used at a time. If the primary power fails, it will switch to secondary power, but there will be an interruption. For debugging purposes, you might want to try with only one power supply at a time; that will make power problems more obvious.
Is it possible for you to post pictures of your radio wiring (both ends)?
This may well cause a power spike, a voltage drop, and a robotRIO brownout. There will be evidence of this in your DS logs. You can mitigate it using current limits and ramps.
Your CAN utilization looks too high but I vaguely remember someone posting that there is a bug in those data collection and maybe it isn’t really that high. Maybe someone can advise you on that. Is it bad data collection or should you cut back on how fast you get CAN data updates (status frame info)?
Your roboRIO is working hard; I presume you have a roboRIO original version and not the 2.0 which has a much faster CPU. Are you getting the 0.02 second iteration overrun messages?
Your voltage looks good. You must have something running periodically (you cut off the scale at the bottom so I can’t tell how fast) but it all seems reasonable.
Your packet loss is better than mine and I’m not even using Wi-Fi and I’m running almost nothing to just make this screen print (of course I can’t tell if you are or not but I presume you are).
I pulled out my Ethernet cable to disconnect and got my vertical marker at the last time and it does match your disconnect at the last time so I believe you disconnected.
Now that I think about it it might have been this CAN utilization that is bogus sometimes and not the graph
This is very helpful – thanks! You choose the log using the list on the left. I assume the specific log you have selected is one that shows the problem you are trying to troubleshoot. If not, please post the right log. You can also upload the log file so that we can look at the logs interactively, this can be very helpful.
See the yellow bars at the bottom (packet loss %) and the thin yellow line that runs closer to the top (Battery voltage)? Also the grey/white line that’s jumping around quite a bit – that’s CAN. But there should be a white line as well, it’s hard to pick out in the sceenshot (PDP Amperage)? Also, there’s a time index at the bottom (below where you cut the image). The idea is to correlate this data, using the time code and other clues in the log, with occurrences of the problem. Then, you can zoom in to these time ranges and see what’s going on with the control system (if you have zoomed out and there’s a long range of time being shown, it can be hard to read the graphs).
When you loose communication, how long does it take to come back? Please let us know this and confirm you have selected a log which shows the problem. Then, we can offer a possible diagnosis and specific suggestions. It would be best if you uploaded the log file, instructions on how to find it are at the earlier link. Use the viewer to confirm you have identified the right log and take note of the name. Use this to find the right file to upload.
Also, please tell us what the robot was doing at the instant of the radio disconnect and maybe 3 seconds before the disconnect. Were you taking a break eating a snack with the robot just sitting there doing “nothing” (it’s always doing something but what?) and you noticed the radio wasn’t on? Or were you driving it hard? Or maybe you just pressed the shoot button and the shooter was winding up to speed? Be specific and as complete as you can remember.
My understanding is the radio stays on when one connection is interrupted. Somewhere internally they’re bussed in a non-interrupting way.
The purpose of this modification is to avoid interruptions and therefore prevent reboots, and implementing it on 841 has reduced our incidences of radio reboots. But I only have memories and anecdotes not data…
This is easy to test: connect the radio to the VRM through both connections, then toggle each one independently.
I’ll bet 1 burrito that the radio doesn’t change state (no short or long reset) when each input connection is toggled independently, first person to post a video proving me wrong gets a Chipotle gift card in their direct messages.
“Similar but different:” you can still get reboots with dual power radio connections if you brown out the whole robot and the VRM drops out, since that’s the source for both radio connections.
