View Full Version : Motor speed control uning Jaguar
Hi Techies,
I have been away from FRC for a while a I need a kick start with using the Jaguar. Our team's app will need highly accurate speed control for a ball shooter.
1) what speed sensor should we use?
2) what accuracy should we expect to achieve?
3) is there a recommended motor for shooter applications?
Thanks,
Hi Techies,
I have been away from FRC for a while a I need a kick start with using the Jaguar. Our team's app will need highly accurate speed control for a ball shooter.
1) what speed sensor should we use?
2) what accuracy should we expect to achieve?
3) is there a recommended motor for shooter applications?
Thanks,
There are a number of encoders to choose from for your speed sensor, namely the USDigital optical encoder and the magnetic encoders in last year's KoP.
Legal motors are listed in [R48], but I think it's a safe bet to say that you won't be using the Vex motor for your shooter.
Keep [R61] in mind though, because that specifically disallows the use of Jaguars' closed feedback loops.
Interesting. I wonder if they will change this like last year.
"As long as the CAN bus is wired legally so that the heartbeat from the cRIO is maintained, the closed loop control features of the Jaguar motor controller may be used. (That is, commands originating from the cRIO to configure, enable, and specify an operating point for all Jaguar closed loop modes fit the intent of <R49>.)
January 21, 2010"
Thad House
08-01-2012, 22:02
There are a number of encoders to choose from for your speed sensor, namely the USDigital optical encoder and the magnetic encoders in last year's KoP.
Legal motors are listed in [R48], but I think it's a safe bet to say that you won't be using the Vex motor for your shooter.
Keep [R61] in mind though, because that specifically disallows the use of Jaguars' closed feedback loops.
How does R61 Disallow it. The blue box below R52 says otherwise.
StephenNutt
08-01-2012, 22:11
How does R61 Disallow it. The blue box below R52 says otherwise.
Agreed, seems explicitly allowed to me.
jwakeman
12-01-2012, 17:08
I am looking for some clarification regarding this part of [R61]:
A. The Jaguar must receive signals via either a PWM cable -OR- a CAN-bus connection. Both may not be used simultaneously.
Does this only apply to "command signals" that control the output of the jaguar? I might want to control the jag via PWM but monitor output voltage and current via CAN at the same time. Is this legal?
Does this only apply to "command signals" that control the output of the jaguar? I might want to control the jag via PWM but monitor output voltage and current via CAN at the same time. Is this legal?
You can do whatever you want for testing. These rules only apply for a competing robot. That said, monitoring via CAN should be legal, but it's lawyering in my opinion.
Would be? Should be? Could be? All three of those are grey area responses. You should post your question in the FRC Q&A Forum (https://frc-qa.usfirst.org/Questions.php) to get a legal explicit ruling from the GDC.
Would be? Should be? Could be? All three of those are grey area responses. You should post your question in the FRC Q&A Forum (https://frc-qa.usfirst.org/Questions.php) to get a legal explicit ruling from the GDC.
Exactly, I'm not the GDC, therefore I can't give an official ruling. I can only offer up my interpretation accompanied by a qualifier.
Rule 61 seems pretty clear to me. You can use either Can-Bus or PWM, but not both on the same Jaguar.
jwakeman
12-01-2012, 20:10
Rule 61 seems pretty clear to me. You can use either Can-Bus or PWM, but not both on the same Jaguar.
Another thought I had was to wire in both the PWM and the CAN. Then only use the CAN bus to control the robot. The PWM would be there as a failover drive system. I have some concerns about the CAN network being reliable annd want to be able to switch to PWM driving if we detect trouble. Not trying to bend the rules, just want to know what's legal. I will ask my question in the rule QA. Thanks
Another thought I had was to wire in both the PWM and the CAN. Then only use the CAN bus to control the robot. The PWM would be there as a failover drive system. I have some concerns about the CAN network being reliable annd want to be able to switch to PWM driving if we detect trouble. Not trying to bend the rules, just want to know what's legal. I will ask my question in the rule QA. Thanks
That would not be legal. There is no way of knowing for sure that only one is controlling the robot.
jwakeman
13-01-2012, 09:38
Would be? Should be? Could be? All three of those are grey area responses. You should post your question in the FRC Q&A Forum (https://frc-qa.usfirst.org/Questions.php) to get a legal explicit ruling from the GDC.
I don't see any way on the Q&A to ask a question. I can only search..
Jared Russell
13-01-2012, 09:53
Regarding speed sensors: An encoder is a good fit for this task. However, keep in mind how fast your wheel will be spinning.
Let's say your shooter is powered by a CIM and a 1:1 ratio. You will see ~5000rpm speed on the shooter wheel.
5000rpm is 83.3 revolutions per second. If you use the kit of parts encoders (250 counts per rev), that is more than 20,000 counts per second. In theory, the FPGA can count upwards of 39,000 counts per second. So this arrangement would work if you are doing speed control on the cRIO, but if you wanted to go to, say 10,000rpm on the shooter wheel, you would want a lower resolution encoder. I am not sure about the capabilities of a CAN Jaguar when it comes to maximum encoder rate.
In 2006, we made our own encoder by using an IR reflective sensor (like the ones Banner or Rockwell makes) with strips of reflective tape on the shooter wheel to trigger the counting. This method would of course work in 2012, as well.
I don't see any way on the Q&A to ask a question. I can only search..
You will need the team account information from your team to post directly to ask a question. See the Q&A - How to Guide (http://www.usfirst.org/sites/default/files/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2012_Assets/Team_User_Q%26A.pdf) for more details.
Another thought I had was to wire in both the PWM and the CAN. Then only use the CAN bus to control the robot. The PWM would be there as a failover drive system.
R61 B says if you are using PWM then you cannot have anything in the other ports which includes canbus
R61 A also would prohibit the PWM connection if you are using canbus since there is no way for you to turnoff the PWM signal.
I expect if you tried to do it the Jag would default to one ignoring the other completely.
The Jag firmware 101 (another thread) seems to have fixed an issue with the canbus. A trashy signal use to take the Jag offline until a power reset. It now will try to reset itself.
mbushroe
20-01-2012, 19:37
I have downloaded the specs for the Black Jaguar to research exactly that question. The spec sheet claims 1 million transitions per second. So the 250 counts per revolution is 4 transitions per line, so 1000 transitions per second. That means that it should handle 1,000 revolutions per second, or 60,000 RPM.
My problem is getting a feedback signal to the Jaguar. Currently I have a left over magnetic encoder, but so far the Jaguar has refused to display a speed or position signal from the magnetic encoder output, which means the PID just ramps up until the Jaguar limits out.
Mike
Regarding speed sensors: An encoder is a good fit for this task. However, keep in mind how fast your wheel will be spinning.
Let's say your shooter is powered by a CIM and a 1:1 ratio. You will see ~5000rpm speed on the shooter wheel.
5000rpm is 83.3 revolutions per second. If you use the kit of parts encoders (250 counts per rev), that is more than 20,000 counts per second. In theory, the FPGA can count upwards of 39,000 counts per second. So this arrangement would work if you are doing speed control on the cRIO, but if you wanted to go to, say 10,000rpm on the shooter wheel, you would want a lower resolution encoder. I am not sure about the capabilities of a CAN Jaguar when it comes to maximum encoder rate.
In 2006, we made our own encoder by using an IR reflective sensor (like the ones Banner or Rockwell makes) with strips of reflective tape on the shooter wheel to trigger the counting. This method would of course work in 2012, as well.
Joe Ross
20-01-2012, 20:03
My problem is getting a feedback signal to the Jaguar. Currently I have a left over magnetic encoder, but so far the Jaguar has refused to display a speed or position signal from the magnetic encoder output, which means the PID just ramps up until the Jaguar limits out.
What is the interface of the magnetic encoder? Most I'm familiar with are an analog interface that isn't compatible with the jaguar.
mbushroe
24-01-2012, 16:46
That would explain the problem. The magnetic encoder I am using generates 2 analog signals that are in quadrature. I thought that the Jaguar could handle that from some of the documentation, but perhaps not. I also tried using the digital Index pulse only, but so fat have not gotten that to work.
The 5/16 inch bore digital encoder should arrive today, and I will try again with that.
Mike
DonRotolo
24-01-2012, 20:43
Rule 61 seems pretty clear to me. You can use either Can-Bus or PWM, but not both on the same Jaguar.I completely agree.
Now I wonder if you can run some Jags on CAN and other jags on PWM, on the same robot. The rules appear to not prevent this, so long as one OR the other is used, never both.
You definitely can't use both PWM and CAN on a single Jaguar. I'm not sure it would even work.
Encoders: This Thread (http://www.chiefdelphi.com/forums/showthread.php?t=100954)has more info on the same topic.
mbushroe
28-01-2012, 14:59
The larger shaft size digital encoder arrived finally, and I got it mounted. Using 2 lantern batteries, and they frequently over current/under volt and crash the Jaguar, requiring a full reset and start from scratch (Note to TI developers, please PLEASE add a save current configuration so that we don't have to reenter EVERYTHING after each reset?).
As long as there were no sudden jumps, it works on digital using the 'encoder' input. I did have to swap the motor leads. I am not sure if 'encoder inverted' would work as well. I also found that at low rpm, like below 100, the TI firmware does not handle speed measurements correctly. Each encoder pulse causes a sudden huge jump up in speed, causing the PID to immediately stop or even reverse (and cause weak batteries to under volt and crash the Jaguar), then go back to zero and let the PID integrate back up. An integration term of 0.0002 is too small to affect the output, 0.003 will ramp up a volt or two per second. With a 15Khz PWM rate, the PID equations may be run at the same speed, and long gaps of time steps with no encoder pulses confuse the firmware. Instead of measuring time between pulses to handle slow speeds, I think they are counting pulses per time period and doing some averaging. All this really means is that direct shaft connection to a drive wheel may require a VERY high line per revolution count, but high motor speeds should be ease to work with. I got up to 1700 rpm before the batteries lost it, and logging 20 times a second and it was stable to a few rpm.
The next big problem is that the WindRiver user's guide has sections for serial and I2I interface, but they are blank, no text. And looking in the code files, there are blocks for Jaguar (PWM mode only), Victor, PID (software version only), serial interface (raw interface), PWM, but nothing that uses the serial interface to control the internal PID in Jaguar. Does anyone know where there is code interface between the cRIO and the Jaguar in C++?
Mike
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.