View Full Version : Jaguar Speed & Position Control with Encoders
DavisDad
26-12-2013, 08:06
Last year we tried to use the Jaguar Motor Controller's position and speed control functions in our Ultimate Accent bot. We got the BDC-COMM utility to work but couldn't work out the "C" programming.
We've had good success on the FTC team using the Matrix motor controller and would like to achieve a similar performance with Jaguars.
I'd appreciate any feedback or point me to a thread where this is discussed.
brennonbrimhall
26-12-2013, 14:14
We got the BDC-COMM utility to work but couldn't work out the "C" programming.
I'm going to operate with the assumption that by "C programming," you mean the C++ programming on the cRIO.
While we use Java, that should be similar to the API we use, which can be found here (http://lcec.us/javadoc/) for all of the classes used in WPILibJ, or here (http://lcec.us/javadoc/edu/wpi/first/wpilibj/CANJaguar.html) for the CANJag class.
Does anyone know of similar documentation for C++?
DavisDad
26-12-2013, 16:38
I'm going to operate with the assumption that by "C programming," you mean the C++ programming on the cRIO.
While we use Java, that should be similar to the API we use, which can be found here (http://lcec.us/javadoc/) for all of the classes used in WPILibJ, or here (http://lcec.us/javadoc/edu/wpi/first/wpilibj/CANJaguar.html) for the CANJag class.
Does anyone know of similar documentation for C++?
I'm not a C++ programmer and will relay any info about this to my son who knows that stuff. I'm mechanical and would understand mechanism and controls hardware. I've worked with industrial PLCs using ladder logic and have some understanding of controls systems. The big questions for me are:
Do the Jaguar on-board speed and position controls work? If so, looking for examples of successful controls strategy?
Is my assumption correct that using the Jaguar's micro-controller PID loops faster and more efficient than running feedback/feed-forward loops from the CReo?
Is the CAN Bus route worth the effort?
What questions have I forgotten to ask? :)
The PID functionality of the Jaguars does work, but adding CAN can be expensive depending on which adapter you use.
The PID on the cRIO is just as fast and as powerful as the one on the jaguar, but works with all types of speed controllers and sensors. If you're looking for basic getting started examples, there are plenty for PID on the cRIO.
brennonbrimhall
26-12-2013, 17:04
I'm not a C++ programmer and will relay any info about this to my son who knows that stuff. I'm mechanical and would understand mechanism and controls hardware. I've worked with industrial PLCs using ladder logic and have some understanding of controls systems. The big questions for me are:
Do the Jaguar on-board speed and position controls work? If so, looking for examples of successful controls strategy?
Is my assumption correct that using the Jaguar's micro-controller PID loops faster and more efficient than running feedback/feed-forward loops from the CReo?
Is the CAN Bus route worth the effort?
What questions have I forgotten to ask? :)
Yes. However, it is the opinion of some (myself included) has been that the physical connections and mechanical implementation in the Jaguar motor controller are unreliable.
Yes.
In my experience, I'd say that doing PID on the cRIO is much less of a headache and much easier to implement than CANBus. I personally find the CAN interface on the Jaguar to be much more trouble than it's worth. That being said, there are several teams who have used the CANBus route successfully and prefer it (according to my friends on 195, it can have cleaner wiring if you do it right, and it is more computationally efficeint than doing it on the cRIO). Whether or not it is a success on your team is a function of your determination, human resources, experience, and time.
It's worth noting that there is not an insignificant chance that the interface for CAN in 2015 will be much different than it was in 2013 (with new roboRIO, and with a new CAN-based Talon). I'd read the following documents/forum discussion. Hopefully they'll answer more questions than they raise, but as always, feel free to ask any new questions you might have. That's what ChiefDelphi is all about. :)
http://content.vexrobotics.com/docs/217-3367-VEXpro_Jaguar_GettingStartedGuide_20130215.pdf
https://decibel.ni.com/content/message/29759
https://decibel.ni.com/content/docs/DOC-14865
DavisDad
26-12-2013, 17:18
brennonbrimhall,
Thanks so much for the help!
I was very excited about the performance of the Jaguar/CIM running on the bench through BCD-COMM. If this can be done through the cRIO, I'm willing to forge ahead. I've read through VEX and TI manuals, read the NI forums but no joy finding a servo/motor/Jaguar set-up problem to solve the problem. I guess I'll need to delve into programming language to get the complete picture :O.
brennonbrimhall
26-12-2013, 17:28
brennonbrimhall,
Thanks so much for the help!
No problem. Always glad to help.
I was very excited about the performance of the Jaguar/CIM running on the bench through BCD-COMM. If this can be done through the cRIO, I'm willing to forge ahead.
Best of luck. You're far braver than I am...
I've read through VEX and TI manuals, read the NI forums but no joy finding a servo/motor/Jaguar set-up problem to solve the problem.
What do you mean by a set-up problem? Are you referring to the PID coefficients, or a simple set-up diagram of sorts?
I guess I'll need to delve into programming language to get the complete picture :O.
Yes, I would recommend that. What language do you use?
Joe Ross
26-12-2013, 19:06
The PID on the cRIO is just as fast and as powerful as the one on the jaguar,
Why do you say this? I wasn't aware that anyone was running PID at 1000 hz on the cRIO. Doing PID on the cRIO is more flexible, however, since you can implement your own.
The serial CAN interface is somewhat inefficient, and you may find that if you send to many updates, it may use more cRIO throughput then running a 50 or 100hz PID on the cRIO would. One option would be to invest in the 2CAN (http://www.crosstheroadelectronics.com/2CAN.htm). Another option would be to limit the amount of CAN traffic. Setting a setpoint every few seconds isn't a problem. Changing setpoints at 50hz to multiple jaguars and requesting lots of status can be a problem.
Joe Ross
26-12-2013, 19:32
Last year we tried to use the Jaguar Motor Controller's position and speed control functions in our Ultimate Accent bot. We got the BDC-COMM utility to work but couldn't work out the "C" programming.
This thread shows the required calls for setting up a CAN Jaguar in position mode. http://www.chiefdelphi.com/forums/showthread.php?t=102909 You also need to using the imaging tool to set the appropriate CAN Jaguar plugin (Serial or 2CAN).
We successfully utilized Jags last year with CAN bus and a position sensor. We were going to also use the speed sensor but had wired a hall-effect sensor for speed vice an encoder. The Jag could not utilize the hall-effect sensor.
Couple of things we learned.
1. Wire the serial port of the cRio to the first Jag, than CAN to the other Jags
2. Don't forget the terminator on the last Jag
3. ReImage the cRio with CAN support (that one took us a while to learn :)
4. Write simple test programs to exercise the Jag before integrating Jag support into your overall robot code. Its MUCH easier to debug.
Don't forget, Jags also work well with limit switches (CAN and PWM control).
Good luck with the Jags this year.
DavisDad
26-12-2013, 21:29
...What do you mean by a set-up problem? Are you referring to the PID coefficients, or a simple set-up diagram of sorts?
Hooking up to the BCD-COMM wasn't easy for us:
I had some quad encoders with index and it took some time to realize that the index was resetting the counter when trying position control
Struggled a bit with USB/Serial converter to Jaguar; PC serial software
Didn't have documentation about PID (PI only) constants; had to trial-and-error the integral.
"Bricked" a Jaguar by failed firmware update (VEX had good support and fixed it for free)
I know none of these are that big a deal individually, but when you're dealing with multiple snags it can get daunting. What I meant is: I wanted to make sure there wasn't some issue like those with the cRIO CAN setup that was preventing proper operation.
Why do you say this? I wasn't aware that anyone was running PID at 1000 hz on the cRIO. Doing PID on the cRIO is more flexible, however, since you can implement your own.
I tested this last year. I tried 800 hz to 10 hz, and everything faster than 100 hz behaves the same way as 100 hz because the victor can only be updated every ~20 ms (50 hz).
Also, I don't think that a drivetrain used in FRC will benefit from being updated 100 times a second vs 1000.
Where did you find the 1000hz number? I'm not saying it's wrong, but I couldn't find it online.
Where did you find the 1000hz number? I'm not saying it's wrong, but I couldn't find it online.
The point Joe was making is that the built-in PID in the Jag's firmware closes the loop at 1000 Hz (http://www.chiefdelphi.com/forums/showpost.php?p=1013476&postcount=41). You can't do that with cRIO. You can't do that with Victor or Talon.
everything faster than 100 hz behaves the same way as 100 hz because the victor can only be updated every ~20 ms (50 hz).
Victors will accept 200 Hz input PWM frequency.
I don't think that a drivetrain used in FRC will benefit from being updated 100 times a second vs 1000.
Other systems might.
Joe Ross
26-12-2013, 21:45
Where did you find the 1000hz number? I'm not saying it's wrong, but I couldn't find it online.
It's in the jaguar source code (not sure if it's still available online, used to be available from TI). There is a 1ms timer interrupt. It runs the PID and updates the H-bridge PWM from the same interrupt.
It's in the jaguar source code (not sure if it's still available online, used to be available from TI). There is a 1ms timer interrupt. It runs the PID and updates the H-bridge PWM from the same interrupt.
Portions of the relevant source code were posted here by dyanoshak:
http://www.chiefdelphi.com/forums/showpost.php?p=1013476&postcount=41
DavisDad
26-12-2013, 22:11
This thread shows the required calls for setting up a CAN Jaguar in position mode. http://www.chiefdelphi.com/forums/showthread.php?t=102909 You also need to using the imaging tool to set the appropriate CAN Jaguar plugin (Serial or 2CAN).
Hi Joe,
Thanks for the link and info in previous post. I work with industrial control systems (not programming) and I like distributed control over a network. My bias from work makes me lean toward using the Jaguar's controller for the feedback control and send setting over the BUS.
I really appreciate the real-world experience with the FRC electronics.
I spent a fair amount of time using CAN and the Jags and this architecture has a lot of potential -- in my opinion, the problems were all in the implementation and the current Jags seem to have addressed the most severe problems. I also designed and built my own smart motor controllers that used different silicon and was very happy with how these turned out. I'm really looking forward to seeing a second-generation motor controller with these capabilities generally available -- and therefore legal for competition use.
I'd second the points about watching the serial bandwidth if you go this way and about using the 2CAN to open up this potential bottleneck. There at least used to be a source (eStop robotics, IIRC) for pre-made serial-to-CAN converters and terminators, as well as cables. Some teams have trouble with these, particularly the terminators. You'll need a serial converter for using BDC-COMM with a PC anyway. And BTW, making sure things work under BDC-COMM is a good first step and troubleshooting tool.
I've also seen people tripped up because the encoder connector on the Jag has a different pinout than the standard one used by US Digital, so pre-made cables at least need to be modified. Also, the space around the pins is very tight and so you have to have the right connector for this.
I sent this for a fix to the problem where the index signal messes up position control, AFAIK, it never made it into official firmware, but I haven't tried to use this in the past couple of seasons (this refers to a source file for the Jag firmware):
Note that this is in the ControllerPositionMode() function in controller.c.
Briefly, the problem was that when using PID position-based control with an indexed encoder, things don't go well when the index is hit and the position count wraps.
static void
ControllerPositionMode(void)
{
long lTemp;
//
// Get the motor position.
//
[...]
//
// Compute the error between the target position and the motor position.
//
lTemp = g_lPositionTarget - lTemp;
[
The preceding line is deriving the position error, but neglects that there are really two errors and this code need to evaluate both of these and pick the smaller of the two. The second error crosses through zero and when this is the smaller of the two, the existing code does not do the right thing.
This shows up especially when using an indexed encoder where the count gets set to zero when the index is encountered. Note that if using a pot, you really don't want to move through zero, so the logic change only applies when dealing with an encoder!
One possible fix is to leave the preceding line as-is, but add this code:
// When using an encoder, handle the case where the most direct way to reach the
// desired position crosses through zero. If the encoder lines global has not been set,
// this will be zero, meaning the count wraps at QEI_MAXPOS_M. If the position
// error is more than halfway through a full revolution, going through zero is the shorter
// distance. If the error is exactly half-way around, it would make sense to keep going
// in the current direction, but PID behavior should adequately cover this case.
// This code should really be gone over to be sure there are no issues mixing signed and
// unsigned 32-bit integers. Also, it might make sense to use QEI_MAXPOS_M in the
// case where the encoder lines global has not been set (but this is more a usage problem).
if (HWREGBITW(&g_ulFlags, FLAG_POS_SRC_ENCODER) == 1 && g_ulEncoderLines != 0)
{
if (lTemp > g_ulEncoderLines / 2)
{
lTemp = lTemp - g_ulEncoderLines;
}
else if (lTemp < -(g_ulEncoderLines / 2))
{
lTemp = lTemp + g_ulEncoderLines;
}
}
]
//
// Run the PID controller, with the output being the output voltage that
// should be driven to the motor.
//
[...]
Another thing that can trip people up is if the controller resets for any reason (power brown-out, bug?, bandwidth saturates on serial link and something bad happens?). Or maybe the cRIO resets but the Jaguar does not, or maybe something bad happens around losing the safety heartbeat, ...
Anyway, there is a possibility that the configuration parameters will all be lost and things will revert to the defaults. You want to have some sort of error handler in the cRIO code and probably also to periodically read at least something from the Jag to be sure things seem good.
There are some old threads on this topic and also that go into more detail on some of the issues in my prior post.
DavisDad
28-12-2013, 04:52
...One option would be to invest in the 2CAN (http://www.crosstheroadelectronics.com/2CAN.htm). Another option would be to limit the amount of CAN traffic. Setting a setpoint every few seconds isn't a problem. Changing setpoints at 50hz to multiple jaguars and requesting lots of status can be a problem.
Hi Joe,
I've read about the 2CAN but the price scared me away. I'll put that on my list to investigate.
Thanks!
DavisDad
28-12-2013, 05:09
The point Joe was making is that the built-in PID in the Jag's firmware closes the loop at 1000 Hz (http://www.chiefdelphi.com/forums/showpost.php?p=1013476&postcount=41). You can't do that with cRIO. You can't do that with Victor or Talon.
Victors will accept 200 Hz input PWM frequency.
Other systems might.
Hi Ether,
First- I've read many of your posts and want to compliment you on your contributions to the teams. Your to-the-point, thorough, and expert responses are a pleasure to read. Thank you!
I've begun following your links and have a lot of studying to do...
DavisDad
28-12-2013, 05:17
The PID functionality of the Jaguars does work, but adding CAN can be expensive depending on which adapter you use.
The PID on the cRIO is just as fast and as powerful as the one on the jaguar, but works with all types of speed controllers and sensors. If you're looking for basic getting started examples, there are plenty for PID on the cRIO.
Jared,
By "adapter", do you mean something like 2CAN? Isn't the CAN system intended to be done directly from the cRIO? My understanding is that using a device like 2CAN improves CAN speed and has some improved functionality, right?
Thanks for the imput
DavisDad
28-12-2013, 05:26
Another thing that can trip people up is if the controller resets for any reason (power brown-out, bug?, bandwidth saturates on serial link and something bad happens?). Or maybe the cRIO resets but the Jaguar does not, or maybe something bad happens around losing the safety heartbeat, ...
Anyway, there is a possibility that the configuration parameters will all be lost and things will revert to the defaults. You want to have some sort of error handler in the cRIO code and probably also to periodically read at least something from the Jag to be sure things seem good.
There are some old threads on this topic and also that go into more detail on some of the issues in my prior post.
Hi nuttle,
Thanks so much for the thorough response and links. The "picture that is emerging" seems to be that CAN architecture with the Jaguar is finicky but powerful if devilish details are worked out.
The "picture that is emerging" seems to be that CAN architecture with the Jaguar is finicky bur powerful if devilish details are worked out.
Yeah, this is a good way to put it. You can get things working without too much trouble, but if you don't leave enough time to test everything very well, you run some risk of having something go wrong at an inopportune time. Could be a transient glitch you barely notice or could be worse...
I've personally had pretty good results, but things like the position control with an index not working (a couple of years back but maybe still not fixed?) are limiting and cost and reliability made it so that it was really only worth the trouble if you could gain an advantage by using the CAN function. It is nice to be able to read the current and even temp, but few teams do anything with this, so closed-loop PID control seems to be the main feature that gets used. It is also nice to have another way to interface encoders, particularly since the cRIO is only set up to handle a limited number of these.
There's a lot more that could be done with this type of architecture. I put some thoughts on this in this post: <http://www.chiefdelphi.com/forums/showpost.php?p=1279562&postcount=74>.
Isn't position and speed control what the analog interface is for? just hook up something like a pot or a limit switch (or even a hall-effect sensor if you are sly like that) to control speed, etc.!
Isn't position and speed control what the analog interface is for? just hook up something like a pot or a limit switch (or even a hall-effect sensor if you are sly like that) to control speed, etc.!
Actually, a pot or a limit switch will be rather useless for controlling speed. Pots are good for position, maybe you can get speed but only for a short time. Limit switches are good for telling you that you need to stop right before your code ignores that and manages to destroy them! (OK, I'm mostly joking--you have to mount them so that they don't get destroyed if the thing that's moving hits the hard stops. Past experience.)
For speed, encoders are the way to go, generally speaking, and seeing as the Jags have the capability to handle them and run PID, that can be a lot more useful than just using the analog interface.
Victors will accept 200 Hz input PWM frequency.
Yeah, but the point Jared was making was that the pulse width coming from the sidecar is about 20 ms, so you still can't get better than about 50 hz.
Also, I'm having a really hard time thinking of an FRC application where you need to update 1000 times per second over 100 or 200. It seems to me that in a single millisecond, a negligible amount of change can be done to the speed of a motor, and that some sensors won't show a change over 1/1000 of a second.
Has anybody really seen a benefit from really fast PID loops?
Victors will accept 200 Hz input PWM frequency
Yeah, but the point Jared was making was that the pulse width coming from the sidecar is about 20 ms, so you still can't get better than about 50 hz.
The pulse width is not 20ms. The period is 20ms. The pulse width varies from roughly 1ms (full reverse) to 1.5ms (zero command) to 2ms (full forward.
You can change the PWM period coming from the sidecar, so you can send commands at a higher frequency.
Joe Ross
28-12-2013, 17:39
Yeah, but the point Jared was making was that the pulse width coming from the sidecar is about 20 ms, so you still can't get better than about 50 hz.
The PWM pulse repeat rate can be as high as 200hz. By default, it is 200hz for Jaguars, 100hz for Victors and Talons, and 50hz for Servos.
The PWM pulse repeat rate can be as high as 200hz. By default, it is 200hz for Jaguars, 100hz for Victors and Talons, and 50hz for Servos.
I was unaware that this works. A while back (2009 or 2010) I looked at the signal with a scope, the pulse width was somewhere between 1-2.5 ms, and the delay in between was 20 ms, no matter what speed controller was selected (in LabVIEW).
DavisDad
28-12-2013, 19:20
Isn't position and speed control what the analog interface is for? just hook up something like a pot or a limit switch (or even a hall-effect sensor if you are sly like that) to control speed, etc.!
Hi yash,
My son and I have implemented speed control on a FTC design using Matrix (http://matrixrobotics.com/wp-content/uploads/2013/07/MATRIX_Motor_Spec_v2.pdf)motors (~120 rpm, planetary 27:1, hall effect encoder 757 lines) controlled by LEGO NXT. You can see our progress here: Modular Drive System (http://www.chiefdelphi.com/forums/showthread.php?t=123409)
Our prototype works well as follows:
The pain for getting the motor controllers configured was relatively small (~ 8 hrs).
PID control of encoder speed tracked well with little control oscillations
The mecanum omni directional control scheme went together smoothly
The prototype controlled smoothly from the game controllers
Power was good
The bot tracked straight with a small amont of drift to the left
We're planning to make a video tomorrow to show the driving performance. We were delighted scooting around the kitchen, pushing around chairs. Sending the desired speed to the motor controller and letting it do the "local maintenance" is a solid architecture.
DavisDad
29-12-2013, 16:03
My son and I made these movies (link to post below) to show Mecanum with speed control. This is the FTC teams prototype; not FRC. This is the design from which we're scaling up.
http://www.chiefdelphi.com/forums/showthread.php?p=1318026#post1318026
FWIW, CAN Starter Pack (https://www.estoprobotics.com/estore/index.php?_a=viewProd&productId=34) is worth checking out, for teams that plan to use CAN.
DavisDad
31-12-2013, 05:42
FWIW, CAN Starter Pack (https://www.estoprobotics.com/estore/index.php?_a=viewProd&productId=34) is worth checking out, for teams that plan to use CAN.
Hi nuttle,
Thanks for the link. For $25, it'd save some time making cables.
Has anybody really seen a benefit from really fast PID loops?
We have had a very positive experience using the closed loop PID in the Jaguar with Speed Control. Less than .25 seconds to reach proper speed from 0, even shorter times when returning to speed after a shot.
It doesn't require the CRIO PID to process it which free resources that can be used for other things.
We have had a very positive experience using the closed loop PID in the Jaguar with Speed Control. Less than .25 seconds to reach proper speed from 0, even shorter times when returning to speed after a shot..
Note to rookies:
Fast spinup and recovery times are strongly influenced by mechanical design: operating speed, motor(s) selection, gear ratios, wheel diameter, and moment of inertia of the load (including wheel and flyweight). With a proper mechanical design, you should be able to get fast spinup and recovery times with other controllers as well.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.