![]() |
Code not Properly Downloading
We're having an interesting problem on our practice bot that we hope doesn't carry over to the competition bot.
When we load code with different autonomous routines, only one in about 10 downloads "works", whether we download wireless or directly via ethernet. We've tried reimaging the cRio and even swapped it for another cRio. We're certain it isn't a code issue, as we even commented out everything but a basic "drive straight" command and it failed to function. When we load an old autonomous routine that worked, it doesn't function properly. Making no changes to code, if we load it a few more times, testing it between loads, we get lucky and it works maybe 1 in 10-15 times. We are thinking the code is somehow being corrupted during load, but have tried both wireless and wired downloads. We have also considered perhaps faulty Jaguars. It seems to be limited to autonomous function, but we did have a similar issue with tele-op during the build where we thought we had a code issue, so we changed the code a few time to no avail; when we loaded the original unrevised code back on it inexplicably worked. Perhaps it could be issues with the laptop and windriver? Has anyone experienced something similar? |
Re: Code not Properly Downloading
What programming language?
Perhaps you have an uninitialized variable that keeps the program from functioning as desired "most" of the time, until random factors align and it works. |
Re: Code not Properly Downloading
What symptoms do you have to say its not working? To confirm, I'd recommend adding some console output (printf() in C++) that just says "Test #1" or something to your main loops, and then keep changing and redownloading, if it consistently prints the different messages, your problem is actually in code elsewhere, if you experience inconsistent messages, it may still be code, or it may be a legitimate download problem. (Don't you love technology?)
Matt |
Re: Code not Properly Downloading
[quote=SM987;1035894]We've tried reimaging the cRio and even swapped it for another cRio.[/code]
This makes me think code. Quote:
|
Re: Code not Properly Downloading
Quote:
Matt |
Re: Code not Properly Downloading
Let's see, I'll try and post the code here below. Haven't tried the printf test but have entered debug mode with the robot on blocks and I believe it appeared to follow the code appropriately, but the robot did not respond accordingly. Pretty sure we don't have any uninitialized variables, but I just took this on today. I'll be taking a closer look at the problem today after school and post the results here. Probably will start with using a different computer/windriver reinstall. Thanks for the help.
BTW, this year the students and mentors have been collaborating with code via bitbucket.org. We highly recommend it for tracking changes/reaching mentors at work etc. Here's the code: Code:
#include "WPILib.h" |
Re: Code not Properly Downloading
Quote:
Matt |
Re: Code not Properly Downloading
Hi Matt, I'm a mentor for the team and was trying to help figure this out this weekend. I don't think its a download problem, I think the crio has the code we downloaded and is running it. Here's why:
We added a "heartbeat" variable to the code that counts 0,1,2,3,0,1,2,3... and sent that variable to a graph on the labview dashboard. The heartbeat updates on the dashboard though occasionally I'll see it miss a number here and there (I'm assuming a dashboard packet can be lost occasionally, it doesn't seem to conincide with the robot's behavior). This proves that we're getting code downloaded and that it is running and not getting hung up anywhere. We've attached with the debugger and stepped through the code and see nothing out of the ordinary. All variables seem to be what we expect, all logic flow goes exactly where we expect. We're seeing things I can't explain. Such as, in the debugger, step over a line that tells both sides of the drivetrain to drive forward, on the robot, one side starts driving but the other doesn't, then *while still on the same line of code *break-pointed* in the debugger, the other side starts driving a few seconds later. We have two jaguars on each side of the drivetrain, driven by a Y-cable for each side from the crio/digital sidecar (can't remember). We've seen one jag come on but not the other. In the code, there is only one jaguar object for each side of the drivetrain. (could this be the problem?) In teleop, for some reason the problems are far less common. The only symptom in teleop is that different functions on the robot will occasionally briefly stop responding to control. For example the right side might stop working but the left still works and the arm still works. The drivers are calling these "cutouts" and claim that the main robot before ship never did this. We get them pretty regularly now. We don't believe we're near any current limits. The arm uses a worm gear and its motor draws very little current and the drivetrain is in low-gear when testing this stuff. |
Re: Code not Properly Downloading
Quote:
Matt |
Re: Code not Properly Downloading
The sidecar was fine (LED's ok, and we tested voltages with multimeter, its getting 12v), we swapped it out for another sidecar just to be sure and repeated the process, checked all connections etc. Here's what's really weird: we'll run the same code multiple times, and it will do something different every time, somewhat related to what its supposed to do (i.e. sometimes delay up to 30s before driving a bit, then spitting out a tube; sometimes functioning perfectly). It's like it has a mind of its own. We're using 3 wire servo to the Jags (checked all the connections), we're really stumped. All that is left to eliminate is the power distribution board (which checks out ok via multimeter), and the Jags/connection to them, so maybe we will try swapping those out.
Could the Jags via servo cable be the issue? We have a Y cable going to each drive side and yet still sometimes you can hear it drag a CIM. My personal guess is that at least one Jag is bad, but I don't know if that could cause the other issues we are having. The students have noted that sometimes the Jags flash red when these issues arise which means there is a fault. We'll keep working on it, no discoveries yet :P |
Re: Code not Properly Downloading
I personally have had nothing but trouble with PWM Y-cables. I would try using CAN, but this late in the season its a fairly hefty change. It's certainly doable though if you bring parts to your first event and find a team to help you. A good middle ground between Y cables and CAN is using dedicated PWM cables to each Jaguar. You'll need more PWM ports, but I find it is more reliable personally.
May I ask why you didn't use CAN to begin with? I understand it can kind of daunting at first glance, but I can assure you it's not very difficult under the surface. You can also make use of sync groups to make sure the Jags update together. As far as another test goes, I would disconnect the motor outputs from the Jaguars, so they're powered, and being commanded, but not actually driving anything. Definitely run through the PWM calibration procedure (as outlined in the manual) and then, command the motors forward and back on each side and make sure all the Jaguars on each side are reacting the same way regarding lights and voltage output by multimeter. The voltages between the two jags may vary slightly, but it should be pretty close for the same command. One 'trick' you can do, to make it a bit easier to watch the voltages, put a probe on each M+ for each set of Jaguars, then your multimeter will measure the voltage difference between the outputs, it should be pretty low, under 1V preferably. If its higher, it means the Jaguars aren't responding to the commands the same way, and if you haven't calibrated them yet, you should definitely do that. Sorry if this didn't make much sense, a little sick at the moment.... Matt |
Re: Code not Properly Downloading
Just to cover the obvious... You're undeploying any code before you run code in debug mode, correct? You can get weird things happening otherwise.
Also, have you tried running NetConsole to see if you're getting any error messages or anything? Not everything shows up in the diagnostic window. |
Re: Code not Properly Downloading
We avoided CAN for tradition I guess :P We may switch to it if for no other reason than to keep PWM's from falling out. It is more versatile we just overlooked it in this tough year.
We're making some headway. We completely disconnected the drive Jags and it functioned fine. Then connected one side at a time and it functioned fine. When we connected everything, same issues. The Jags are going into fault mode, but it is interesting; one going in to fault mode appears to chain reaction them sometimes, other times not. It could be the calibration. This might explain why the problem is more prevalent in autonomous where full ahead commands aren't subject to human input. The problem is limited to the Jags or to the power distribution board. Faults are caused by over-current or under voltage. I doubt we're drawing much current in low gear up on blocks. We see the voltage jump all over the place but haven't had issues in the past (sometimes driving with the compressor running and other motors running you will see the voltage drop to 8 or below). Maybe there's a bad Jag in the mix somewhere. I'll post some more findings tomorrow. |
Re: Code not Properly Downloading
Quote:
|
Re: Code not Properly Downloading
What it sounds like you're describing is what we were experiencing earlier.. We were having a problem where the robot would respond to commands for about a second, then our programming laptop would lose connection to the C RIO, then it would get it back for a second, and so on. It turns out we had a loop without a delay in it, om nom noming all the processing time.
I don't know if there's a way to measure the CPU usage in windriver, but I'd suggest trying to find that or double-checking your code that you don't have anything too strenuous. |
Re: Code not Properly Downloading
Quote:
Matt |
Re: Code not Properly Downloading
Wow ok... It appears those case shorted RS-775's are the culprit. I'll update with more when I get home. Appreciate the help of everyone! How frustrating.
Update: The case shorted RS-775 caused a chassis ground. The great part about this is if you reverse the motor, the frame is now positive. Not itself a big deal but there was a fray or something somewhere that made intermittent contact with the frame and thus the erratic Jaguar faults and odd behavior. It's more frequent in autonomous because the motor is receiving a full forward command and thus if a ground wire sweeps against the frame voltage drops to 0 and the Jags fault. Appreciate all the input. We did everything, replaced the distribution board, replaced Jags, ran Netconsole, you name it. found some other interesting stuff. Don't know if we'll have a two-tuber in San Diego or not. :P |
| All times are GMT -5. The time now is 23:42. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi