Go to Post Disclaimer: I am not an electrical engineer nor an electrician. I occasionally play one on CD. And when inspecting robots, sort of... - jvriezen [more]
Home
Go Back   Chief Delphi > Technical > Electrical > CAN
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 04-03-2012, 11:54
johnmaguire2013's Avatar
johnmaguire2013 johnmaguire2013 is offline
Harps On Websites
AKA: John Maguire
FRC #3322 (Eagle Imperium)
Team Role: Webmaster
 
Join Date: Jan 2011
Rookie Year: 2011
Location: Ann Arbor, MI
Posts: 74
johnmaguire2013 is an unknown quantity at this point
Re: Your take on CAN...

Quote:
Originally Posted by RyanN View Post
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.
__________________
John Maguire
Website Team | PR/Marketing Team
FRC Team 3322 - Eagle Imperium | My Blog
Reply With Quote
  #17   Spotlight this post!  
Unread 04-03-2012, 12:17
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Your take on CAN...

Quote:
Originally Posted by JABot67 View Post
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).

Quote:
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.

Quote:
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.

Quote:
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.

Last edited by techhelpbb : 04-03-2012 at 12:28.
Reply With Quote
  #18   Spotlight this post!  
Unread 04-03-2012, 13:01
JABot67 JABot67 is online now
Unregistered User
AKA: John Bottenberg
FRC #2930 (Sonic Squirrels)
Team Role: Engineer
 
Join Date: Feb 2009
Rookie Year: 2007
Location: Redmond, WA
Posts: 330
JABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond reputeJABot67 has a reputation beyond repute
Re: Your take on CAN...

Quote:
Originally Posted by techhelpbb View Post
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!
__________________
John Bottenberg - University of Michigan '14 - Microsoft
FLL Team "Dark Matter": 2003-2005
Robofest Team "Dark Matter": 2005-2008
Team 67 Programmer: 2007-2010
Team 3322 Programming Mentor: 2012-2014
Team 2930 Engineering Mentor: 2015-????
Reply With Quote
  #19   Spotlight this post!  
Unread 04-03-2012, 15:26
mikets's Avatar
mikets mikets is online now
Software Engineer
FRC #0492 (Titan Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Bellevue, WA
Posts: 675
mikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of light
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
__________________
Reply With Quote
  #20   Spotlight this post!  
Unread 04-03-2012, 19:19
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Your take on CAN...

Quote:
Originally Posted by JABot67 View Post
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!
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).
Reply With Quote
  #21   Spotlight this post!  
Unread 04-03-2012, 19:27
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Your take on CAN...

Quote:
Originally Posted by mikets View Post
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.
Reply With Quote
  #22   Spotlight this post!  
Unread 04-03-2012, 21:20
mikets's Avatar
mikets mikets is online now
Software Engineer
FRC #0492 (Titan Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Bellevue, WA
Posts: 675
mikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of light
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.
__________________
Reply With Quote
  #23   Spotlight this post!  
Unread 06-03-2012, 18:05
mjcoss mjcoss is offline
Registered User
FRC #0303
 
Join Date: Jan 2009
Location: Bridgewater,NJ
Posts: 70
mjcoss is a jewel in the roughmjcoss is a jewel in the roughmjcoss is a jewel in the roughmjcoss is a jewel in the rough
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.
Reply With Quote
  #24   Spotlight this post!  
Unread 14-03-2012, 02:33
RyanN's Avatar
RyanN RyanN is offline
RyanN
AKA: Ryan Nazaretian
no team
Team Role: Mentor
 
Join Date: Jun 2006
Rookie Year: 2005
Location: Austin, TX
Posts: 1,127
RyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond reputeRyanN has a reputation beyond repute
Re: Your take on CAN...

Quote:
Originally Posted by mjcoss View Post
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.
__________________
Taking a break from mentoring for a few years. (Is that allowed?!?)

Controls Mentor
@rnazaretian

Previous teams:
Team Fusion, FRC 364
Garnet Squadron, FRC 4901

Last edited by RyanN : 14-03-2012 at 02:36.
Reply With Quote
  #25   Spotlight this post!  
Unread 14-03-2012, 08:57
Superllama12's Avatar
Superllama12 Superllama12 is offline
Wombaticus
AKA: Brandon Buncher
FRC #0540 (Talon 540)
Team Role: Electrical
 
Join Date: Jan 2011
Rookie Year: 2004
Location: Henrico, VA
Posts: 150
Superllama12 is an unknown quantity at this point
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
__________________
I would put a signature here, but that's too mainstream

Wait a moment...
Reply With Quote
  #26   Spotlight this post!  
Unread 14-03-2012, 12:30
Brian Selle's Avatar
Brian Selle Brian Selle is offline
Mentor
FRC #3310 (Black Hawk Robotics)
Team Role: Engineer
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Texas
Posts: 170
Brian Selle has a spectacular aura aboutBrian Selle has a spectacular aura aboutBrian Selle has a spectacular aura about
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.
Reply With Quote
  #27   Spotlight this post!  
Unread 15-03-2012, 14:21
jwakeman jwakeman is offline
Registered User
FRC #0063 (Red Barons)
Team Role: Mentor
 
Join Date: Jan 2011
Rookie Year: 2010
Location: 16510
Posts: 182
jwakeman is just really nicejwakeman is just really nicejwakeman is just really nicejwakeman is just really nicejwakeman is just really nice
Re: Your take on CAN...

Quote:
Originally Posted by btslaser View Post
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.
Reply With Quote
  #28   Spotlight this post!  
Unread 20-03-2012, 00:39
Levansic's Avatar
Levansic Levansic is offline
Registered User
AKA: Len Evansic
FRC #0585 (Cyber Penguins)
Team Role: Mentor
 
Join Date: Jan 2012
Rookie Year: 2008
Location: Tehachapi, CA
Posts: 185
Levansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud of
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.
Reply With Quote
  #29   Spotlight this post!  
Unread 20-03-2012, 08:50
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Your take on CAN...

Quote:
Originally Posted by Levansic View Post
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).

Last edited by techhelpbb : 20-03-2012 at 09:02.
Reply With Quote
  #30   Spotlight this post!  
Unread 20-03-2012, 09:58
Levansic's Avatar
Levansic Levansic is offline
Registered User
AKA: Len Evansic
FRC #0585 (Cyber Penguins)
Team Role: Mentor
 
Join Date: Jan 2012
Rookie Year: 2008
Location: Tehachapi, CA
Posts: 185
Levansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud ofLevansic has much to be proud of
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.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 19:57.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi