CAN tutorial

[alexhenning]

Hi,

Since this was team 348's first year doing CAN, we decided to document it. (in part because I'm a senior and won't be around all the time next year) I Right now, it's currently a draft, but I figured by the time I'm happy with it, it will be too late. Right now, it's just the basics. I plan on adding examples of taking advantage of closed loop control and other features of jaguars.

Hopefully you find it helpful! And please leave any suggestions to clarify or improve it.

Link: http://norwellrobotics.com/papers/canbus.html

[ratdude747]

I also wrote I a document on CAN, but it was from a hardware point of view. It is mostly on the wiring aspect of CAN.

http://www.chiefdelphi.com/media/papers/2433

care to compare notes?

edit- I read it. your method for making the serial adapter is different. my methods were using a rj-12 to db9 adpter and reusing old db9 serial cables. not that your method is wrong, it is just different.


good luck on the document...

[alexhenning]

Originally Posted by ratdude747

I also wrote I a document on CAN, but it was from a hardware point of view. It is mostly on the wiring aspect of CAN.

http://www.chiefdelphi.com/media/papers/2433

care to compare notes?

edit- I read it. your method for making the serial adapter is different. my methods were using a rj-12 to db9 adpter and reusing old db9 serial cables. not that your method is wrong, it is just different.


good luck on the document...

Thanks, your's looks really good too! Now, I feel like I should add better pictures.

[tux]

Thanks for the information on CAN. I had no idea what CAN was and looked all through the documentation without really getting a handle on the very basics.

I might suggest that you start your paper with a sentence or two on what CAN is and what it stands for. Maybe a link here:
http://en.wikipedia.org/wiki/Controller_area_network

I think my team is going to stick with PWM this season. I've already started wiring that way and I have some familiarity with it. Maybe after the season we can reconfigure for CAN to get some experience with the added functionality.

Your work will certainly help with that. Thanks!

[alexhenning]

Thanks for the feedback. I added another paragraph in the "overview of CAN" section.

I've also started an example of using the encoders to read speed through the CAN network. I have to verify wiring colors monday, but other than that, it should be good to go.

[PhilBot]

I'm just getting into using CAN and I had some recent revelations which may end up in a white paper somewhere, but I just wanted to post here in case anyone else can benefit/comment.

Using CAN bus in LabVIEW

Our 2011 Robot has a hybrid Swerve drive (6 wheel frame, two center wheels are swerve, 4 outer wheels are omni’s), and a manipulator arm with two motorized joints.

This is my first attempt to use CAN with our robot, and I did it for several reasons.

1) We wanted to have limit switches for the manipulator motions, and CAN provides a software-independent method to protect the motion from end collisions.

2) We wanted to use pots on the rotating joints and have a master/slave controller for the arm, so CAN would let us use the built-in closed loop position control provided by the Jaguar motor controllers.

3) We’ve not had great success with closed loop drive controls to date, so if we try it again it would ne nice for it to be built in to the controllers.

The available tutorials for hooking up the Serial-CAN bus are really good. So we got the actual bus up pretty quickly using a home-made cable and the CAN utility provide by TI. Here we learned about the various control modes and what to expect when reading and writing control data.

However, once we started actually programming (in LabVIEW) things got fuzzier. Larry’s tutorial here: http://www.chiefdelphi.com/media/papers/2433 was a big help, but Larry was only using it for drive control.

Where I started running into problems was putting the JAG’s into Position Control using a POT.

I had verified this action using the TI Jag tool, but the LabVIEW code wasn’t acting the same.

Issues:

1) The Jag tool did position control based on pot voltage, and provided feedback in terms of voltage, so, I was expecting the same from LabVIEW. But the LabVIEW VI’s seemed to use something else. Through much doc searching and experimentation, I discovered that LV is converting position command and position feedback values to the 0.0 to 1.0 range. This makes sense in hindsight, but since pot vales seemed to work, but not properly, it was cause for several close collisions. The inference is that the “real world” units for “position” are “Rotations”, and that a pot measures 1 complete rotation. We all know that’s not true, but it’s probably close enough.

2) The motor enable and disable VIs don’t seem to work the way I expect them to… We wanted to be able to turn off the control of the arm if no motion was required. The code had an enable/disable switch that would issues Enable/Disable commands. We would repeatedly issue a disable command to an arm motor and it would still continue to run in a weird slow-motion way. Since we are setting the control mode to Position Control (POT) and the Disable.vi is sending a “Volt Disable” message to the Jag, I’m wondering if it is truly disabling the motor, since there is ALSO a more appropriate “Position Disable” command.

Anyway... more info at it comes available.

Phil.

[kamocat]

Phil,

Feel free to try using the "position disable" command, and see if it makes a difference. I was under the impression all the "disable" commands function identically. The main purpose of the "enable" and "disable" is to prevent the Jaguar from making wild movements while you are configuring.

In my experience, the BDC-COMM and the LabVIEW implementation treat the position the same; in rotations. I've tested Position Mode with encoders in both LabVIEW and the BDC-COMM, but I've only tested with potentiometers in BDC-COMM.

EDIT:
If you want to control using voltage, you can set your "pot turns" configuration to 3. The Jaguar uses a 3v regulator for the potentiometer.

[PhilBot]

Originally Posted by kamocat

Phil,

Feel free to try using the "position disable" command, and see if it makes a difference. I was under the impression all the "disable" commands function identically. The main purpose of the "enable" and "disable" is to prevent the Jaguar from making wild movements while you are configuring.

In my experience, the BDC-COMM and the LabVIEW implementation treat the position the same; in rotations. I've tested Position Mode with encoders in both LabVIEW and the BDC-COMM, but I've only tested with potentiometers in BDC-COMM.

EDIT:
If you want to control using voltage, you can set your "pot turns" configuration to 3. The Jaguar uses a 3v regulator for the potentiometer.

Now that I've got things working, I'll try the enable/disable again.
Regardless of the original intent for "enable/disable? it seemed the most logical way for me to "stop" the motor from following the slave controller. Changing the mode back to voltage and then setting voltage to zero seemed long winded.

Now that I think back... it's possible that the BDC-COMM WAS running 0-1, but the on-screen text just made me think it was volts...... perceptions...

Setting pot turns to 3 is a clever trick. I wasn't sure how that value effected the controller. I thought that the gear reduction should also come into play there.... but not really..

That parameter could have a paragraph of explanation somewhere so it's more obvious how it effects things.... The Rotations connection just wasn't obvious to me & I've been around the block a few times (or is it arround the bend?)

Phil.

[gckid333]

Thanks for the great tutorial! Our team has tried for 2 years to get it working, but with the lack of any good documentation, we were unsuccessful. We've been doing only part of what has been said in these tutorials. The extra information must be the missing link. I do have one small question. When we first started using CAN, the person in charge of our electronics said that a 120 ohm resistor worked just as well as the 100 ohm resistor, and bought A LOT of 120 ohm resistors, and NO 100 ohm resistors. So since we're stuck with these, I was wondering if they would still work, or if we should just go buy some 100 ohm resistors. Again, thanks for the great info!

[kamocat]

Yes, the 120 ohm resistors work fine.
Truth be told, the CAN bus will actually operate with NO terminating resistor, but it will be less reliable.

[Aren Siekmeier]

We tried out CAN this year via a Serial to CAN cable to a Black Jag. We had a 6 motor drive train and one motor for the elevator (2 black jags, 5 grey). Our CAN code worked beautifully with the drive train; we had not yet wired up the Jag for the elevator. When we did and started running elevator at the same time, we got lots of lag issues, with safety timeouts and CAN bus errors all over the place, resulting in system watchdogs beyond belief. We had it later confirmed (not sure where) that the Serial CAN bus on the cRio can only handle 6 jags efficiently, so we had it switched out for PWM. Unfortunately, due to <R49> and <R58> we couldn't have the limit switches on the elevator jag, which was a big sad face for the programmers.

