Your take on CAN...

[RyanN]

I'm curious as to what other teams think of CAN. Is your team using it? If so, why? If not, why not? Any problems that keep on popping up for no apparent reason?

I ask this because I know Team Fusion wanted to use CAN for the main sake of getting rid of the spaghetti. We were also interested in the different control features such as a configurable voltage ramp, current status, voltage status, fault status, etc...

We wanted to use it last year, but encountered too many bugs (which were later fixed with new cRIO images and firmware) during build season. This year is a different story.

We did have an issue, which I cannot comment on, where CAN stopped working, but I was able to easily fix it when I went home for the weekend to mentor. Basically the cRIO somehow got stuck into safe mode, the students reimaged it, but did not turn Net Console off properly.

The main issue that worries me is the RS-232 portion from the cRIO to the Jaguar, as motor noise, vibrations, etc... can interfere with the connection, but supposedly the firmware is built strong enough to combat these problems.

I'm fairly confident about the actual CAN portion though, I mean they use CAN everywhere in industry, right down to the car you drive (if you're old enough :))

We aren't placing all bets on it though. It's only running our shooter, so if it does go out, we're still a really good defensive bot with the ability to heard balls and cause major chaos on the field. :p

So yea... what's everyone else's take on CAN? Who's using it? Who isn't? Why? How are you using it?

[techhelpbb]

CAN on the Jaguars is pretty functional. Exceptions:

1. It's a single point of failure, make sure the wiring is correct.
2. Without using the 2CAN you can overwhelm the CAN communications.
3. If the Jaguars brownout you'll end up back in the default modes and if you're tracking encoders with them you'll have a problem. So don't build a system that browns them out (I know that's a lot simpler to say than do).
4. You can detect the brownouts and thankfully the newer firmware won't lock up like it used to.

[gracie.]

From the electrical team's point of view, CAN is awesome. We got immobilized in a couple matches last year because the PWMs on our jags kept falling out. It got to the point where we were using hot glue and electrical tape, but the damage was already done. I know it took programming a while to figure out how CAN works, but in the end I think it was worth it.
A word of caution... crimp your connectors so the wires are in the right order... oops.

[mikets]

I can't comment on CAN from past experience because this is our first year using CAN too. But we have been researching CAN issues in order to avoid hitting them. So we should be able to tell you our experience after this season :) . However, we can share some of the things we learned so far. For example, the issue about Jags browning out.
http://chiefdelphi.com/forums/showthread.php?t=101871
Reliability issue due to daisy chaining CAN bus.
http://chiefdelphi.com/forums/showthread.php?t=99554&page=3&highlight=backbone

There are a few issues we are still researching. One of them is about the bandwidth of CAN bus. It may be more relevant to you since you are using RS-232 instead of Ethernet which is much slower. Depending on how your program is structured, you may be sending multiple CAN messages across the CAN bus in each iteration of your robot loop. My understanding is that each message involves a send and a receive and they are synchronous. In our case, we have seven Jaguars on the robot. In an ideal scenario, our robot main loop will be updating all 7 Jaguars. 5 of our Jaguars have encoders so our ideal scenario is one Set() call for each Jag and one GetPosition() or GetSpeed() call for each Jag that has encoder. So ideally, we will have at least 12 CAN messages sent for each robot loop. I say ideally because I am making an assumption that we do not send more than one Set() or Get() for each Jag in a single loop. But we already found a few places in our code that's not true. So we are in the process of adding perf code to benchmark the number of CAN messages sent per loop and the average time each CAN command uses and how much time the CAN bus operation consumes in a single iteration of the main loop. We are doing this because we occasionally hit the MotorSafety timeout issue which we can't explain except for CAN bus traffic taking too much time in a single robot loop. We are instrumenting a CANJag wrapper class to collect this information. We hope to have some results in a week or so.

[Phalanx]

If you're looking to save bandwidth on the CAN bus consider using Periodic Status for each JAG. Configure each JAG in begin, and then you ask each JAG in teleop to obtain it's most recent cached status update.

Be aware, there is a minor bug as described here:
http://www.chiefdelphi.com/forums/showthread.php?t=103629

Also consider, 128K for the Serial to CAN adapter, versus 1M using 2CAN and Ethernet.

[mikets]

If you're looking to save bandwidth on the CAN bus consider using

Periodic Status for each JAG. Configure each JAG in begin, and then you ask each JAG in teleop to obtain it's most recent cached status update.

Be aware, there is a minor bug as described here:
http://www.chiefdelphi.com/forums/showthread.php?t=103629
As far as I can tell from reading that thread, it is a LabView only feature. (no?) We are using C++. I don't seem to see that in C++ WPILib. In any case, like I said, we are planning to implement a wrapper class that shadows all config and parameters of the Jag, then we will create a periodic task (say 100 msec period) that will communication with each Jag once in each period to communicate the "changes". So if the caller is calling more often than this period, it will just get/change the cached shadow copy. I suppose this is exactly what the LabView library is providing. It would be great if the CANJaguar class in WPILib will support this for next year (also implementing the brownout safeguard).

[mjcoss]

We are using CAN and used them as well last year. My concerns are the introduction of a single point of failure (2CAN), and the side effects of the safety features of the Jaguars. In a properly running system, the Jaguars run fine, and don't brown out. BUT this is a robotic competition, and bad things happen.

There has been persistent issues with timeouts. Some claim it's all just bad wiring on the part of teams, others claim that the CRIO/CAN driver is to blame, others that the 2CAN is the issue, and others that the Jaguars are bad. The upshot is that we have a number of components and lot a software in between.

One thing that I stumbled upon lst year was that if a CAN bus message timed out, the caller (in C++) receives no indication that an error occurred. This results in the CAN request returning valid (0) but incorrect data. So the test GetForwardLimitOK will return false on a timeout'd request. This can wreak havoc on code that is unaware of the issue.

[Aren Siekmeier]

Our team hasn't much extensive research here, but here's our experience anyway:

Last year, both 2175 and 3130 (the team we share a shop with) tried it out during the build season, but it consistently caused teleop to lag, and it seemed it was due to traffic jams on the CAN bus. Since we weren't getting that much benefit from the CAN bus anyway and it was near the end of build, both teams switched to PWM control because we needed something that worked, and the lag in Teleop went away immediately. Both teams were using the Serial to CAN capabilities of the black Jags. Since then, we have found that the lag issues on the CAN bus may have been due to loose connectors (the pins can get bent too far back), but haven't tested any of it yet.

This year, 2175 went with all Victors to save space and because they are significantly simpler electrically and don't fault. Also, we would have gained nothing from using CAN this year because all of the mechanisms for which we want closed loop control are on more than one speed controller, so offboarding the control loop is not an option. So 2175 hasn't pursued CAN since the end of the 2011 build season (we may play around with it more this offseason).

3130 gave CAN another shot, and as far as I know have had success. They are still doing Serial to CAN. But one of them would have to give all the details there.

[techhelpbb]

We are using CAN and used them as well last year. My concerns are the introduction of a single point of failure (2CAN), and the side effects of the safety features of the Jaguars. In a properly running system, the Jaguars run fine, and don't brown out. BUT this is a robotic competition, and bad things happen.

There has been persistent issues with timeouts. Some claim it's all just bad wiring on the part of teams, others claim that the CRIO/CAN driver is to blame, others that the 2CAN is the issue, and others that the Jaguars are bad. The upshot is that we have a number of components and lot a software in between.

One thing that I stumbled upon lst year was that if a CAN bus message timed out, the caller (in C++) receives no indication that an error occurred. This results in the CAN request returning valid (0) but incorrect data. So the test GetForwardLimitOK will return false on a timeout'd request. This can wreak havoc on code that is unaware of the issue.

I still fight with this issue as well so I'll second this concern. There's so many things that can cause it and I'm sure quite often it's a subtle combination. A lot of work has been poured into working the various bugs out, and still, if we wait long enough it'll come up (in the default modes, it comes up much more often in other modes).

[johnmaguire2013]

I don't understand motors, electricity, etc. however I have a question on behalf of my team, and I think I'm wording this correctly.

Basically, we used CAN with Jaguars for our robot's drivetrain this year. Multiple times it stopped working during the match, and our team was seemingly able to determine that this was due to built-in protection on the Jaguar to stop, essentially, surges. It was happening when a large amount of voltage was sent through the Jaguar I believe, and our team said this wouldn't be an issue if we switched back to PWMs. It would usually happen if our driver was moving back and forth very quickly (e.g. the bridge.) Does anyone have an idea of what was happening or how this could be fixed?

[techhelpbb]

I don't understand motors, electricity, etc. however I have a question on behalf of my team, and I think I'm wording this correctly.

Basically, we used CAN with Jaguars for our robot's drivetrain this year. Multiple times it stopped working during the match, and our team was seemingly able to determine that this was due to built-in protection on the Jaguar to stop, essentially, surges. It was happening when a large amount of voltage was sent through the Jaguar I believe, and our team said this wouldn't be an issue if we switched back to PWMs. It would usually happen if our driver was moving back and forth very quickly (e.g. the bridge.) Does anyone have an idea of what was happening or how this could be fixed?

I think you mean current not voltage (the battery voltage will generally get lower as you drive the robot).

There's a bunch of issues at work here:

1. The Jaguars and the Victors both reboot when the voltage of the battery gets too low (the battery can be too low because it needs to be charged, or because you are beating it down with heavy electrical loads). Victors, which use PWM only, will reboot fairly quickly and in some cases you might not even notice. The Jaguars using CAN can use quite a few modes and those modes have to be selected if they are not the defaults. If you use the Jaguars with PWM or the default mode on CAN (which performs a similar concept) when the voltage drops to a certain point (what is called a brown out) they come back up and just start working again (at least if you have the newest firmware they usually do). If you use another mode on CAN, then when they brown out you need to detect it and reset the mode. Problem is if you put an encoder on the Jaguar and it browns out...unless it's an absolute encoder...you'll loose track of the position of that encoder. Keep in mind that the brown out condition is not going to come back if the circuit breaker trips and hasn't yet reset.

2. You don't mention what you've got for a drive train. I assume you mean a drive train because of the way you've described it. However, it's very easy with the weight limits of the FIRST competition to build a drive train that draws more than 40A from the 40A breakers powering the CIMs. I assume you've put the CIMs in the drive train on the 40A breakers if not...that's probably gonna need to be changed. If you start to draw more than 40A from the breakers you'll start getting into the area where the circuit breakers are starting to trip (they take a while to trip) and fairly randomly the breaker will open cutting the power till it cools off (the longer you wait, the longer generally it will work after that...if you start doing it all over again shortly after the breaker cools, it's already pretty hot, so you'll probably cut out again shortly).

To add to this you've get the safety limits of the Jaguar. The Jaguars are designed to basically provide 40A. They'll provide 60A for a short period, but then they'll start to cut you back. The circuit breakers will also start to cut off at some point after 40A. So sooner or later you'll have the Jaguars cutting you back or the circuit breaker cutting you off for a bit, but one way or another if your drive train is quite often passing more than 40A of current you'll be running on the edge of failure.

Keep in mind the Victors won't make the breakers stop cutting off if you draw more than the 40A either. However, the Victors won't reboot into the wrong mode or cut you back. With the Jaguars your driver might mistakenly think being cut back means try to push to go faster (running you right back into the very overload you want to avoid and possibly pushing the breaker into opening). Remember that your drivers probably can't see the cut off in progress unless you report it, so they'll assume they are slipping or something mechanical like that.

A simplistic indicator that you're pushing too much current is the CIM motors will get quite hot. I warn you now that the CIMs can get hot enough to burn you so be careful if you plan on touching them to check that.

3. You might have a circuit breaker(s) in your power distribution board that are a little more 'touchy'. I've seen some cases where a drive train is marginally close to the current limits and variance in the performance of the circuit breaker causes the breaker to open. Usually the breaker is just doing what it should (in fact better than normal), but for this purpose it might be undesirable. Might want to try some other breakers it's quick and simple, but remember that if you don't quickly isolate a few 'touchy' breakers you are too close to the limitations of the system and you need to address that instead.

4. Are you sure you wired the effected part of the system correctly? Are the connectors firmly connected? Was the right gauge wire used? Are the screws properly tightened (be careful not to remove or strip them, sometimes when you remove the Jaguar screws you get some SWARF! from the bottom of the hole the screw was in loose in the Jaguar). If you can put a load (like a light bulb) on the wiring and check the voltage drop you can check to see if your wiring can handle the load (obviously there's more to this check than what I've written here...I'd ask a mentor or ask for more information if you want it).

5. Are you properly ventilating the Jaguars? Remember they have a fan inside them and it's important they get ambient temperature air flow. If you don't provide this you can cook the Jaguars and that's gonna lead to trouble.


What I wrote about is probably what they were trying to communicate.
Below are some more reasons your Jaguars might lock up or stop working for a bit.


6. If you're using encoders on the Jaguar then you might be loosing track of them. That can cause issues so you might want to think about how fast your encoders rotate versus their resolution, whether you properly installed the U.S. Digital encoder wheels, or if the encoder is electronically producing a clean signal. I won't wander too far off on this, it's a possible problem but I have no idea if you have encoders at all.

7. It appears some of the CAN bus connectors on some of the newer Jaguars might have some quality control issues. You might want to check the pins to make sure they make good contact. Also, it's easy to make bad CAN wiring, you want to check that because if you have bad CAN wiring it can stop several or all of the Jaguars from communicating and that might be intermittent.

8. You might be communicating too quickly on the CAN bus. The 2CAN is able to sustain a higher communications rate than the RS232 to CAN bridge in the black Jaguars. It's possible to overwhelm the communications process with CAN. Obviously if you're not properly communicating with the Jaguars they'll probably not do what you expect.

9. You might have set up your PID loops with poor choices for the relevant settings. This assumes you are using the PID functionality. It's possible that if the PID loop was setup properly your electrical system might not pass so much current, or the result will be the movements you expect. I can think of quite a few systems where a properly functioning PID loop might avoid an overload, especially systems with finite mechanical limits (like arms where if you don't stop you hit the mechanical limit and overload the motor trying to go past it).

There are 9 hints hope that helps.

[JABot67]

I think you mean current not voltage (the battery voltage will generally get lower as you drive the robot).

There's a bunch of issues at work here:

1. The Jaguars and the Victors both reboot when the voltage of the battery gets too low (the battery can be too low because it needs to be charged, or because you are beating it down with heavy electrical loads). Victors, which use PWM only, will reboot fairly quickly and in some cases you might not even notice. The Jaguars using CAN can use quite a few modes and those modes have to be selected if they are not the defaults. If you use the Jaguars with PWM or the default mode on CAN (which performs a similar concept) when the voltage drops to a certain point (what is called a brown out) they come back up and just start working again (at least if you have the newest firmware they usually do). If you use another mode on CAN, then when they brown out you need to detect it and reset the mode. Problem is if you put an encoder on the Jaguar and it browns out...unless it's an absolute encoder...you'll loose track of the position of that encoder. Keep in mind that the brown out condition is not going to come back if the circuit breaker trips and hasn't yet reset.

2. You don't mention what you've got for a drive train. I assume you mean a drive train because of the way you've described it. However, it's very easy with the weight limits of the FIRST competition to build a drive train that draws more than 40A from the 40A breakers powering the CIMs. I assume you've put the CIMs in the drive train on the 40A breakers if not...that's probably gonna need to be changed. If you start to draw more than 40A from the breakers you'll start getting into the area where the circuit breakers are starting to trip (they take a while to trip) and fairly randomly the breaker will open cutting the power till it cools off (the longer you wait, the longer generally it will work after that...if you start doing it all over again shortly after the breaker cools, it's already pretty hot, so you'll probably cut out again shortly).

To add to this you've get the safety limits of the Jaguar. The Jaguars are designed to basically provide 40A. They'll provide 60A for a short period, but then they'll start to cut you back. The circuit breakers will also start to cut off at some point after 40A. So sooner or later you'll have the Jaguars cutting you back or the circuit breaker cutting you off for a bit...but one way or another if your drive train is quite often passing more than 40A of current you'll be running on the edge of failure.

Keep in mind, the Victors won't make the breakers stop cutting off if you draw more than the 40A either. However, the Victors won't reboot into the wrong mode or cut you back...which with the Jaguars your driver might mistakenly think means go faster (running you right back into the very overload you want to avoid and possibly pushing the breaker into opening).

A simplistic indicator that you're pushing too much current is the CIM motors will get quite hot. I warn you now that the CIMs can get hot enough to burn you so be careful if you plan on touching them to check that.

3. If you're using encoders on the Jaguar then you might be loosing track of them. That can cause issues so you might want to think about how fast your encoders rotate versus their resolution, whether you properly installed the U.S. Digital encoder wheels, or if the encoder is electronically producing a clean signal. I won't wander too far off on this, it's a possible problem but I have no idea if you have encoders at all.

4.

Thank you for giving us some detailed instructions. I will attempt to clarify our situation.

We use CAN and have been having a specific problem during our matches where some, most, or all of our Jaguars will cut out perhaps halfway to three fourths of the way through a match. This happens when we go from full forward to full reverse or vice versa.

We do believe this has something to do with the current spike that occurs when the Jaguars are trying to spin the motors in the opposite direction from where we're going. You said it was very possible to build a drivetrain that will draw more than 40 amps when switching directions. That may be so with our drivetrain, but we have tried switching directions on a single Window motor (with no load) attached to a Jaguar, and it still fails.

We set the Jaguars to brake mode in code, and we also tried setting the "automatic ramp" rate. This stops the errors from occurring; however, our drive becomes less maneuverable because when switching from forward to reverse, the robot's motors will still be running forward for a while. We have tried several ramp rate values, and none of them were good enough to be used in a match. (We got DQed in a match because we hit the opponents' bridge while they were balancing. Not sure if the lack of control caused that specific infraction, but there sure was a lack of control.)

Our drivetrain is a four wheel tank with AM supershifters. Nothing too ridiculous. We use encoders plugged into the Jaguars, but only use them in autonomous mode. Auton is not a problem for us.

Would a switch to PWM cables on Jaguars (perhaps with the jumpers set to ramp mode) allow us better control of the robot and at the same time allow us to compete for an entire match?

We just want to be able to go from full forward to full reverse and vice versa during a match without our speed controllers failing on us, in order to give our driver the slickest control possible. Is that too much to ask for?

[techhelpbb]

Thank you for giving us some detailed instructions. I will attempt to clarify our situation.

We use CAN and have been having a specific problem during our matches where some, most, or all of our Jaguars will cut out perhaps halfway to three fourths of the way through a match. This happens when we go from full forward to full reverse or vice versa.

We do believe this has something to do with the current spike that occurs when the Jaguars are trying to spin the motors in the opposite direction from where we're going. You said it was very possible to build a drivetrain that will draw more than 40 amps when switching directions. That may be so with our drivetrain, but we have tried switching directions on a single Window motor (with no load) attached to a Jaguar, and it still fails.

We set the Jaguars to brake mode in code, and we also tried setting the "automatic ramp" rate. This stops the errors from occurring; however, our drive becomes less maneuverable because when switching from forward to reverse, the robot's motors will still be running forward for a while. We have tried several ramp rate values, and none of them were good enough to be used in a match. (We got DQed in a match because we hit the opponents' bridge while they were balancing. Not sure if the lack of control caused that specific infraction, but there sure was a lack of control.)

Our drivetrain is a four wheel tank with AM supershifters. Nothing too ridiculous. We use encoders plugged into the Jaguars, but only use them in autonomous mode. Auton is not a problem for us.

Would a switch to PWM cables on Jaguars (perhaps with the jumpers set to ramp mode) allow us better control of the robot and at the same time allow us to compete for an entire match?

We just want to be able to go from full forward to full reverse and vice versa during a match without our speed controllers failing on us, in order to give our driver the slickest control possible. Is that too much to ask for?

When some or all of the Jaguars cut out, do they do it at the exact same moment? Could be an intermittent connection on the CAN bus. Are all the units you loose sequential in the CAN chain? Perhaps the forward and reverse shakes something loose.

When you tried the window motor did you use a fully charged battery? You know when you suddenly shift the direction of your possibly 130lb robot you have to fight all the mechanical momentum of the robot that was previously moving the other way. You absorb that extra force with a surge of power from your battery. The more you suddenly shift the direction as hard as possible the greater the surge. Hence why the automatic ramp helps because you slowly absorb that energy...not all at once. If you absorb too much energy (relate current to kinetic energy of electrons) all at once the potential energy of the battery (relate voltage to the potential number of electrons to move out of the chemical system in the battery) and then keep trying, your battery voltage will drop and that can cause a brownout which all or part of the system might notice and reset. On the other hand, that's a big rush of current and that current might trip the safety of the Jaguar or the circuit breaker as well. Of course it could be a combination of all those possible issues as well.

You know if there's nothing else wrong with the system you can write your own ramp in software.
You can even simulate the brake function in your own software.
The team I mentor does this frequently.

[JABot67]

When some or all of the Jaguars cut out, do they do it at the exact same moment?

Usually that is the case.

Are all the units you loose sequential in the CAN chain?

No, they can but are usually not sequential in the CAN chain.

When you tried the window motor did you use a fully charged battery?

Yes, we used a fully charged battery. We have experienced and characterized the issues that occur on the CAN bus when the battery power is low.

You know when you suddenly shift the direction of your possibly 130lb robot you have to fight all the mechanical momentum of the robot that was previously moving the other way. You absorb that extra force with a surge of power from your battery. The more you suddenly shift the direction as hard as possible the greater the surge.

The error occurs even when the robot is barely moving. Our driver knew about this issue in the competition yesterday and purposely tried to avoid throwing the weight of the robot around. During no point in the match did he try going full speed forward (actual robot speed, not the speed of the wheels) to full speed reverse. The error mostly occurred when he was trying to turn. Turning does not absorb as much energy as a sudden shift from full forward to backward.

Hence why the automatic ramp helps because you slowly absorb that energy...not all at once.

Is there a good value for the automatic ramp that allows us the maximum amount of control possible without causing damage or disablement of the Jaguars? We were unable to find a good value.

[RyanN]

I don't understand motors, electricity, etc. however I have a question on behalf of my team, and I think I'm wording this correctly.

Basically, we used CAN with Jaguars for our robot's drivetrain this year. Multiple times it stopped working during the match, and our team was seemingly able to determine that this was due to built-in protection on the Jaguar to stop, essentially, surges. It was happening when a large amount of voltage was sent through the Jaguar I believe, and our team said this wouldn't be an issue if we switched back to PWMs. It would usually happen if our driver was moving back and forth very quickly (e.g. the bridge.) Does anyone have an idea of what was happening or how this could be fixed?

I think our mentor, Steve Phillips, puts this situation in the best perspective...

Imaging you're in your car, driving down the freeway, at 70MPH. Then you decide you simply want to go into the opposite direction. You change from drive to reverse, and hit the gas. What's going to happen? Well, I'll tell you what isn't going to happen... you won't be going the direction you want to be going. What will happen is that you'll likely break a lot of stuff in your car.

Same concept applies here to robotics. You have a 120lb robot going at 15FPS. That's quite a bit of momentum built up. Your driver suddenly wants to go the other direction, and slams it into the other direction. First off, the motors are creating back EMF of about 12V, and plenty of current capability, you then tell the speed controller to apply -12V, and give it all the current it can. You have a difference of 24V now, right? Given that you're technically going over the stall current because of the back EMF, you're probably putting a load of 200+ Amps on the Jaguar. It simply cuts out for protection. The Victors don't have this protection built in. They'll try to back drive, and the only overcurrent protection they have are the 40A snap action breakers. If you didn't have those in the circuit, they would literally self destruct, and actually, I know we have had a few in the past self destruct because of the conditions you described.

The ramp mode will keep you from reaching the cut-out condition, but you'll lose some maneuverability. The best solution is to make sure the drivers remember this concept, or switch to Victors and use PWMs.

[johnmaguire2013]

I think our mentor, Steve Phillips, puts this situation in the best perspective...

Imaging you're in your car, driving down the freeway, at 70MPH. Then you decide you simply want to go into the opposite direction. You change from drive to reverse, and hit the gas. What's going to happen? Well, I'll tell you what isn't going to happen... you won't be going the direction you want to be going. What will happen is that you'll likely break a lot of stuff in your car.

Same concept applies here to robotics. You have a 120lb robot going at 15FPS. That's quite a bit of momentum built up. Your driver suddenly wants to go the other direction, and slams it into the other direction. First off, the motors are creating back EMF of about 12V, and plenty of current capability, you then tell the speed controller to apply -12V, and give it all the current it can. You have a difference of 24V now, right? Given that you're technically going over the stall current because of the back EMF, you're probably putting a load of 200+ Amps on the Jaguar. It simply cuts out for protection. The Victors don't have this protection built in. They'll try to back drive, and the only overcurrent protection they have are the 40A snap action breakers. If you didn't have those in the circuit, they would literally self destruct, and actually, I know we have had a few in the past self destruct because of the conditions you described.

The ramp mode will keep you from reaching the cut-out condition, but you'll lose some maneuverability. The best solution is to make sure the drivers remember this concept, or switch to Victors and use PWMs.

Even so, with ramping we had some major issues (again, we were unable to find a value which had a fair balance between maneuverability and not-breaking.) i.e. Our driver apparently had only tapped the backward button and it coasted backwards into a bridge (hence the DQ.) And that was not the only time he lost control of the robot.

[techhelpbb]

Usually that is the case.

No, they can but are usually not sequential in the CAN chain.


Then it's probably not the CAN bus loosing connection (could be CAN related in part but probably not a cable that just came off for a second).


Yes, we used a fully charged battery. We have experienced and characterized the issues that occur on the CAN bus when the battery power is low.


A fully charged battery with a Jaguar driving an unloaded window motor should not be having issues. If you're sure the window motor was not damaged, try another battery in case there's a subtle issue in the battery. If that still doesn't help, check the wiring cause that doesn't sound right at all.
That maybe be just one of the issues or it maybe the whole issue.


The error occurs even when the robot is barely moving. Our driver knew about this issue in the competition yesterday and purposely tried to avoid throwing the weight of the robot around. During no point in the match did he try going full speed forward (actual robot speed, not the speed of the wheels) to full speed reverse. The error mostly occurred when he was trying to turn. Turning does not absorb as much energy as a sudden shift from full forward to backward.


We had a 6 wheel, dropped center tank drive last year. After a few competitions the center wheel actually wore down. When it wore down it was no longer lower than the rest of the tires (it was now 1/8" smaller in diameter). All of the sudden the robot was trying to force all 6 tires to drag across the carpet.

Instant overload. Consider that situation with your robot.

I will again say, however, that mechanical issues with your drive train could be all or part of the problem.

Is there a good value for the automatic ramp that allows us the maximum amount of control possible without causing damage or disablement of the Jaguars? We were unable to find a good value.

Right idea, wrong path. It's not a value you seek. It's the speed with which you achieve that value. Current is the flow of energy over a period of time. The higher the current, the more energy you flow in the same period of time (derivative in calculus represents current, the ramping can be integration in calculus). Assuming that all you need is software to fix your problem, which means your drive train draws close to or below 40A normally you need to slowly increase towards your target value.

Basically what you need to figure out is how slowly you need to approach your target values. I can't tell you this 'magic' it depends on your system. I will tell you that if your system has: a mechanical issue, a bad battery, bad high current wiring, or can't be made to routinely stay near 40A you will have to accept some consequences. If your system draws too much current and you can't otherwise fix that you can limit how high you turn on the speed controls...but your driving performance might suffer. If your system draws too much current too quickly even with the most modest ramping of the speed controls then you must fix the system.

Again you don't have to use the automatic ramping, I don't and it wasn't available when my team used them.
We write software that basically tries to balance the performance we desire with the beating we'll be giving to the battery, the electronics, the wiring, the motors and the mechanisms.

Also keep in mind, that if you're routinely beating on the battery (even if the battery is not bad) it'll be okay for a short period then cave and it might be before the match ends. That might be why you had this happen at slow speed. All the hits to the battery before that depleted it. You've got to consider all the loose ends and it's tricky.

[JABot67]

We had a 6 wheel, dropped center tank drive last year. After a few competitions the center wheel actually wore down. When it wore down it was no longer lower than the rest of the tires (it was now 1/8" smaller in diameter). All of the sudden the robot was trying to force all 6 tires to drag across the carpet.

Instant overload. Consider that situation with your robot.

http://www.youtube.com/watch?v=Z4Id9IR_HCU

Consider this match video. It never seems like we are "beating on the battery". In fact, it looks like our driver is being very meek in this final match. Perhaps there was a problem from the very beginning, like a drive jaguar on both sides not working. However, our problem occurs around 1:20 in the video, when the right drive gives way.

We have omni wheels in the front of our robot that can be deployed for easier turning; they are deployed for the majority of the time except when we are pushing another robot, aiming to shoot, or trying to balance the bridge. When these omnis are deployed, only our back wheels are driven and we do not get a situation where a bunch of wheels are trying to drag across the carpet. Therefore, I believe that our drivetrain should not be demanding a ton from the Jaguars and the battery. Perhaps it is an electrical problem.

We will definitely work through this in the next couple weeks and find a solution. Thank you for helping us and pointing us in the correct direction. Nothin' like having a robot that almost works! :ahh:

[mikets]

Correct me if I am wrong. If the cause is really over current (not because of loose wires etc) and the breakers got cut off, your robot will be cut out no matter if you are using Jaguars or Victors (CAN or PWM for Jaguars). The only difference between Jaguars and Victrors (or CAN vs PWM) is that when the breaker resets, Victors (and Jaguars with PWM) will work again versus Jaguar with CAN may not work because its configuration has been cleared by the "brownout". If that is really the cause, software may be able to help to recover by detecting brownout and reconfiguring the Jaguars if necessary. We have written a wrapper class for CANJaguar (included below) that you can try. Caveat: This code is new and hasn't been tested extensively so use at your own risk. Unfortunately (or fortunately), we haven't really hit a brownout condition, so we don't know if the code works as intended. It is possible that we have hit brownouts and the code worked beautifully to recover that we did not even notice. We have added a "printf" in the recovery code path so it is supposed to print a warning to the net console if a brownout has been detected. We haven't noticed that warning but it's possible it's been drowned in the sea of debug printouts. It is also possible that our drive train design doesn't cause brownouts (e.g. weaker drive train). If you find bugs in the code, comments are welcome.
#if 0
/// Copyright (c) Titan Robotics Club. All rights reserved.
///
/// <module name="CanJag.h" />
///
/// <summary>
/// This module contains the definition and implementation of the
/// CanJag class.
/// </summary>
///
/// <remarks>
/// Environment: Wind River C++ for National Instrument cRIO based Robot.
/// </remarks>
#endif
#ifndef _CANJAG_H
#define _CANJAG_H
/**
* This class defines and implements the CanJag object. The CanJag object
* inherits from the CANJaguar object in the WPI library. It basically wraps
* the CANJaguar class so it can shadow all the volatile Jaguar configuration
* parameters. If the Jaguar ever browns out, we will be able to restore the
* Jaguar configurations.
*/
class CanJag: public CANJaguar
{
private:
UINT16 m_encoderLines;
UINT16 m_potTurns;
float m_faultTime;
NeutralMode m_neutralMode;
double m_fwdLimitPos;
double m_revLimitPos;
double m_voltRampRate;
SpeedReference m_speedRef;
PositionReference m_posRef;
double m_Kp;
double m_Ki;
double m_Kd;
float m_motorValue;
double m_position;
double m_speed;
/**
* This funcion checks if a power cycle has occurred. If so, it will
* reconfigure the Jaguar with the shadowed information.
*
* @return Returns true if the Jaguar has been power cycled since we
* check last.
*/
bool
CheckPowerCycled(
void
)
{
bool fPowerCycled = GetPowerCycled();
if (fPowerCycled)
{
//
// Jaguar has lost power, restore configuration appropriately.
//
printf("Detected brownout on Jag %d.", m_deviceNumber);
CANJaguar::ChangeControlMode(m_controlMode);
if (m_controlMode == kPosition)
{
CANJaguar::SetPID(m_Kp, m_Ki, m_Kd);
CANJaguar::SetPositionReference(m_posRef);
if (m_posRef == kPosRef_QuadEncoder)
{
CANJaguar::ConfigEncoderCodesPerRev(m_encoderLines );
}
else if (m_posRef == kPosRef_Potentiometer)
{
CANJaguar::ConfigPotentiometerTurns(m_potTurns);
}
}
else if (m_controlMode == kSpeed)
{
CANJaguar::SetPID(m_Kp, m_Ki, m_Kd);
CANJaguar::SetSpeedReference(m_speedRef);
if (m_speedRef != kSpeedRef_None)
{
CANJaguar::ConfigEncoderCodesPerRev(m_encoderLines );
}
}
else if (m_controlMode == kCurrent)
{
CANJaguar::SetPID(m_Kp, m_Ki, m_Kd);
}
if (m_maxOutputVoltage > 0.0)
{
CANJaguar::ConfigMaxOutputVoltage(m_maxOutputVolta ge);
}
if (m_faultTime > 0.0)
{
CANJaguar::ConfigFaultTime(m_faultTime);
}
if (m_neutralMode != kNeutralMode_Jumper)
{
CANJaguar::ConfigNeutralMode(m_neutralMode);
}
if (m_fwdLimitPos == 0.0 && m_revLimitPos == 0.0)
{
CANJaguar::DisableSoftPositionLimits();
}
else
{
CANJaguar::ConfigSoftPositionLimits(m_fwdLimitPos,
m_revLimitPos);
}
if (m_voltRampRate > 0.0)
{
CANJaguar::SetVoltageRampRate(m_voltRampRate);
}
CANJaguar::EnableControl();
}
return fPowerCycled;
} //CheckPowerCycled
public:
/**
* Constructor: Create an instance of the CanJag object that inherits
* the CANJaguar class.
*
* @param deviceNumber Specifies the CAN ID for the device.
* @param controlMode Specifies the control mode to set the device to.
*/
CanJag(
UINT8 deviceNumber,
ControlMode controlMode = kPercentVbus
): CANJaguar(deviceNumber, controlMode),
m_encoderLines(0),
m_potTurns(0),
m_faultTime(0.0),
m_neutralMode(kNeutralMode_Jumper),
m_fwdLimitPos(0.0),
m_revLimitPos(0.0),
m_voltRampRate(0.0),
m_speedRef(kSpeedRef_None),
m_posRef(kPosRef_None),
m_Kp(0.0),
m_Ki(0.0),
m_Kd(0.0),
m_motorValue(0.0),
m_position(0.0),
m_speed(0.0)
{
if (controlMode == kSpeed)
{
m_speedRef = GetSpeedReference();
m_Kp = GetP();
m_Ki = GetI();
m_Kd = GetD();
}
else if (controlMode == kPosition)
{
m_posRef = GetPositionReference();
m_Kp = GetP();
m_Ki = GetI();
m_Kd = GetD();
}
else if (controlMode == kCurrent)
{
m_Kp = GetP();
m_Ki = GetI();
m_Kd = GetD();
}
m_motorValue = CANJaguar::Get();
m_position = CANJaguar::GetPosition();
m_speed = CANJaguar::GetSpeed();
//
// Clear the power cycled flag.
//
GetPowerCycled();
} //CanJag
/**
* Destructor: Destroy an instance of the CanJag object.
*/
virtual
~CanJag(
void
)
{
} //~CanJag
/**
* This function sets the motor power.
*
* @param value Specifies the motor power.
* @param syncGroup Optionally specifies the syncgroup of the motor.
*/
void
Set(
float value,
UINT8 syncGroup = 0
)
{
CheckPowerCycled();
if (value != m_motorValue)
{
m_motorValue = value;
CANJaguar::Set(value, syncGroup);
}
} //Set
/**
* This function sets the reference source device for speed control mode.
*
* @param reference Specifies the reference device.
*/
void
SetSpeedReference(
SpeedReference reference
)
{
m_speedRef = reference;
CANJaguar::SetSpeedReference(reference);
} //SetSpeedReference
/**
* This function sets the reference source device for position control mode.
*
* @param reference Specifies the reference device.
*/
void
SetPositionReference(
PositionReference reference
)
{
m_posRef = reference;
CANJaguar::SetPositionReference(reference);
} //SetPositionReference
/**
* This function sets the PID constants for the closed loop modes.
*
* @param Kp Specifies the P constant.
* @param Ki SPecifies the I constant.
* @param Kd Specifies the D constant.
*/
void
SetPID(
double Kp,
double Ki,
double Kd
)
{
m_Kp = Kp;
m_Ki = Ki;
m_Kd = Kd;
CANJaguar::SetPID(Kp, Ki, Kd);
} //SetPID
/**
* This function sets the maximum voltage change rate.
*
* @param rampRate Specifies the max voltage ramp rate.
*/
void
SetVoltageRampRate(
double rampRate
)
{
m_voltRampRate = rampRate;
CANJaguar::SetVoltageRampRate(rampRate);
} //SetVoltageRampRate
/**
* This function configures the neutral mode.
*
* @param mode Specifies the neutral mode.
*/
void
ConfigNeutralMode(
NeutralMode mode
)
{
m_neutralMode = mode;
CANJaguar::ConfigNeutralMode(mode);
} //ConfigNeutralMode
/**
* This function configures the number of encoder lines per revolution.
*
* @param encoderLines Specifies the number of encoder lines per rev.
*/
void
ConfigEncoderCodesPerRev(
UINT16 encoderLines
)
{
m_encoderLines = encoderLines;
CANJaguar::ConfigEncoderCodesPerRev(encoderLines);
} //ConfigEncoderCodesPerRev
/**
* This function configures the number of turns of the potentiometer.
*
* @param turns Specifies the number of turns of the potentiometer.
*/
void
ConfigPotentiometerTurns(
UINT16 turns
)
{
m_potTurns = turns;
CANJaguar::ConfigPotentiometerTurns(turns);
} //ConfigPotentiometerTurns
/**
* This function configures the forward and reverse position limits.
*
* @param fwdLimitPos Specifies the forward limit position.
* @param revLimitPos Specifies the reverse limit position.
*/
void
ConfigSoftPositionLimits(
double fwdLimitPos,
double revLimitPos
)
{
m_fwdLimitPos = fwdLimitPos;
m_revLimitPos = revLimitPos;
CANJaguar::ConfigSoftPositionLimits(fwdLimitPos, revLimitPos);
} //ConfigSoftPositionLimits
/**
* This function disables soft position limits.
*/
void
DisableSoftPositionLimits(
void
)
{
m_revLimitPos = 0.0;
CANJaguar::DisableSoftPositionLimits();
} //DisableSoftPositionLimits
/**
* This function configures how long the Jaguar waits in the case of a
* fault before resuming operation.
*
* @param faultTime Specifies the fault time.
*/
void
ConfigFaultTime(
float faultTime
)
{
m_faultTime = faultTime;
CANJaguar::ConfigFaultTime(faultTime);
} //ConfigFaultTime
/**
* This function gets the motor position from the Jaguar controller.
*
* @return Returns the motor position.
*/
double
GetPosition(
void
)
{
m_position = CANJaguar::GetPosition();
return m_position;
} //GetPosition
/**
* This function gets the motor speed from the Jaguar controller.
*
* @return Returns the motor speed.
*/
double
GetSpeed(
void
)
{
m_speed = CANJaguar::GetSpeed();
return m_speed;
} //GetSpeed
}; //class CanJag
#endif //ifndef _CANJAG_H

[techhelpbb]

http://www.youtube.com/watch?v=Z4Id9IR_HCU

Consider this match video. It never seems like we are "beating on the battery". In fact, it looks like our driver is being very meek in this final match. Perhaps there was a problem from the very beginning, like a drive jaguar on both sides not working. However, our problem occurs around 1:20 in the video, when the right drive gives way.

We have omni wheels in the front of our robot that can be deployed for easier turning; they are deployed for the majority of the time except when we are pushing another robot, aiming to shoot, or trying to balance the bridge. When these omnis are deployed, only our back wheels are driven and we do not get a situation where a bunch of wheels are trying to drag across the carpet. Therefore, I believe that our drivetrain should not be demanding a ton from the Jaguars and the battery. Perhaps it is an electrical problem.

We will definitely work through this in the next couple weeks and find a solution. Thank you for helping us and pointing us in the correct direction. Nothin' like having a robot that almost works! :ahh:

The problem with this analysis is that it assumes that the only forces that act on the drive train are a driver with a 'lead foot'.

You could have a misalignment, a jammed chain, a stuck bearing (or no bearings), a jammed wheel, or even something wedged in your gear boxes.

It's not just a question of physical speed, there's also torques and accelerations versus momentums and inertia.

You can read the Jaguars to get the current so I'd put it up on blocks, run it and see how much current you flow like that. Then put it on similar carpet and try it. Also if you have the tools you can measure the current with your own small high wattage resistor in series and a voltmeter or even a DC compatible clamp on current probe if you doubt the Jaguars (just remember that that resistor must be small or it'll lower the performance of the Jaguar and motor by you adding it).

Also I should point out that last year we did have a pair of bad CIM motors. So you might want to try some other CIMs, perhaps you have one with an issue (they are pretty reliable but it happens).

[techhelpbb]

Correct me if I am wrong. If the cause is really over current (not because of loose wires etc) and the breakers got cut off, your robot will be cut out no matter if you are using Jaguars or Victors (CAN or PWM for Jaguars). The only difference between Jaguars and Victrors (or CAN vs PWM) is that when the breaker resets, Victors (and Jaguars with PWM) will work again versus Jaguar with CAN may not work because its configuration has been cleared by the "brownout". If that is really the cause, software may be able to help to recover by detecting brownout and reconfiguring the Jaguars if necessary.

I really do like this effort and the value it adds.

However, there is a slight catch. If the system often browns-out the problem will degrade the battery charge and possibly the battery life.

So this is absolutely great for situations where something unusual happens and the drive train is operating within a reasonable range, but it's no fix for a drive train that often draws too much current under normal operation. If a drive train can't move forward on a flat rug surface without any interference and without flowing 60A all this will do is buy you a little time. Maybe you can use it to extend things to the end of a match for a design pushing just past the limit but it'll have consequences later.

[mikets]

Agreed. Software recovery is meant to safeguard rare occassions that browned out Jags such as short stall situatoins. If this happens a lot in normal operations, it must be root caused and fixed.

[mjcoss]

We had a similar issue last year with our lifter mechanism. It was strictly a mechanical issue. The motors were really on the ragged edge of being able to run the lifter smoothly over the entire range of motion. To help the drivers avoid burning out the motor, we added to our dashboard a current graph. We polled the Jaguars for the current, and had a nice chart. If we saw it going into the red zone (> 40 amps) for any extended period, the driver could dial back on the motor. This detected stalls and binds in the lifter, and had nothing to do with the Jaguars or CAN bus other than to give us the ability to peer into them and see what was happening.

[RyanN]

We are using CAN and used them as well last year. My concerns are the introduction of a single point of failure (2CAN), and the side effects of the safety features of the Jaguars. In a properly running system, the Jaguars run fine, and don't brown out. BUT this is a robotic competition, and bad things happen.

There has been persistent issues with timeouts. Some claim it's all just bad wiring on the part of teams, others claim that the CRIO/CAN driver is to blame, others that the 2CAN is the issue, and others that the Jaguars are bad. The upshot is that we have a number of components and lot a software in between.

One thing that I stumbled upon lst year was that if a CAN bus message timed out, the caller (in C++) receives no indication that an error occurred. This results in the CAN request returning valid (0) but incorrect data. So the test GetForwardLimitOK will return false on a timeout'd request. This can wreak havoc on code that is unaware of the issue.

We've been messing with CAN a bit this week in some testing and validation of our code. I'm using a home made Serial to Jaguar cable since our good one is bagged up with the robot. We're getting tons of CAN bus time out errors, but it doesn't seem to have any effect on the output. We're setting 4 motors every 10ms and using the Update Sync Group command. I don't think 10ms is too short of a time frame, but I may be wrong. We can probably increase it to about 50ms without any adverse effects. It's in a closed PID control loop.

We also did some reliability testing today as well... with the 4 motors setup and running, we yanked one of the cables out. No matter the position on the bus, all motors faulted, and stopped the output, which is a GOOD thing... at least in our case with all 4 motors driving the same device. Upon connecting the cable, the system got its act together in a seemingly short amount of time and was output power within a second of reconnecting. Seems good. Yanking the cable had immediate effects, but simply pulling the breaker seemed to output power for half a second or so before faulting. Not too bad, but not what I would like to see.

We're still on the "CAN is cool and all, but we don't trust it yet" phase. We're using it for one function on our robot, while all other functions rely on other means of control.

The 4 motors are controlled in a loop placed within periodic tasks, and they are only called there, so there are no floating calls elsewhere in the code to cause data intersections.

I can try to slow down the loop a bit, but really, I'm not too worried about it at this point.

Our code running on our simulation test bench is using about 75% of the CPU usage, and everything is running nice and smooth. We'll see how it is on the real robot later this week.

[Superllama12]

This is our second year using it, and we really like it. Electrically, it's neater (no more spaghetti all over) and less likely to catch on stuff, so the Jags stay connected during the whole round. Our only issue has been the single point-of-failure, but it's pretty easy to figure out which Jag/cable is a problem. Overall, I like it a lot better, and I'm very glad we've used it for the past two years

[Brian Selle]

This is our first year using CAN. After reading through all the forums it was my gut feel that CAN was the way to go for the future. The ability to monitor the jaguars, PID hardware loop, adjustable voltage ramp, and the wire organization mentioned earlier were our main reasons. As FRC CAN matures it's my understanding that there will be more features available.

We decided to give CAN a try with the idea that we can always go back to PWM. After reading about the update rate issues with the serial cable we went with a 2CAN so we wouldn't have to worry about it. I certainly can't say the implementation of CAN has gone without a hitch. We have stumbled across several of the issues (firmware download locked up a jag on Windows 7 - now fixed, bent RJ11 socket pins on the jaguar - Home Depot RJ11 plugs fit too tight, bad cords, etc).

The support we received from Mike C. at Cross The Road Electronics was unbelievable. Dare I say almost too good. When we were frustrated and thought about going back to PWM, he kept us in the game.

We are currently running 9 jaguars and have used almost all the available jaguar/CAN features at one time or another. I'm happy we took the leap.

[jwakeman]

This is our first year using CAN. After reading through all the forums it was my gut feel that CAN was the way to go for the future. The ability to monitor the jaguars, PID hardware loop, adjustable voltage ramp, and the wire organization mentioned earlier were our main reasons. As FRC CAN matures it's my understanding that there will be more features available.

We decided to give CAN a try with the idea that we can always go back to PWM. After reading about the update rate issues with the serial cable we went with a 2CAN so we wouldn't have to worry about it. I certainly can't say the implementation of CAN has gone without a hitch. We have stumbled across several of the issues (firmware download locked up a jag on Windows 7 - now fixed, bent RJ11 socket pins on the jaguar - Home Depot RJ11 plugs fit too tight, bad cords, etc).

The support we received from Mike C. at Cross The Road Electronics was unbelievable. Dare I say almost too good. When we were frustrated and thought about going back to PWM, he kept us in the game.

We are currently running 9 jaguars and have used almost all the available jaguar/CAN features at one time or another. I'm happy we took the leap.

Very similar experience and I agree.

[Levansic]

I took an informal poll at the LA regional this weekend, and ~35% of the teams I talked with we're using CAN in some form. Generally, more established teams were more likely to use it, while young or rookie teams were far less likely to try.

There were some interesting usage philosophies between the teams. All of the teams that I talked with that used CAN, were also using PWM on their robots in some capacity. Usually, but not always, the PWM controllers on robots using CAN were Victors.

Specifically, team 294 used CAN control "everywhere that matters", meaning drive, bridge tipper, and shooter. They use PWM with Victors on their ball elevator, to save weight. Conversely, I was told by a student on 330, that they use PWM for their tank drive, and CAN for their bridge tipper and shooter. They use a black jaguar as a serial to CAN bridge, and felt that using CAN for those parts was essential, as they took advantage of the closed loop modes.

I heard some complaints from students about perceived unreliability of CAN, but still saw it employed on their robot. My observation was that the rail at the center of the field, or more properly the impacts with that rail, caused the majority of component and system failures, regardless of which control method was chosen.

One other observation I had was that poor design choices would lead teams on a quixotic search for scapegoat components. I saw quite a few 4-wheel tank drives that could go forward and back just fine, but would stall their CIM motors when attempting to turn. No doubt, it may have worked adequately on linoleum at home, but not on the competition carpet. Low gear ratios coupled with high-friction contact points at the corners colluded to make their drive systems into current sinks, causing system-wide brown-outs. Unfortunately, this is probably how some of the Jaguar naysayers got started.

[techhelpbb]

One other observation I had was that poor design choices would lead teams on a quixotic search for scapegoat components. I saw quite a few 4-wheel tank drives that could go forward and back just fine, but would stall their CIM motors when attempting to turn. No doubt, it may have worked adequately on linoleum at home, but not on the competition carpet. Low gear ratios coupled with high-friction contact points at the corners colluded to make their drive systems into current sinks, causing system-wide brown-outs. Unfortunately, this is probably how some of the Jaguar naysayers got started.

In all fairness the documentation of all the common troubleshooting and key design issues is strewn throughout this site. Previous firmware under the brownout conditions would stand an excellent chance of outright lock-up. Further there are still unresolved issues such as timeouts that haven't been adequately addressed so far as I am concerned (you can easily experience timeouts and still use CAN). As I built an entire robot myself at my cost to test them, I'm not bashing the Jaguars, but I am pointing out that not all the criticism that targets the Jaguar is undeserved. Even if some of the robots have poor design choices. One can easily make subtle poor design choices merely using the pre-built drive train components from AndyMark and a perfectly valid wheel system that will easily overload the Jaguars but the Victors will endure (it's not good for them either).

Each of these speed controls has a place. There's no reason they can't co-exist. The Jaguars do not lend themselves to situations where you don't have the time or the resources to focus on them. So, as I've pointed out elsewhere, it's not very surprising to me that newer teams would avoid them. Then again it's not entirely true the Victors are better, but they are very much like simple heavy-duty RC car speed controls (so the students are very likely to really relate to that).

I can only say further that to me a competition such as FIRST FRC is a capable enough place that we can all do things moderately differently without breaking out the 'cookie cutter'. I just hope that people don't camp on these ideas with polarity because this is very much about science and engineering and that's not necessary. I, for one, think that documentation and proactive effort on the part of the community and manufacturers would dramatically reduce a great deal of the undeserved bad reputation that Jaguars do get unfairly (I can't and won't deny that it does happen and it's unfortunate regardless of how it happens).

[Levansic]

I should have clarified. Most of the poor design choices were on rookie team robots, and the brown-outs we're not specific to the jaguars only. There were lots of conspiring issues, for quite a few teams. All were searching for a singular cause of their frustrations, when there seemed to never be just one cause. The student who complained about CAN could not cite an example of the "problems" when pressed. I suspect he was just parroting a mentor or another team member. Still, their robot functioned without fault.

My team was not competing in LA. We ran the practice station, so we saw many of these issues come through, accompanied with the anxiety to just get the robot to work reliably.

In another thread in the electrical forum, there were complaints about the field system. We didn't have problems on the practice field, but many teams had on-field failures of the radio links. Quite a few came back to the practice field trying to diagnose their problems. Some were genuine power supply issues, but not one team noticed or mentioned that there were over a dozen active Wi-fi networks in the half of the arena where the competition field was.

My point is that the cause of failures is many and varried. Often convenience and relying on hearsay causes the finger of blame to point to one component or technology, when a more thorough examination without preconceptions will unearth the true cause of problems.

[techhelpbb]

In another thread in the electrical forum, there were complaints about the field system. We didn't have problems on the practice field, but many teams had on-field failures of the radio links. Quite a few came back to the practice field trying to diagnose their problems. Some were genuine power supply issues, but not one team noticed or mentioned that there were over a dozen active Wi-fi networks in the half of the arena where the competition field was.

My point is that the cause of failures is many and varried. Often convenience and relying on hearsay causes the finger of blame to point to one component or technology, when a more thorough examination without preconceptions will unearth the true cause of problems.

I totally agree about the number of WiFi networks at the events. It's really crazy compared to the normal density of networks even in a place like downtown Manhattan. There are easy ways to get a feel for it, given the number of 'smart phones' available, there are Android and iOS apps that can show you the networks and their respective strengths. Many are free.

During the one event we had trouble at last year there were at least 10 networks sitting on the default channel according to my Android copy of WiFi analyzer. Not sure how or why that was allowed to happen. There was a time when a person with a Agilent spectrum analyzer would sit right near the field to watch for stuff like this.

Additionally you are absolutely right, an open mind is the best policy in the absence of quantifiable evidence of an issue.

[mjcoss]

In another thread in the electrical forum, there were complaints about the field system. We didn't have problems on the practice field, but many teams had on-field failures of the radio links. Quite a few came back to the practice field trying to diagnose their problems. Some were genuine power supply issues, but not one team noticed or mentioned that there were over a dozen active Wi-fi networks in the half of the arena where the competition field was.

My point is that the cause of failures is many and varried. Often convenience and relying on hearsay causes the finger of blame to point to one component or technology, when a more thorough examination without preconceptions will unearth the true cause of problems.

In my opinion, the field issues has little to due with the other networks, although it will make the problem worse. FIRST has set it up such that teams can inadvertently saturate the field network. The camera can, and on the newer cRIO must be, connected to the DLINK, and the driver station can access the camera directly, bypassing the cRIO. This allows for streaming video from the camera with no compression, and at its highest rate, i.e. 640x480 @ 30 frames a second. It only takes a couple of robots stream video this way to saturate the field. Add to it that you can send data back and froth from the driver station to the cRIO via open unregulated ports, and you have a recipe for bad field behavior. In addition, 802.11n is susceptible to interference from other networks notably 802.11g, and this will reduce the overall data rates achieved. Also, the default code locks the periodic loops to the arrival time of driver station packets. If the network is congested, the jitter and latency of packet arrivals will be awful causing stuttering and unresponsive robots. While on the practice field or at your build site things will be fine. We have toned down our usage of the back channels to try a minimize our impact on the field, but this is a real issue and hopefully at some point FIRST will try to do something about it.

[Alan Anderson]

FIRST has set it up such that teams can inadvertently saturate the field network. The camera can, and on the newer cRIO must be, connected to the DLINK, and the driver station can access the camera directly, bypassing the cRIO. This allows for streaming video from the camera with no compression, and at its highest rate, i.e. 640x480 @ 30 frames a second. It only takes a couple of robots stream video this way to saturate the field. Add to it that you can send data back and froth from the driver station to the cRIO via open unregulated ports, and you have a recipe for bad field behavior.

You might not be aware that the field access point creates six independent wireless networks, one for each team. One robot's network usage is not at the expense of the other robots' bandwidth. Too much streaming video from a robot can bog down its team's Driver Station, but it won't mess with other teams.

In addition, 802.11n is susceptible to interference from other networks notably 802.11g, and this will reduce the overall data rates achieved.

Doesn't the field wireless use 802.11n on 5 GHz? 802.11g is on 2.4 GHz and shouldn't interfere with that.

[mjcoss]

You're right that if they are running at 5 Ghz (which they should be), then they should be isolated from other networks running at 2.4 Ghz, but not other 5 Ghz networks in use. And while they may be running each team on a separate channel, there *appears* to be an issue that is correlated to the number of camera feeds streaming on the field.

I noticed this phenomenon last year, and it seems to be worse this year. I may have jumped to the wrong conclusion but I think that someone should be looking with a network analyzer to see what is really happening on the field during matches with various compositions of streamers, and/or robots making use of the open channels from/to the cRIO, the dashboard, and the driver station.

[techhelpbb]

http://www.chiefdelphi.com/forums/showthread.php?p=1137769#post1137769

There was a discussion about the field issues and connectivity in this topic as well, I'm providing it for reference because troubleshooting tools were discussed that didn't exist last year.

See Greg McKaskle's post at the bottom of the first page.