CAN Design Kit

[AdamHeard]

Originally Posted by EricVanWyk

Thats the part I'm really excited about. I'll bet we'll see a lot of practice bots that are an off the shelf wifi router/bridge/whatever and a 2CAN. Can't beat that!

What will sensors be hooked up to?

[Andy Baker]

Originally Posted by EricVanWyk

Thats the part I'm really excited about.

So are we at AndyMark. Here is the 2CAN page.

This device should be available before Christmas.

We are happy to work closely with Mike and Omar at CTRE.

Andy B.

[EricVanWyk]

Originally Posted by AdamHeard

What will sensors be hooked up to?

I was thinking more of box on wheels type practice bots to teach new drivers, so there wouldn't be any sensors. But on second thought, the Jags do have a couple sensor inputs. I'm not saying the 2CAN could replace a full system, but it really does lower minimum the cost bar for partial-bots.

Knowing Mike, I wouldn't be surprised at all if he made a CAN sensor node. Maybe the 2CAN itself will have a few inputs. I haven't gotten the chance to play with these guys yet, but it could happen.

Bear in mind that I tend to believe that more options is never bad, at worst neutral and usually good.

[AdamHeard]

Originally Posted by EricVanWyk

I was thinking more of box on wheels type practice bots to teach new drivers, so there wouldn't be any sensors. But on second thought, the Jags do have a couple sensor inputs. I'm not saying the 2CAN could replace a full system, but it really does lower minimum the cost bar for partial-bots.

Knowing Mike, I wouldn't be surprised at all if he made a CAN sensor node. Maybe the 2CAN itself will have a few inputs. I haven't gotten the chance to play with these guys yet, but it could happen.

Bear in mind that I tend to believe that more options is never bad, at worst neutral and usually good.

Ah, I was thinking more along the lines of full functionality.

Could a gyro be hooked up the to analog input on a jaguar and have the operation of the two be unrelated? The Jaguar's analog input just being used to pass the value to the processor.

[Mike Copioli]

Originally Posted by AdamHeard

Ah, I was thinking more along the lines of full functionality.

Could a gyro be hooked up the to analog input on a jaguar and have the operation of the two be unrelated? The Jaguar's analog input just being used to pass the value to the processor.

The 2CAN is only one component of what would be a modular control system. It would be the core communications module. Other modules would be needed such as CAN to GPIO(general purpose input/output), CAN gyro, CAN to analog. CAN speed controllers such as the Jaguar, CAN accelerometers, CAN encoders. These devices could be developed by teams or purchased form a third party vendor. The advantage to using a device like the 2CAN is that a developer could use ANY processor using ANY platform to rapidly develop a fully functional robot. You could use a laptop, an arm processor, a PIC, a basic stamp. Any language c,c++, c#, basic, Java so long as the processor module supports either CAN or Ethernet or Both. Furthermore this device opens a door that will allow teams to develope their own CAN modules.

For years the primary focus of a FIRST team during design and the robot development cycle was mechanical and programming with some allowances for custom circuitry, leaving a very important field of engineering behind, Electrical. We mentor students on forces like inertia, and momentum, power to weight ratios with little or no focus on things like Ohm's Law, Thevenin's Theorem and Kirchhoff's laws. We do not have rules that require you to use a specific size axle shaft or sheet metal thickness because we want this to be part of the "Problem" that needs to be solved. But we have rules that require teams to use a certain gauge wire and specific breaker size. We disallow the use of power management devices in fear of fire. I argue a wheel flying off of the robot or an end of arm tooling that was under engineered is just as if not more dangerous than a rouge electronic component releasing the magic smoke in an arena with enough fire suppression capabilities to put out the earths core. Allowing teams to build their own speed controllers is as important as allowing them to build a transmission. Teaching them to use PCB layout and design software such as EAGLE or PADS or Altium is just as important as teaching them how to use Solidworks or Autodesk.

I hope the 2CAN is the gateway to these changes.

[kamocat]

Sounds great!
I have some ideas on a CAN relay module.
But... I don't really want to deal with the low-level CAN handling.
Is there any chance you could make a "CAN prototype board" sort of thing?
Most of the IO mapping can be done on the cRIO in the communication VIs.
But a device that would have several prescribed analog PID inputs and outputs, and some general analog and digital inputs and outputs.

I can see several possibilities with this already:
Wire the pressure switch for the air compressor directly back to the CAN relay module that controls it.
Servo controllers for a camera pan, tilt, and zoom, all in one CAN module.

[Tom Line]

Originally Posted by Mike Copioli