Have other people had issues with more than 6 jags on the Serial bus? Is the 2CAN able to handle it? (I've heard it's bus speed, anyway, is much much faster, at about 800MHz?)

We also had one Jag (grey) that gave nothing but a Vbus fault in BDC-COMM and didn't accept any image. It worked flawlessly with PWM, so it was probably a firmware issue.

[ratdude747]

Originally Posted by compwiztobe

We tried out CAN this year via a Serial to CAN cable to a Black Jag. We had a 6 motor drive train and one motor for the elevator (2 black jags, 5 grey). Our CAN code worked beautifully with the drive train; we had not yet wired up the Jag for the elevator. When we did and started running elevator at the same time, we got lots of lag issues, with safety timeouts and CAN bus errors all over the place, resulting in system watchdogs beyond belief. We had it later confirmed (not sure where) that the Serial CAN bus on the cRio can only handle 6 jags efficiently, so we had it switched out for PWM. Unfortunately, due to <R49> and <R58> we couldn't have the limit switches on the elevator jag, which was a big sad face for the programmers.

Have other people had issues with more than 6 jags on the Serial bus? Is the 2CAN able to handle it? (I've heard it's bus speed, anyway, is much much faster, at about 800MHz?)

We also had one Jag (grey) that gave nothing but a Vbus fault in BDC-COMM and didn't accept any image. It worked flawlessly with PWM, so it was probably a firmware issue.

very odd... my team made 9 jaguars on Serial Can work fine. we had those erros at one point but it was a code issue; we used labview and the programmer had put everything in teleop.vi and never used periodic tasks, big mistake. moving it all the control loops (non-robot drive) to invidual while loops in periodic tasks solved the timeout issues.

the odd jaguar might have metal shavings inside... open it up and make sure its clean. I was able to fix 5 ones in the junk box that way... remove the shavings and they come back to life.

[Eric Sakshaug]

If I'm reading this correctly, the firmware must be updated prior to assigning a number? My team is currently experimenting with CAN on one of our off-season robots, and we've gotten as far as getting the LED on the black jaguar to be a solid yellow (don't ask why we've waited this long to even get this far!) while connected through 6P6C-DB9 cable to a laptop, and BDC-COMM is saying that it is connected, however, when we attempt to assign a number to the Jaguar (so far, just the black jaguar, and it does have the proper terminator) it gives us the countdown, we press the user button in time, it flashes yellow once, and goes back to solid yellow (meaning that it's being assigned to ID 1, when we're trying to do ID 2). So, is our issue that we need to update firmware first, or is it something else?

[FrankJ]

Go ahead and update the firmware. You will have to do it eventually anyway. I expect the reboot will reset the address to 1 regardless of the current address. I have not actually tried with any ID but 1 this so I could be wrong.

The procedure is to put the new address in the box. Click the assign button. you see the box counting down & the jag light blinking. Press the user button within the 5 seconds. Sorry for being redundant. Should work. Look at the top of the BCD Comm box for the current board ID NOT the assign box.

You can find directions for BCD-COMM here

[Eric Sakshaug]

Originally Posted by FrankJ

The procedure is to put the new address in the box. Click the assign button. you see the box counting down & the jag light blinking.

Look at the top of the BCD Comm box for the current board ID NOT the assign box.

Thanks for the speedy response!

The jag light was remaining solid after we pressed the assign button.

Also, although the jag's LED was solid yellow, there were no board IDs listed in BDC Comm.

Also, we had to force the computer to set the jaguar to Com port 1, otherwise, BDC Comm wouldn't even acknowledge that there was another Com port present.

The black jag was the only one on the network at the time, and attempting to daisy chain through to a tan jag yielded no communications on the tan jag.