So, I’m currently doing a small personal project, and I will need speed controllers.
I’m thinking about using Jags/Victors, but have a question.
I know they are PWM based, so if I send a PWM signal to it, will I need to do anything else for them to drive the motors? I’ll probably be sending the PWM signal using an arduino, if that makes a difference.
They need power, too. But yeah, they just need a pwm signal to make them work.
If you don’t have speed controllers already, and you don’t need the high current capacity of the Jags/Victors, you might consider the smaller (lower current) controllers that Banebots sells. They are reversible. They do require you to send them a zero signal before they’ll start, which can be either a nice safety feature, or a pain.
As long as you feed them a good PWM signal at 5v levels, they will be very happy and run your motors.
If you miss an update, they will stop your motors.
If you are using a Jaguar:
Pulse between .8 and 2.2 ms long(I think this is correct)
Center is at 1.5 ms long
Update at least every 20 ms
Update no more then every 5 ms
Pulse between 1 and 2 ms
Center is 1.5 ms
Update at least every 50 ms ish - I dont know this exact time, sooner is better
Update no more then every 10 ms
All times are in milliseconds.
Since you are on Arduino and using unsigned integers, you should probably store the speed value as a uint8 and then scale it to a uint16 (microseconds) for output.
Edit: Squirrel beat me to it.
Alright thanks, to both of you.
And yeah, I’ll probably need the higher current capacity, I’ll be using CIM motors most likely, for my drive train.
Remember that there is a difference between PWM (pulse-width modulation) and PPM (pulse-position modulation). PWM is the ratio of high to low in a signal (25% is X time of the signal is high, and 3X time of the signal low, then it repeats). PPM on the other hand is the servo signal, between 1 ms and 2 ms like described above. The Arduino libraries have a nice structure (class? Is that one written in C or C++?) setup for this in a library, called “Servo”. You just have to add the Library in the Arduino IDE. The Servo reference is here:
http://arduino.cc/en/Reference/Servo
I’d recommend looking at the “Sweep” example at the bottom, it shows very cleanly how everything is placed.
A note on Servo.write(): The “write()” function is designed to take an angle between 0-180 degrees (a typical servo absolute maximum range, most drivers only have 120, so you might get some jitter or mis-calibration around the extremes), but if the number you input is too high to be considered a valid angle, it will consider the value as a time in microseconds and call “writeMicroseconds()”. The “read()” function will only return the angle, I believe.
Also, if you’ve never used structures/classes, they act a little like variable types (like an “int” or a “char”). You would declare a specific servo (like “myservo”) of type Servo. That’s what “Servo myservo;” does under the include statement.
How fast are you running the realtime task on your arduino? If you’re running fast enough, you could create you own duty cycle in your algorithm and use a simple H-bridge relay to drive your motors at variable speed and direction.
For example, at 1500Hz you could generate 10 different speed levels at 150Hz.
Food for thought.
~
I’ve been using Victors for years, and love them. Over seven years we’ve blown precisely one of them… in our first year… when late at night we hooked three of them up BACKWARDS and ran the robot for many seconds. And we only blew one of the three. Those things are TOUGH.
But the new Jags are worth taking a look at. Our programmer and drivers find they have better low-end response than the Victors, and while we haven’t quantified it, I feel it, too, when I try my hand at driving the robot.
Even better, though, is that the new “Black” Jags don’t require PWM at all… you can communicate over serial and … using the built-in encoders and limit switches on the speed controllers off-load a lot of your processing to the controller.
From what I understand, if you’ve got one “Black” Jag and some of the “Beige” jags, you can use the Black one to do the RS232 communications and then communicate with the other Jags over the CAN network.
The possibility of off-loading PID, limit switch handling and all that to the speed controller is a real paradigm shift for me… it means that anything that can send a serial signal is suddenly a pretty powerful robot controller! Got an old laptop kicking around?
Jason
Jason,
I believe the motor sensor inputs are just using the CAN bus interface within the Jag to port data back to the controller. They are not handled within the individual Jag independent of a controller. The limit switches do function when using PWM but under the 2010 robot rules, you may only provide limit switches when using the Jag under CAN bus control and then only to port limit data back to the controller.
R60
L. If CAN-bus functionality is used, limit switch jumpers may be removed from a Jaguar speed controller and a custom limit switch circuit may be substituted (so that the cRIO-FRC may read the status of the limit switches).
Does <R60> prohibit connecting wheel speed encoders directly to the Jags and using the built-in PID controller in the Jags to control wheel speed or position ?
I was under the impression that some teams did exactly that this year. Could be wrong.
It does. <R60-L> only allows custom limit switch circuits (replacing jumpers), and only on the CAN-bus.
My guess is that a) somebody messed up at inspection or b) you misheard/misread something.
I did some further searching and it appears to be legal under <R68>.
The GDC addressed this question in the Q&A forum:
http://forums.usfirst.org/showthread.php?t=13757
~
Jaguars provide internal closed loop computation for speed, current, and position provided that the controller has enabled one of these modes. This computation is performed at a 1 kHz rate and is done completely within the Jaguar. Data is sent back to the controller when the controller requests (reads) it, but only then.
<R60> covers changes you can make to an electrical component. <R60-L> covers the replacement of the factory installed jumpers, much in the same way that <R60-K> covers changing the brake/coast jumpers.
<R60> doesn’t cover connecting custom circuits to a Jaguar. <R68-H> covers the connection of the output of custom circuits to a Jaguar and make them legal (as Ester points out).
Lets avoid quoting rules when we are talking about a small personal project. Okay?
We’re talking about someone’s rule question, which would determine whether or not this small personal project is likely to be legal next year. This is useful information for people deciding whether or not to learn about the topic.
Once you set up the P, I and D constants on the Jaguars, they can do all the PID calculations onboard itself. The only thing the main robot controller does is send it a new command position/velocity over the CAN bus.
You can easily use a small microcontroller to communicate to CAN bus devices; there are a thousand different ways to do this, but some of the easiest would be use a microcontroller which supports CAN natively, use a SPI-to-CAN hardware adapter, or use a RS232-to-CAN hardware adapter.
OR…
// What follows is not FRC-legal, but it’s a really sweet (and cheap!) solution for offboard PID calculations for other projects.
Let’s say you have a really simple speed controller. Maybe it’s a Victor, or maybe it’s a similar style one rated for different currents or voltages. And you want to use PID, and you want to do it offboard from your main controller. And you’re looking to spend no more than a few bucks to do so. Luckily, the Atmel ATtiny series microcontrollers (among many others) was invented for this very reason!
For $1.94, you can buy an Atmel ATtiny13 microcontroller. With six I/O lines (including a 10-bit ADC) and the capability to run up to 20 MHz with an external crystal, you have your main robot controller output a desired output position* to the ATtiny. Once you write the code for it, the ATtiny takes in this signal, takes in the desired PID sensor (potentiometer, encoder, etc), processes the PID calculations, and then outputs the correct PWM signal. Voila, offboard PID!
This project that I am doing doesn’t involve FRC, or FIRST.
I can guarantee it isn’t legal, because I will also be having a gas engine on board.