pic: Team 610 - 2013 Electronics Board

[Andrew Schreiber]

Originally Posted by kenavt

For a more relevant question... How is the new 2CAN working for you, and CANbus in general, so far in 2013?

I'm not 610 but I can tell you that 79 hasn't had any problems with either the 2CAN or the CANbus in general this year. The only major problem we have is that our electrical team has a nasty habit of pull Jags off the bus that we still talk to and it introduces a stutter into the system. Despite our best efforts we have not been able to rectify this problem (the electrical team removing Jags, the stutter is fixed by not writing to that Jag).

[Mr. Lim]

Well, another Saturday in the books. Figured I'd post a quick response before a night-time Timmie's run...

I can't really comment about the drivetrain, other than the fact that I really like it, and that student designer Ryan Tam (Gr. 11) deserves a tons of recognition for the design and manufacture of it. He worked under the mentorship of Mr. Stehlik, and there are a lot of neat little details in it that just don't show up in this picture... (i.e. all 4 side plates are identical, how the square channels are securely connected to the side plates with only one fastener, the in-between CIM "floating" encoders + mounts)

It's not flashy, but it's really well thought out, with a ton of detail to maximize ease of machining, assembly, and maintenance.

To answer some questions:

Yes, the smiley is covering something. We noticed one of the frisbee manipulating components got into the picture, and needed to be covered up.

The air tank holder is custom cut 1/4" lexan on our CNC router, again designed by Ryan Tam. It is basically four holes, as the tanks have a nice raised boss at each end that you can support them by.

As for CAN, it worked well for us last year, but we had a few hundred lines of code dedicated to CAN Error Recovery. Without it, we would have been dead in the water. We used the black serial adapter last year, and this is the first year we are using the 2CAN. It's still a bit early to give any meaningful feedback, as all we've done is some light open-loop driving.

[Andrew Schreiber]

Originally Posted by Mr. Lim

Well, another Saturday in the books. Figured I'd post a quick response before a night-time Timmie's run...

I can't really comment about the drivetrain, other than the fact that I really like it, and that student designer Ryan Tam (Gr. 11) deserves a tons of recognition for the design and manufacture of it. He worked under the mentorship of Mr. Stehlik, and there are a lot of neat little details in it that just don't show up in this picture... (i.e. all 4 side plates are identical, how the square channels are securely connected to the side plates with only one fastener, the in-between CIM "floating" encoders + mounts)

It's not flashy, but it's really well thought out, with a ton of detail to maximize ease of machining, assembly, and maintenance.

To answer some questions:

Yes, the smiley is covering something. We noticed one of the frisbee manipulating components got into the picture, and needed to be covered up.

The air tank holder is custom cut 1/4" lexan on our CNC router, again designed by Ryan Tam. It is basically four holes, as the tanks have a nice raised boss at each end that you can support them by.

As for CAN, it worked well for us last year, but we had a few hundred lines of code dedicated to CAN Error Recovery. Without it, we would have been dead in the water. We used the black serial adapter last year, and this is the first year we are using the 2CAN. It's still a bit early to give any meaningful feedback, as all we've done is some light open-loop driving.

Im interested in the CAN Error Recovery stuff. Could you elaborate?

[Mr. Lim]

Originally Posted by Andrew Schreiber

Im interested in the CAN Error Recovery stuff. Could you elaborate?

We coded our robot in Java using the Command-based template.

Within each subsystem that used a Jaguar, we ensured that whenever we caught a CANTimeOutException, we called a subsystem-specific recovery method to re-initialize and verify the configurations of all Jags within that subsystem.

This ended up being a bit tricky for some sub-systems, as we switched Jaguar configurations depending on the task we were doing. i.e. the drivetrain could be in VBus, Position, or Speed mode at different times in the match. We had to keep track of these states, and restore them gracefully.

