Jaguar/Victor question

[MrForbes]

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.

[nighterfighter]

Originally Posted by squirrel

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.

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.

[daltore]

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.

[Ether]

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.

~

[dtengineering]

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

[Al Skierkiewicz]

Originally Posted by dtengineering

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).

[Ether]

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.

[EricH]

Originally Posted by Ether

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.

[s1900ahon]

Originally Posted by EricH

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.

<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).

[kevin.li.rit]

Lets avoid quoting rules when we are talking about a small personal project. Okay?

[Chris is me]

Originally Posted by Coffeeism

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.

[artdutra04]

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!

* The simplest way I wan think of to achieve this (e.g. least additional custom hardware and software) is to plug the robot controller PWM data line into one of the digital I/Os on the ATtiny13, and write a bit-banged function to read the PWM input to ascertain what the 0-255 value was. Then calculate PID, and set the PWM output. To enable the PWM output you'll have to read through the Atmel product manual for the correct internal clock register values to enable PWM output.

[nighterfighter]

Originally Posted by Chris is me

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.

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.

[Ether]

Originally Posted by Ether

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.

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

~

[s1900ahon]

Originally Posted by Al Skierkiewicz

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.

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.