Intermittent connection on field only

[Mark McLeod]

Originally Posted by Dad1279

@Mark - So that's an issue with Labview and not Java? (We were using Java)

It's a LabVIEW issue, although it's possible to write Java/C++ code that has the same problem (i.e., killing the CAN sequence mid-command) you pretty much have to go out of your way to do it.

The LabVIEW default framework is constructed to kill the Autonomous thread at the end of the mode. The good part of this is you can't easily get stuck in Auto like you can in the other languages with sloppy code. The bad part is, with sloppy LabVIEW CAN code, you can end up with corrupted CAN.

[Al Skierkiewicz]

Originally Posted by techhelpbb

You know very well that I can't test a competition field environment without a competition field. So you're telling people that I should basically test something you are insuring can not be tested.

The point again, for all to read, is not that all issues are power quality issues. The point is that when you do have power quality issues you are effectively putting those teams at a disadvantage. I fully admit...again and again in this topic there are more problems than merely the power quality.

Note: this next part was posted before Al edited his post.

So far as this not being a real issue...you prove once again that Team 11 and other teams finding bad power supply components feeding the D-Link AP is not considered a real problem. It's not a real problem why? Perhaps because Team 11 and these other teams weren't on the Einstein field? Going to be hard to get to that field when our not so 'real' problems get in the way.

Brian,
I suggest you look back and reread what I have said to you and to others. You believe your team obviously has a power issue but you refuse to perform the tests that would point to a power issue on your own robot. Do so and bring us the results. You do not need a competition field to do that (try using FMS Lite). Your robot remains a stand alone component that if power is an issue, it should show up that problem on your home field. If you find something that others have not, then and only then can FIRST actually decide to pursue an investigation using other methods. You must admit that what you are asking requires a rather large expense on First to accomplish. Bring valid data to support your claim and First can weigh your data against the need to expend further money and resources in the pursuit of a radio power supply issue.

As for myself and all other robot inspectors, we take our job very seriously. When we don the shirt and hat we take on every team as our own, bar none. When they fail on the field, we fail. When they go home with a loss, so to do we. We feel strongly that the success of an event lies our in our hands and the happiness of the competitors is our highest measure of success. We cheer for everyone because that is what we are required to do in this competition. When we see something wrong we try to fix it or we find someone who can. We do this at every competition for every team, all weekend, without regard to team number or qualifying slot. Should an inspector or Lead not meet these goals, I want to know about it. Teams need to be able to trust and believe in the assistance of their inspectors. Our stated goal is to insure you play (within the rules) and not to prevent you from playing. I can tell you that robots not running is a common discussion topic during volunteer meals for inspectors. We pass along what we find so that all teams can fully participate.

As to your finding a bad power component at one of your competitions, that is a known issue with a very small number of regulators. (a very few have been found defective from the factory) When questioned, most often the root cause is a team wiring issue that was later corrected by the team. For the record, that can take the form of the input and output of the regulator being swapped, the input or the output wiring reversed, the input to the radio reversed, or some of the wiring not fully insulated and shorting to the frame. As to other issues with robot radio, we have found the use of the wrong size coaxial plug (either the inside socket or the outside barrel or both), a team fix on a broken plug, a broken wire internal to the cable due to stress or bending, improperly applied hot glue that forced the connector open or un-soldered the power jack. More than half (~100 this year) of the power problems we find is teams wiring the radio directly to an unregulated 12 volt output on the PD. Other issues include blocking all the cooling holes in the radio, using damaged ethernet cables or after having broken a connector hot gluing same into an ethernet output on the radio. Mounting the radio upside down against a metal plate or mounting the radio on top of 2 CIMs in a transmission are also common. And finally teams mounting the radio deep inside the robot to "protect" it from harm.

So to repeat for everyone's homework, if you suspect a power issue with your robot radio, test and document the conditions under which the link fails. i.e. a power supply droop, noise (how much and what frequency), radio reboot or not, disabling of certain inputs or outputs, do you have a camera and does it stop working, does the robot stop after auto or after a specific length of time coming out of auto, etc. Make your findings public or send them to me, so others can duplicate the problem.

As far as your last paragraph above, I never said this was a non-issue. I said, in my experience I have not found any evidence that the power supply issues (that you suggest are occurring) have caused link issues. So far you haven't shown any evidence of this either. Your team found a defective regulator that for you and me is a smoking gun in your robot. That is a known problem, stated multiple times over the past two years by me (and many others) in several posts here on CD and in the LRI forum for all inspectors. For the record any problem is an issue for me. If you have one, the chances of someone else having it are good. However, I can only pursue problems if you can tell me what it is and repeat it. If you were closer I most certainly would suggest I spend a Saturday at your facility pursuing this.

[techhelpbb]

Originally Posted by Al Skierkiewicz

Brian,
I suggest you look back and reread what I have said to you and to others. You believe your team obviously has a power issue but you refuse to perform the tests that would point to a power issue on your own robot. Do so and bring us the results. You do not need a competition field to do that (try using FMS Lite). Your robot remains a stand alone component that if power is an issue, it should show up that problem on your home field. If you find something that others have not, then and only then can FIRST actually decide to pursue an investigation using other methods. You must admit that what you are asking requires a rather large expense on First to accomplish. Bring valid data to support your claim and First can weigh your data against the need to expend further money and resources in the pursuit of a radio power supply issue.

Al, Team 11 did have a power issue. Replacing the DC-DC converter at the competition did fix it. You want this DC-DC converter? I ask because when this topic and the vector it was following wouldn't stop before I offered to remove *myself* from this issue and let someone you were seemingly more comfortable with perform the analysis to your satisfaction.

The solution to the problem is past tense. It was found.

Other teams did have a power issue. They replaced the PDB and it did fix it.

Past tense and in the next part I accept that you publicly acknowledge this.

As for myself and all other robot inspectors, we take our job very seriously. When we don the shirt and hat we take on every team as our own, bar none. When they fail on the field, we fail. When they go home with a loss, so to do we. We feel strongly that the success of an event lies our in our hands and the happiness of the competitors is our highest measure of success. We cheer for everyone because that is what we are required to do in this competition. When we see something wrong we try to fix it or we find someone who can. We do this at every competition for every team, all weekend, without regard to team number or qualifying slot. Should an inspector or Lead not meet these goals, I want to know about it. Teams need to be able to trust and believe in the assistance of their inspectors. Our stated goal is to insure you play (within the rules) and not to prevent you from playing. I can tell you that robots not running is a common discussion topic during volunteer meals for inspectors. We pass along what we find so that all teams can fully participate.

Sir with respect. I am not accusing you of active favoritism. Other than the mere fact that when you don't like something other people tell you they don't get told facts and figures they get told to go figure it out on their own and basically stop bothering you (when in point of fact I've offered repeatedly to do just that with a topic split I can't myself perform). Realizing it or not, that exclusivity creates a situation where someone gets marginalized. I should hope no one intends that result or you can see that I am obviously not shy and I will call them out on it.

Furthermore, some of those students you have on that field crew are students I mentored. So let me be clear. I am extremely unhappy when I see students in my chosen profession. A profession to which I have been an apprentice. To which I have clawed my way up in versus vast nonsense. I am extremely unhappy when I watch them get reduced to tears. I am tired of FIRST using them as reason why I should watch what I say.

I should like to point out that the very first e-mail I ever got in private from anyone on ChiefDelphi was Eric telling me to watch what I say because 40,000 students are watching. Yes they are and they need leadership and answers.

Some of you are their leaders. You dictate the limits of their tools (you certainly shot down my offer of a tool to which you have little alternate). You dictate the information and facts they are presented. I feel given the sheer lack of students in this topic (especially among those telling me to go away) that the leadership of this matter is using them as a shield. Not that you Al are doing so...but I see it all over the place. Where we tell people don't judge them so poorly. I am not judging those students, sometimes my students poorly. I am demanding they be given an environment that is never allowed to come to this end!

As to your finding a bad power component at one of your competitions, that is a known issue with a very small number of regulators. (a very few have been found defective from the factory) When questioned, most often the root cause is a team wiring issue that was later corrected by the team. For the record, that can take the form of the input and output of the regulator being swapped, the input or the output wiring reversed, the input to the radio reversed, or some of the wiring not fully insulated and shorting to the frame. As to other issues with robot radio, we have found the use of the wrong size coaxial plug (either the inside socket or the outside barrel or both), a team fix on a broken plug, a broken wire internal to the cable due to stress or bending, improperly applied hot glue that forced the connector open or un-soldered the power jack. More than half (~100 this year) of the power problems we find is teams wiring the radio directly to an unregulated 12 volt output on the PD. Other issues include blocking all the cooling holes in the radio, using damaged ethernet cables or after having broken a connector hot gluing same into an ethernet output on the radio. Mounting the radio upside down against a metal plate or mounting the radio on top of 2 CIMs in a transmission are also common. And finally teams mounting the radio deep inside the robot to "protect" it from harm.

So to repeat for everyone's homework, if you suspect a power issue with your robot radio, test and document the conditions under which the link fails. i.e. a power supply droop, noise (how much and what frequency), radio reboot or not, disabling of certain inputs or outputs, do you have a camera and does it stop working, does the robot stop after auto or after a specific length of time coming out of auto, etc. Make your findings public or send them to me, so others can duplicate the problem.

I would love to know, in a competition where I was one of the few examples of someone that brought an oscilloscope to a competition (a CRT unit at that).

In a competition where I had students that did not even know what the oscilloscope was nor it's application on the robot.

Considering that I offered test equipment for mounting on a moving robot, or even to open the door to using the cRIO which was shot down in the official FIRST Q&A forum after an unusually long delay.

How you figure that so many of the people you ask have the tools to deliver on your request?

Especially, again, when I point out that the tools to eliminate this issue on the active field...when it's the most disastrous they do not have. They can't even use the cRIO on the competition field as a data logger on that power supply.

Even if I show you what we already know. That power issues are the bottom of the troubleshooting tree and that we all admit they effect people. The point has and remains that what a robot does on my test field sometimes means nothing once I toss it in a bag. Ship it all over creation. Smack it into walls. Have pieces torn out of it by other robots accidentally and expose it to just general wear and tear.

The entire point of the monitors I created or even using the cRIO as a data logger on the D-link AP power supply was to prevent incidental damage as the result of wear and tear from blind siding teams that have otherwise done everything right and just don't realize the cumulative damage they are taking. We at Team 11 had no reason nor any approved method to track that damage. That's not unique to Team 11 at all. There's no approved method to get into that point while moving, and certainly no example I can find of anyone even load testing that supply and again I did ask openly in this very topic.

As far as your last paragraph above, I never said this was a non-issue. I said, in my experience I have not found any evidence that the power supply issues (that you suggest are occurring) have caused link issues. So far you haven't shown any evidence of this either. Your team found a defective regulator that for you and me is a smoking gun in your robot. That is a known problem, stated multiple times over the past two years by me (and many others) in several posts here on CD and in the LRI forum for all inspectors. For the record any problem is an issue for me. If you have one, the chances of someone else having it are good. However, I can only pursue problems if you can tell me what it is and repeat it. If you were closer I most certainly would suggest I spend a Saturday at your facility pursuing this.

Here's the thing Al. Unless someone tells me otherwise I'm going to Monty Madness with the tools I made to reduce the conflict on this issue...which perversely people have aligned to increase the conflict on these issues. I expect given the initial excitement that FIRST had when I mentioned what I created and was offering: that FIRST will give these monitors, that community electronic motor control and most especially LinuxBoy's projects a fair shake. I also expect that when teams ask FIRST to use a piece of approved hardware to monitor a system in a way that is inconsequential to it's function, but hugely consequential to the performance of the robot they'll let them do it even on a competition field.

I have every reason to believe based on the pattern I've been a personal witness to for the last week that I need to say that paragraph above publicly. I personally over a year ago offered to provide nearly the exact same thing LinuxBoy has been working on and the feeling I got personally was that I should go away. Do not do that to LinuxBoy, do not involve him in what seems to be an issue some of you have with me.

[Al Skierkiewicz]

Brian,
Your last post is confusing, what are you trying to say? Are you saying I act with favoritism because I don't agree with your suggestions? With your methods or with your premise?
What are you referring to in the paragraphs about students and field teams?
I am suggesting that you use your monitors on your own robot on your practice field to give First and the community some data to digest and duplicate. Are you against that?
As to you having something on your robot during Monty Madness, that is up to you and the event staff.
As to First's reaction to your hardware, I have no knowledge of what you are relating to us. For the record I am not FIRST staff, I am not a member of the GDC, I am a key volunteer.
As to adding monitoring to a robot, may I refer you to StangSense. We used the control system in conjunction with a custom circuit, to monitor current/voltage to critical systems, mostly motors, using a method that did not interrupt the power pathways to electrical components on our robot. We also used that system in a mobile design to aid other teams in the pursuit of problems on their robots for several years. We also described the data we collected and the subsequent issues we observed to anyone who wanted them and that data aided in the design of the current PD power circuitry. FIRST added several test bed monitors to operating robots (including ours) during the design phase as well. I assisted with at least some of the interpretation of that collected data during the collection at IRI. The boost/buck regulators on the PD are a direct result (I believe) of that research.

[Gdeaver]

First has a serious problem with dead robots on the field. The radio power supply and cabling has known issues. Given the severity of this problem and most likely there are many points of failure all points need to be looked at. The power supply issue needs to be looked at closely to see if there are problems other than cabling. I mentioned that there are potential problems with a switching power supply feeding a switching power supply feeding a switching power supply. I have never head of anybody that has characterized the load dump and switching transients on the PD. Does this affect the power supply to the radio? One transient that gets through is all that is needed to potentially lock up the radio electronics. It would be a very good idea to get some real on the field data. This needs to be done at a competition. A competition like Monty Madness should be RF noisy enough to put the radio into a high power state. ( gain scheduling) Team 1640 will be at Monty. We would be willing to have data logging put on to our robot. Can't load code on our c-rio. It's busy enough. Has to be stand alone. We have a swerve drive using 8 motors plus 4 more motors for ball handling and shooting. Should be a good heavy load environment for some testing. The testing should be able to see short transients. So if this want to be done our robot is available. Contact me if our robot is needed.

[Jon236]

Originally Posted by RyanN

Then comes the driver station. We had been using a Dell purchased this season as the DS, but during all the debugging, we switched to my laptop, a 2010 MacBook Pro (Core i5, 8GB RAM, SSD... a pretty powerful machine), and we kept on having the issues. Finally, when trying out the basic framework code, we switched to the Classmate PC, configured for this year and updated with the latest FRC updates, and no Windows Updates.

Just curious, was your wifi adapter disabled on your laptop when you connected to FMS?

[techhelpbb]

Originally Posted by Al Skierkiewicz

Brian,
Your last post is confusing, what are you trying to say? Are you saying I act with favoritism because I don't agree with your suggestions? With your methods or with your premise?

No I am merely stating that the power supply issues, on the whole robot in point of fact, are often a great big grab bag of problems many of which I feel are beyond the resources of some teams.

We don't expect teams to solder. If they can great. We don't expect teams to engineer the cRIO. If they can great. We expect teams to follow directions, but what directions can I hand them to follow?

Where are the directions and parameters to load test that power supply? What tools do they need? What do the tests in the directions tell, or not tell about the robot?

I am not the first to ask these questions. When we ignore that some teams are far more equipped than others. When we ignore that off the competition fields these teams may be more greatly isolated. We create a situation that while I agree with you seems so simple...to them is disaster looking for a place to happen for them.

What are you referring to in the paragraphs about students and field teams?
I am suggesting that you use your monitors on your own robot on your practice field to give First and the community some data to digest and duplicate. Are you against that?

I'll be at Monty Madness at the request of field personnel. I am not against it at all.

As to you having something on your robot during Monty Madness, that is up to you and the event staff.

Exactly. I was willing to let FIRST shut down the idea of monitoring the D-Link power supply with my my monitors without too much fuss because it was made clear to me that off season events are the place to beta test. I agree with the KOP team at FIRST that they should have all opportunity to review a piece of test hardware they've not seen before.

I was surprised when FIRST said the cRIO couldn't monitor the power supply of the D-Link AP. In effect that means that we can't look while the robots are running on the competition field with hardware FIRST should by now know quite well.

As to First's reaction to your hardware, I have no knowledge of what you are relating to us. For the record I am not FIRST staff, I am not a member of the GDC, I am a key volunteer.

Fair enough Al. It's just that this a FIRST sponsored forum. It's hard to ignore the authority from which some of you speak.

As to adding monitoring to a robot, may I refer you to StangSense. We used the control system in conjunction with a custom circuit, to monitor current/voltage to critical systems, mostly motors, using a method that did not interrupt the power pathways to electrical components on our robot. We also used that system in a mobile design to aid other teams in the pursuit of problems on their robots for several years. We also described the data we collected and the subsequent issues we observed to anyone who wanted them and that data aided in the design of the current PD power circuitry. FIRST added several test bed monitors to operating robots (including ours) during the design phase as well. I assisted with at least some of the interpretation of that collected data during the collection at IRI. The boost/buck regulators on the PD are a direct result (I believe) of that research.

I have no doubt that StangSense and your work is well considered Al. The problem for me remains. That you do not personally build all of our robots. The need for teams to collect data doesn't really end in a beta or in just a few robots or even in the pits at competition.

Data collection against issues, assuming proper respect for doing it properly, should not discouraged in any way. In fact, it should be an extremely common thing for FIRST teams beyond just reading the voltage of the battery. I don't feel based on the current rules and based on the current status of things that such collection is widely encouraged. Worse, because of a lack of simple instructions I feel that it's beyond the reach of some people that really need it.

[Al Skierkiewicz]

Originally Posted by techhelpbb

Fair enough Al. It's just that this a FIRST sponsored forum. It's hard to ignore the authority from which some of you speak.

This is not a FIRST sponsored forum, this is a team forum and always has been. Only the First Forum is sponsored by First. For myself, as for others that may or may not be FIRST staff, we write here for the teams that need advice. As part of that responsibility we (the collective CD community) feel strongly in correcting occasional errors in posts to insure that teams get the answers they need. I write personal opinions on issues related to the community in general from my collective experience (17 years on WildStang and 43 years as a Broadcast Engineer).

I still have to ask what your reference to students on field teams means?

[techhelpbb]

Originally Posted by Al Skierkiewicz

This is not a FIRST sponsored forum, this is a team forum and always has been. Only the First Forum is sponsored by First. For myself, as for others that may or may not be FIRST staff, we write here for the teams that need advice. As part of that responsibility we (the collective CD community) feel strongly in correcting occasional errors in posts to insure that teams get the answers they need. I write personal opinions on issues related to the community in general from my collective experience (17 years on WildStang and 43 years as a Broadcast Engineer).

Fair enough if I am mistaken. Your forum's position is well established in FIRST circles and the frankly your forum actually often comes up before FIRST forums in a variety of situations. My apologies for misinterpreting the extent of your influence.

I just want to make myself very clear again, that nothing I've written in this topic is intended to devalue your views or your experience.

I still have to ask what your reference to students on field teams means?

It all comes down to how leadership decides to handle situations.

I see people all over the place in these topics suggesting that some of us have lost confidence in the field personnel because we speculate and try to solve the problems (funny to be asked not to solve problems in situations where it's the task of the day normally...especially difficult considering the enthusiasm that FIRST inspires in regard to troubleshooting regardless of whom you are or what you know). That somehow we have lost confidence in FIRST's ability to troubleshoot this issue on the field.

I have lost no confidence in any field personnel. None at all. Not one field person I've seen recently seemed to me to be intent on making the playing field anything other than fair, circumstances beyond their control may influence the situation otherwise however. It was certainly clear to me on several occasions they were not fully equipped or fully prepared with quick, direct and specific resolutions to a variety of problems. Again there's a limit to what they can bring to the table, having never seen your robot before, having no access to valuable tools, and sometimes not having information about things that could and probably should have been given to them before these events. As my example in this topic, I was expressly assured by field personnel that the field was on 2.4GHz...not 5Ghz. That's a problem that needs to be addressed, it was a mere simple error I'm sure, but it's an error that masks other communications issues. Collecting anecdotal information before events is no real solution to the issue either of getting these field folk and the teams the information they need. Continuous, specific, directed data collection is a good solution.

I also brought that up because some people were genuinely thrilled that I had actually bothered to think to bring an oscilloscope to an event as the guy that didn't even know he was competition field spare parts until the evening before. People at that event in management of it made it very clear they intended to recommend that an electronics table, or at least the relevant basic tools were available to teams at events. They were thrilled that I sat there making tails for 2GO PC's with broken Ethernet ports. I even made a bunch of cables for the field and for teams. It was extremely clear to me that some of these teams had no resources to do this for themselves I wonder what would have become of them had I not stepped up.

When I wander through forums often reading but not posting to topics and I see people sort of suggesting that field personnel are somehow to deal with this. When I see people suggesting we should be quiet because the field personnel might feel we are being predatory on them. It makes me very unhappy. The field personnel have done all they could, in many cases much more than they should have been able to do...

However, they are restrained by the tools, by the quality of their instructions, and most importantly by restrictions on information that need to be removed.

I don't find any fault for these people running the fields, in the end FIRST is the central control canopy for all that happens. If the information doesn't get there. If the instructions were not given. If the tools were not there. FIRST needs to do something about it. Not have some people running around topics suggesting that other people are not patient with the field personnel or that the field personnel are the issue. There's no need for people to be silenced, but we can all see the unprecedented and absolute need that this problem...in fact all problems that drop robots dead on the field be meticulously managed and removed.

Data collection needs to be done. It needs to be done to analyze this mess at the Championship. It needs to be done within the organization. It needs to be a tool handed to every nook and cranny of the people involved and it does need to involve the people in the community. It needs to be continuous and it shouldn't be disappearing behind the curtains now. Blame is irrelevant and again purely anecdotal.

[Hugh Meyer]

Out of band interference could also be part of the problem.

I remember at the 2007 DARPA Grand Challenge they had a huge video display setup near the starting line. The three robots closest to the screen couldn’t move until they shut down the giant display. It was about the same distance the Einstein field was from the display in the dome.

Another possible culprit is the high concentration of video and other equipment near to the FMS access point. I often see the access point sitting adjacent to a television video monitor, which I would consider as bad as putting the robot radio on top of a CIM motor.

-Hugh

[Al Skierkiewicz]

Brian,
These students???...

Originally Posted by techhelpbb

Furthermore, some of those students you have on that field crew are students I mentored. So let me be clear. I am extremely unhappy when I see students in my chosen profession. A profession to which I have been an apprentice. To which I have clawed my way up in versus vast nonsense. I am extremely unhappy when I watch them get reduced to tears. I am tired of FIRST using them as reason why I should watch what I say.

[techhelpbb]

Originally Posted by Al Skierkiewicz

Brian,
These students???...

A fair number of your field crews are college students. They come back and help out.
No specific event was implied.
Further, I'm including all the personnel at an event in the crew.

Additionally (post 139):
http://www.chiefdelphi.com/forums/sh...106042&page=10
"This could have been prevented long before Einstein, but that is a discussion for other threads which we have all been following all season. I saw one FTA in tears afterwards, and I know everyone involved was doing all they could."

[Al Skierkiewicz]

Hugh,
The LED wall does give off a fair amount of noise. It is mostly in the form of buzz and wreaks havoc with dynamic microphones. That's why you don't see anyone speaking from behind the scorer's table on the big stage I would suspect. I have some experience with RF mics and wireless "IN EAR" monitors and have used a spectrum analyzer when checking for problems in several shows here. Most are in the UHF band now that the FCC has been involved in unlicensed wireless devices in unused TV channels. Almost everyone is using Wi-Fi to interconnect various audio interfaces and haven't had any issues. I have not seen anything in the bands I am looking at so that leads me to believe that harmonics beyond 700 MHz do not exist. Each little block connects to the one next to it to assemble a large screen. Then you tell the master-controller how many blocks wide and high and if you want it to portion the screen or simply display the entire video signal. There is a CRT monitor on the scorer's table but is an analog device as I remember. There are a variety of LCD monitors as well. Most of that stuff has a fair amount of shielding internal so I don't expect anything in 5 GHz range from any of that stuff.

[RyanN]

I've been messing around with things today and yesterday trying to break the robot.

Power and brownouts should be a non-issue. If the teams use the OEM cable, the connection remains consistent and has no drop outs.

We also were running with a dead battery. The first thing to give out was the digital sidecar. It resulted in the robot quickly flashing our LEDs on and off as it would brown out the DS,.causing the relays to turn on and off rapidly. The voltage went down to about 4V before I shut off the light show. The cRIO (4-slot) and the Dlink remained powered and connected the whole time with no dropouts.

We have also been testing CAN out a bit, and found some unsettling results.

If you have an intermittent connection where a CAN devices does not appear on the CAN network, the whole CAN network will drop out, and the digital side car will not work. The thing is that the robot remains connected the entire time.

This was not the cause of our problem as we went back to PWM during Bayou, but I can see teams complaining about no communication due to this.

We originally had 4 CAN-enabled Jaguars, IDs 2, 3, 4, and 5. ID 5 was the last in the chain, and had the terminator resistor installed. We wanted to test 8 Jaguars over the RS-232 to see how well it worked. Well, we assigned IDs 6, 7, 8, and 9 to the drive motors. When we plugged it all back in, nothing worked. We found out that when we extended the network, that the Jaguar with ID 5 had a bad RJ-45 port. To work temporarily, we rearranged the cables to make that Jaguar the last in line, and it all worked again.

So that's another idea that I had as far as troubleshooting.

We can't use the 8 jags though... I'm not sure if we reached the limit of RS-232 driving CAN, but we were getting tons of CAN timeouts, and Drive Motors not being called fast enough warning (in teleop). I analyzed the timing of Telop, and found that it ran every 10ms on average, but 60ms to 500ms spikes were not uncommon (where we saw the timeouts). When this occurred, we would also glitch/jerk.

I think it has to deal with calling CAN devices at different times. We have Periodic Tasks running a shooter control loop every 50ms, and then Teleop is called every 50ms. I think there is a resource conflict and timing issues and we occasionally get a bus lockup for a split second. Going back to PWM, we run at a constant of 3 to 4ms to run the Telop task.

[Mark McLeod]

Teleop shouldn't be showing a loop time any faster than 19-20ms, because it's triggered by the DS packets arriving every 20ms.

You've got something else wrong going on with Teleop.