The 2CAN is only one component of what would be a modular control system. It would be the core communications module. Other modules would be needed such as CAN to GPIO(general purpose input/output), CAN gyro, CAN to analog. CAN speed controllers such as the Jaguar, CAN accelerometers, CAN encoders. These devices could be developed by teams or purchased form a third party vendor. The advantage to using a device like the 2CAN is that a developer could use ANY processor using ANY platform to rapidly develop a fully functional robot. You could use a laptop, an arm processor, a PIC, a basic stamp. Any language c,c++, c#, basic, Java so long as the processor module supports either CAN or Ethernet or Both. Furthermore this device opens a door that will allow teams to develope their own CAN modules.

For years the primary focus of a FIRST team during design and the robot development cycle was mechanical and programming with some allowances for custom circuitry, leaving a very important field of engineering behind, Electrical. We mentor students on forces like inertia, and momentum, power to weight ratios with little or no focus on things like Ohm's Law, Thevenin's Theorem and Kirchhoff's laws. We do not have rules that require you to use a specific size axle shaft or sheet metal thickness because we want this to be part of the "Problem" that needs to be solved. But we have rules that require teams to use a certain gauge wire and specific breaker size. We disallow the use of power management devices in fear of fire. I argue a wheel flying off of the robot or an end of arm tooling that was under engineered is just as if not more dangerous than a rouge electronic component releasing the magic smoke in an arena with enough fire suppression capabilities to put out the earths core. Allowing teams to build their own speed controllers is as important as allowing them to build a transmission. Teaching them to use PCB layout and design software such as EAGLE or PADS or Altium is just as important as teaching them how to use Solidworks or Autodesk.

I hope the 2CAN is the gateway to these changes.

To a point, I agree. Picking up a hammer or a drill are life-skills, not just engineering skills, and a lot of the kids coming into FIRST have never even put a drill bit in a chuck due to their suburban - urban lifestyle and the throw-away mentality a lot of people have nowadays. I can definitely see an argument where the mechanical side of FIRST is more applicable for a larger subset of people.

The only way, however, to get MORE of those engineering skills out there is to do what you're doing. Which is pretty darn cool. Kudos Mike. That's a really cool bit of Kit that I think we'll try to use too

[Mike Copioli]

Thanks for the kudos Tom.

Originally Posted by Tom Line

Picking up a hammer or a drill are life-skills, not just engineering skills, and a lot of the kids coming into FIRST have never even put a drill bit in a chuck due to their suburban - urban lifestyle and the throw-away mentality a lot of people have nowadays. I can definitely see an argument where the mechanical side of FIRST is more applicable for a larger subset of people.

The mechanical world is tangible.
The electrical world is abstract.
The programming world is lonely and misunderstood however sometimes the keyboard is mightier than the drill!

I prefer a combination of all of the above. As far as the life skills argument is concerned these are my thoughts; Many times when a friend or family member is in need of help with a project it is my soldering iron or oscilloscope that is required not my lathe or hammer. Hey can I borrow your truck to move has turned into hey can you fix my kids X-box. What does this tell you? It tells me that in a throw-away world these people are not willing to throw away these devices. But they lack the skills or know-how to make the repairs themselves. often times they even provide me with a link to a site that tells you EXACTLY how to fix the problem but because they are intimidated by the size and misconceived fragility of the components they seek help from others who CAN. Although taking a hammer to it might make you feel a lot better it will not fix your kids X-box. I believe that everything that you use through life regardless of the frequency is a life skill. When I was in high school i did not realize until my junior year that I had an aptitude for electronics. The primary reason......People were showing me how to use hammers instead of soldering irons. Then one day I saw a device that intrigued me. I had no idea how it worked. I found myself in a position that required me to solicit the help of others. The person I found was the high schools electronic teacher. The next year I enrolled in his class. The rest is history.

One argument that I will agree with is that the robot requires more "Manpower" to deal with the mechnical aspects then the electrical/programming.

[EricVanWyk]

Originally Posted by Mike Copioli

One argument that I will agree with is that the robot requires more "Manpower" to deal with the mechnical aspects then the electrical/programming.

I have to agree with you now, but I hope I can disagree with you soon. I think the problem is that there is a large gap in the electronics for FIRST; there isn't enough in between the "connect a to b" and "full custom" categories. On the mechanical side, there is a much fuller continuum from "kit bot" to "CNC porn".

I really hope that the Cypress PSoC board for the driver station acts as a small step in bridging that sparky divide. It comes with a bread board, which I'm hoping will allow teams to begin to experiment with simple things like RC filters. It also has some neat bits like analog outputs and capacitive sensors, which may or may not result in some awesomeness.

I don't know how to fully bridge the gap, but I'm excited for the possibilities.