We had to handle the deadlock condition as well, because sometimes the error recovery would cause more CANTimeoutExceptions if the affected Jag wasn't ready to be re-initialized. Gracefully handling this condition without stopping your entire CAN communications bus was a bit tricky.

At worst we only wanted a single sub-system to "pause" just long enough to gracefully re-initialize the Jaguars after an exception. All the other sub-systems had to keep going as if nothing happened.

[Andrew Schreiber]

Originally Posted by Mr. Lim

We coded our robot in Java using the Command-based template.

Within each subsystem that used a Jaguar, we ensured that whenever we caught a CANTimeOutException, we called a subsystem-specific recovery method to re-initialize and verify the configurations of all Jags within that subsystem.

This ended up being a bit tricky for some sub-systems, as we switched Jaguar configurations depending on the task we were doing. i.e. the drivetrain could be in VBus, Position, or Speed mode at different times in the match. We had to keep track of these states, and restore them gracefully.

We had to handle the deadlock condition as well, because sometimes the error recovery would cause more CANTimeoutExceptions if the affected Jag wasn't ready to be re-initialized. Gracefully handling this condition without stopping your entire CAN communications bus was a bit tricky.

At worst we only wanted a single sub-system to "pause" just long enough to gracefully re-initialize the Jaguars after an exception. All the other sub-systems had to keep going as if nothing happened.

Interesting, maybe I'll have to chat with you guys in more depth post season about this. We use Iterative and C++ so your approach wouldn't work for us.

[ksafin]

Is the perimeter of this thing really under 112 inches? It looks huge!

[Mr. Lim]

Originally Posted by ksafin

Is the perimeter of this thing really under 112 inches? It looks huge!

Our perimeter measures out at 110".

The VersaWheels do funny things to the perspective.

[Nick Lawrence]

Originally Posted by Mr. Lim

Our perimeter measures out at 110".

The VersaWheels do funny things to the perspective.

This is especially true with 256's drivetrain.

http://www.chiefdelphi.com/forums/sh...hreadid=112141

-Nick

[WileyB-J]

Sweet multimeter.

[Tmaxxrox97]

Originally Posted by Mr. Lim

I can't really comment about the drivetrain, other than the fact that I really like it, and that student designer Ryan Tam (Gr. 11) deserves a tons of recognition for the design and manufacture of it. He worked under the mentorship of Mr. Stehlik, and there are a lot of neat little details in it that just don't show up in this picture... (i.e. all 4 side plates are identical, how the square channels are securely connected to the side plates with only one fastener, the in-between CIM "floating" encoders + mounts)

It's not flashy, but it's really well thought out, with a ton of detail to maximize ease of machining, assembly, and maintenance.

Is there a CAD file of this drivetrain available? The floating encoders and mounts sound like a really cool idea and I would like to take a look at them if I could.

[jamierose]

Originally Posted by Tmaxxrox97

Is there a CAD file of this drivetrain available? The floating encoders and mounts sound like a really cool idea and I would like to take a look at them if I could.

We will probably upload our CAD to www.frc-designs.com at some point in the future. I would do it now, but unfortunately, I, and many other members of our team, are currently writing exams, so we don't have much time to sort out our CAD and upload it. I'll explain a bit about how our encoders are mounted.

As you can see in the picture, our CIMs are pretty close together. We made a small plastic piece with our 3-axis CNC router that looks like a rectangle with a semi-circle cut out on either side of it. These portions of a circle are made to fit perfectly around a CIM. There was a hole in the middle of the piece for an encoder to fit through so we could screw it on. We then slid the piece in between the CIMs. The friction was enough to keep the plastic piece in place.

We then used our usual method to connect the encoder to the shaft. On 610 we use a technique we borrowed from 188, which is using surgical tubing to connect an encoder to a shaft. We simply slide the encoder into one end of the surgical tubing and the shaft into the other end. It works extremely well and we have never had issues with it.

If you have any more questions feel free to ask or message me! Hopefully we'll be able to get that CAD uploaded soon.