What COTS parts would you like to see?

[Andrew Schreiber]

Originally Posted by dv/dt

I'm sure I'm missing something and some of this has been alluded to, but how about a small, lightweight, easily mounted replacement for a window motor? Something with low rpm and modest torque. The window motors are flimsy and hard to mount. I love the versaplanetaries but would prefer not to have to use a 3 stage reduction to get to the sub-100 rpm realm.
Clue me in on what you use in these applications.

Crazy suggestion: Make the Neverest motors legal. They are about the same power range as window motors. Bonus, also have a funky output shaft with only a few cots ways of interfacing

[Greg Needel]

Originally Posted by JesseK

I would like to see a better solution for using LED's. Right now LED's paralyze my team with how many choices / setups there are, so usually there's a mediocre attempt at them but never a finished product.
- How do we connect power to the LED's?
- Which LED brand, model, and length do we use?
- Do we really have to care that each light is addressable, seriously?
- To control them do we use an offboard processor, use a Spike, or is there a better way?

Would love to have something simpler that doesn't depend on in-house custom circuitry or an arduino. Plug this 12" LED strip into this device, then plug this device into the PDB and into the RoboRIO using these connectors. Then use this sample code to get going with writing different colors/brightnesses or blinking lights to the LED's.

So we built a prototype of a product about a year ago to do simple LED control called the "blinkin Board"

The basic idea was to allow on a single board the ability to drive the WS281* LEDs or 12v RGB LEDs. The voltage buck 12 to 5 with 3 amps of supply is on board, so just give it 12 volts and it would work.

The real beauty (in our minds) was the fact that you can control either kind of strip with a PWM input, we were able to sub-divide the standard PWM signal into tons of discrete signals and using a provided chart teams could make their LEDs do things with no hard programming required. There are a bunch of jumpers on the board so you can select things like your team colors & strip length.



We got the prototype almost ready for production (needed a bit more DFM work and software) but we ran out of time as we needed to focus on other things (like the SPARK). We also were not sure how many teams would be interested in something like this to justify the effort to bring it to market. It is still something we can definitely make, we just need to figure out where on the priority list it falls compared to some of the other large initiatives REV is working on.

[Chris is me]

Originally Posted by bigbeezy

Smaller 3/8" hex bearings. Ideally ones that could be used in a 1x1 tube. So like 7/8" OD with a flange. We used crummy conveyor bearings from Grainger with our collector, which surprisingly didn't fail during competition.

This product used to exist from AM, but it required such a thin inner race at the points that the bearings would fail catastrophically at relatively low loads.

[thefro526]

Originally Posted by Chris is me

This product used to exist from AM, but it required such a thin inner race at the points that the bearings would fail catastrophically at relatively low loads.

FWIW, I would love to see FR6's with a 3/8 Hex bore make a come back, I've used them in 2013, 2014 and 2016 without issue. (Bought stock when they were discontinued) From what I've seen, they can be used in Auxilary mechanism, specifically high reduction gear boxes and intake type gearboxes without issue.

[ASD20]

Originally Posted by dv/dt

I'm sure I'm missing something and some of this has been alluded to, but how about a small, lightweight, easily mounted replacement for a window motor? Something with low rpm and modest torque. The window motors are flimsy and hard to mount. I love the versaplanetaries but would prefer not to have to use a 3 stage reduction to get to the sub-100 rpm realm.
Clue me in on what you use in these applications.

+100 If it had a easy mounting pattern and a hex output shaft that would be amazing. Easy to find specs and a way to actually buy it would also be pluses.

[TehSwegGey]

Originally Posted by Chak

Every broken gear picture on CD has the teeth sheered off. I've never seen the body of a gear crack.

How possible would a combination gear be? Something with a lighter but still strong internal portion and a steel outer? It might be better than holes for the smaller gears? Like this maybe?



I'm new to this stuff...

[Rangel]

Originally Posted by marshall

Ain't gonna happen anytime soon for a lot of reasons. Unless of course all you want is the PIXY CAM with a CAN interface... you can make that happen without a whole lot of effort... use the HERO board to do it maybe?

All that being said, 900 is actively talking about how to "cheesecake" vision onto other robots in the future... no idea what that means at the moment but we're talking about it.

The biggest issue with vision isn't the vision or the detection. It's getting more teams to add encoders to their drivetrains and mechanisms. You need feedback to make use of the vision data.

I'd love to see more COTS options for encoder integration.

I would also love to see the CIM-Encoder that AM introduced this season improved. It's hollow and the little center spacer plate isn't square. Make it filled in, more robust, and square the center plate.

And I REALLY hope brushless is coming based on what CTRE was showing off. I'd love to see it happen.

Why couldn't a gyro be an alternative to having encoders on the robot? If the gyro was part of the board, it could likely still be kept all together. I'm not sure if we even used the encoders for our vision tracking this year and we hit every autonomous shot at champs. I'd imagine a game with a bigger goal would be even better.

Edit: Granted, we did use the encoders for going forward a set distance in teleop. This probably would effect our accuracy in autonomous. I would imagine not by too much though. In teleop though, auto tracking would be unaffected by not having encoders.

[Andrew Schreiber]

Originally Posted by Rangel(kf7fdb)

Why couldn't a gyro be an alternative to having encoders on the robot? If the gyro was part of the board, it could likely still be kept all together. I'm not sure if we even used the encoders for our vision tracking this year and we hit every autonomous shot at champs. I'd imagine a game with a bigger goal would be even better.

Edit: Granted, we did use the encoders for going forward a set distance in teleop. This probably would effect our accuracy in autonomous. I would imagine not by too much though. In teleop though, auto tracking would be unaffected by not having encoders.

Gyros tend to need to be level. You can cheat to an extent with some of the IMU boards doing a self leveling routine on startup and I guess that's probably a viable approach. Just don't forget it.

But why Encoders - At some point you need to get to a point on the field and that's pretty hard without encoders in the drive.

[GDG 2337]

FR6-ZZ HEX PS2 Radial Bearings at Boca Bearing, showing 4700 in stock

http://www.bocabearings.com/bearing-...12-FR6ZZHEXPS2

[asid61]

Originally Posted by GDG 2337

FR6-ZZ HEX PS2 Radial Bearings at Boca Bearing, showing 4700 in stock

http://www.bocabearings.com/bearing-...12-FR6ZZHEXPS2

And look at that- only $14 each! What a steal. /sarcasm
Seriously though, nice find. Good to know there's a source out there for 3/8" hex bearings in tough situations. However, I would still want a 7/8" OD 3/8" hex bearing available from Vex or AM.

[asid61]

Originally Posted by TehSwegGey

How possible would a combination gear be? Something with a lighter but still strong internal portion and a steel outer? It might be better than holes for the smaller gears? Like this maybe?



I'm new to this stuff...

It seems like that would be much more expensive than just making a lightened steel one, however I can't comment on the strength.

[Munchskull]

Motor question, are the RS 775 and RS 550 standard motor sizes? If so how are they measured?

[PAR_WIG1350]

Originally Posted by Munchskull

Motor question, are the RS 775 and RS 550 standard motor sizes? If so how are they measured?

Here is what you are looking for

[Peter Johnson]

Originally Posted by JesseK

I would like to see a better solution for using LED's. Right now LED's paralyze my team with how many choices / setups there are, so usually there's a mediocre attempt at them but never a finished product.
- How do we connect power to the LED's?
- Which LED brand, model, and length do we use?
- Do we really have to care that each light is addressable, seriously?
- To control them do we use an offboard processor, use a Spike, or is there a better way?

Would love to have something simpler that doesn't depend on in-house custom circuitry or an arduino. Plug this 12" LED strip into this device, then plug this device into the PDB and into the RoboRIO using these connectors. Then use this sample code to get going with writing different colors/brightnesses or blinking lights to the LED's.

FWIW, introductory courses in embedded electronics in college were all about blinking LED's, and connection of those circuits to the corresponding code was way more straightforward than the FRC LED situation.

We've used standard cut-to-length non-addressable 12V LED strips (Amazon sells lots of these in various colors) and this tiny board from pololu to control them: https://www.pololu.com/product/2802

Basically the polulu board is a simple digital switch (think of it like a spike without the ability to reverse the voltage polarity), controlled by a PWM signal. The linked one above is 3A but they also have higher current ones. The wiring diagram shows how to wire it up. Load is LED strip, source is either 5V or 12V (depending on LED strip voltage) from VRM. The PWM comes from a PWM output on the roborio. You do need 5V in from somewhere too; if you're using 5V LEDs or a PWM from a MXP board you can get 5V from that connection, or you can get it from the VRM or RoboRIO DIO. I think we used the Talon class in software to control the PWM output--set(0) turned the LEDs off, set(1) turned them on. Easy enough to do das blinkenlights from there with software timing.

[nuclearnerd]

Originally Posted by Greg Needel

So we built a prototype of a product about a year ago to do simple LED control called the "blinkin Board"

We got the prototype almost ready for production (needed a bit more DFM work and software) but we ran out of time as we needed to focus on other things (like the SPARK). We also were not sure how many teams would be interested in something like this to justify the effort to bring it to market. It is still something we can definitely make, we just need to figure out where on the priority list it falls compared to some of the other large initiatives REV is working on.

Oh I would definitely buy this. The need for a dedicated power supply and controller has kept me from prioritizing blinkinlights in the past. Your board looks like a pretty simple drop-in solution.