|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
|||||
|
|||||
|
Re: Your take on CAN...
Quote:
|
|
#17
|
||||
|
||||
|
Re: Your take on CAN...
Quote:
Quote:
That maybe be just one of the issues or it maybe the whole issue. Quote:
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. Quote:
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. Last edited by techhelpbb : 04-03-2012 at 12:28. |
|
#18
|
|||
|
|||
|
Re: Your take on CAN...
Quote:
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! ![]() |
|
#19
|
||||
|
||||
|
Re: Your take on CAN...
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.
Code:
#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_maxOutputVoltage);
}
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
|
|
#20
|
||||
|
||||
|
Re: Your take on CAN...
Quote:
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). |
|
#21
|
||||
|
||||
|
Re: Your take on CAN...
Quote:
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. |
|
#22
|
||||
|
||||
|
Re: Your take on CAN...
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.
|
|
#23
|
|||
|
|||
|
Re: Your take on CAN...
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.
|
|
#24
|
||||
|
||||
|
Re: Your take on CAN...
Quote:
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. Last edited by RyanN : 14-03-2012 at 02:36. |
|
#25
|
||||
|
||||
|
Re: Your take on CAN...
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
|
|
#26
|
||||
|
||||
|
Re: Your take on CAN...
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. |
|
#27
|
|||
|
|||
|
Re: Your take on CAN...
Quote:
|
|
#28
|
||||
|
||||
|
Re: Your take on CAN...
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. Last edited by Levansic : 20-03-2012 at 00:50. |
|
#29
|
||||
|
||||
|
Re: Your take on CAN...
Quote:
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). Last edited by techhelpbb : 20-03-2012 at 09:02. |
|
#30
|
||||
|
||||
|
Re: Your take on CAN...
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|