Intermitent Talons

Can you post your driver station logs here. That will help us be able to debug rather than just guessing

What else do you have installed on your driverstation? Quite often this is the result of another application like autocad or windows trying “phone home” to check for updates / licensing etc.

Thought that might the problem as well, but I checked with task manager and no other application was running.

However, we recently noticed the problem only affects the drivetrain so it might by an issue with the wiring.

Sorry for lack of format pretty new to Chief Delphi, also from a small team with no electronics or programming mentors.

Included a picture of the electronics to see if anyone can spot a potential error

UPDATE:

Hi guys, sorry for spaming post but we are really lost here.

Checking the graphs this is not an issue with coms at all. The robot stays conected and the other motor controlers (two Talons and a Spark) are always responsive. The issue is that the Talons corresponding to the drivetrain (four Talons in total, which are in pairs and using the “following” function for each side) will randomly stop sending output voltage (measured with the ShuffleBoard and the function "getMotorOutputVoltage) and thus the robot will not move; the issue is completly random and I have no been able to find a correlation yet.

If it is any help, we are running the Talons in VoltageCompesentation mode with a filter of 32 ms and a ajusted for 10 volts (originally 11, but stepped down to 10 because I though the problem migh be related to that -it was not-).

To be honest I have no clue what the problem is, any suggestion is apreciated. Thanks.

I currently suspect the code in Arm.lift().
I’d disable it and run a test to see if it changes the behaviour.
Run the code with the lift() code commented out and report back the results.

I also see similar code in Shooter.shoot()
I’m not sure of drivetrain().
In brief you have code like:

if ( some case)
      set motor(value)
else if ( some other case)
      set motor(some other value)
[...]
else 
    set motor(0)

I’d do something like this:

if (some case) 
    motorRunning = true
    set motor(some value)
else if (some other case)
   mothorRunning = true
   set motor(some other value)
[ .... ]
else if (motorRunning)
    set motor(0)
   motorRunning = false

Thank you for your help!!! I will try to update the code tomorrow. Although we redid the wiring just to make sure everything was OK and we haven`t seen the issue since -although it is intermitent, so I am NOT 100% sure it is solved.

Just so I can understand the problem a little better - I am a pretty novice programmer-, why would this help the issue?

I’m not experienced with python but I might suggest if you continue to see the problem, to try using code as close to original template/example code as you can. Do this as the first step in process of elimination either eliminating the software or hardward/electrical systems.

When you do this don’t use voltage compensation, you want to make as few changes to the template as you possibly can.

Do the spikes in packet loss in the DS logs corespond to the loss in control? Since you say you still have control of other mechanisms, that leads me to think the packet loss is not causing the problem you’re seeing.

I don’t see how this will help? Their code looks perfectly normal for FRC code, adding another state won’t help at all. Second this problem appears to have nothing to do with the lift or shooter talons, which work perfectly fine.

Your drivetrain code is kind of complicated. Can you explain the get_left_motor and get_right_motor functions? It might be worth trying out the WPILib DifferentialDrive code to see if there’s something wrong with your drivebase code. You can also try recording what power you set the motors to, to see if that corresponds with the 0 output voltages.

2 Likes

Our team which also uses python had the exact same issue last year of lagging and the robot stuttering which eventually ruined our season. At our second competition, we noticed that it occurred while we ran in velocity mode (Constantly tracking encoders and using PIDS rather than voltage.). Upon conferring with mentors on our team and other team as well as CSAs, we came to the conclusion that we were somehow overloading the CAN bus. When we switched to driving motors simply off percent voltage (Besides autonomous), we never encountered the issue again.

In order to definitively test the issue, we are in the process of setting up the official FMS and running our robot off it in velocity mode as we were unable to recreate the issue by tethering or over wifi.

If we are encountering the same issue, it may be a good idea to notify the people behind robotpy. While I believe we informed them about the issue last year, I can’t recall what their response was and it looks like it hasn’t been completely resolved yet.

Best of luck!

@nickbrickmaster I have seen many problems with robot code that occurs when calling wpilib set() methods every time through the main robot loop. Symptoms include jittery robots and lost packets.

In the case of the ‘nothing has changed’, several objects are being called to update and set the same current state, changing nothing. Most, if not all, set() methods grab a lock which are in contention with FRC threads grabbing the same lock.

Grabbing a lock takes time, and can take significant time if in contention. The net result being that the main loop takes too much time to grab locks to make zero changes delaying the operations of the other half of the main loop.

This problem sounds very similar to other issues others had reported last year across multiple languages. CTRE has a great blog post detailing the issues: https://phoenix-documentation.readthedocs.io/en/latest/blog/blog-perf.html . You should definitely check to see if you have the latest version of robotpy-ctre installed, which would have some of the improvements that they mention.

Another thing I would do is disable LiveWindow. Here’s where my team’s code does that: https://github.com/frc6367/2019-robot/blob/master/robot/robot.py#L72

Thanks for all the replys. The problem went away, it appear that for the problem to not occur the baterry need to be as charded as possible, but I will research the solutions you guys proposed to make a more robust platform for our robot\

Thank you so much

1 Like

If there is a correlation between the battery state of charge and the behaviour of your system, you may have bad batteries and/or bad electrical connections. You may want to post driver station logs so it can be seen if you have voltage dips. You can also check the batteries with a Battery Beak and check all of your electrical connections for loose crimps and loose bolted connections.

There have been bad batches of batteries in the past. Do you know where that/those batteries came from?

Not really, we are from México. We have only been at for 3 years. Sorry

Regardless of where you purchased your batteries, they can go bad. That is why you should check them with a Battery Beak.

OP is nowhere near brownout conditions (battery drops below 7.5v). Packet losses appear to be reduced while the bot is enabled, and the latency is stable… I think virtuald is on the right track.

Looks like the exotic CANbus issues from too many get()commands overloading FRC NetComm.

(I don’t follow codedr’s explanation of how their suggestion reduces the number of get() and set() commands, which the thread seems to be in agreement are a likely culprit)