[FTC]: Drive Platform- Design Exercise

[DavisDad]

In this thread, my son and I will document our process of designing and building a drive platform. We hope to finish the build and programming this summer.

The process will consist of the following steps:


Establish design environment: CAD software, new Android programming tools, etc...
Establish an engineering design process to follow.
Design
Build
Test
Repeat steps 3 through 5 until finished


Anyone interested is welcomed to join in the exercise. All comments, critiques and suggestions welcomed.

[DavisDad]

CAD Software:

We've found 3D solid modelling software indispensable for designing our mechanical systems. We've used SolidWorks for the past several years, and SW has served us very well.

This year, I'll be exploring converting to a new software: "Onshape". This is a new CAD modeling software where all the computing is done “in the cloud”; computing is done by servers through the internet and does not require special computers or licensing on the computer = no IT overhead. Onshape also has new collaboration tools/capability similar to Google Drive and Google Docs. Onshape is FREE and easy to gain access. See here: Onshape- The Future of CAD
(https://www.onshape.com/)

We'll be converting to Onshape and using it for this project. My son has worked with Onshape more than me, and thinks we'll still need SW for some of the functionality not yet available in the current beta version. We'll see...

[DavisDad]

Engineering Design Process

Here's a typical approach from Wikipedia (link (https://en.wikipedia.org/wiki/Engineering_design_process)):

Research
Feasibility
Conceptualization
Design requirements
Preliminary design
Detailed design
Production planning and tool design
Production


For this drive platform project, we'll use an abbreviated version. We've already decided the platform will be a Mecanum system. The project is based on previous years' platforms. We'll skip to the "Design Requirements" step and capture previous design work in a document called "User Requirements Specification".

Here's a video of our previous version on the modular Mecanum drive platform:

https://i.ytimg.com/vi/QL6rHh3uY8Q/mqdefault.jpg (https://www.youtube.com/watch?v=QL6rHh3uY8Q)

http://simhardware.org/img/Simple_DriveAssembly.JPG

[DavisDad]

Here is the URS for the platform design:

User Requirements Specification
FTC 2015/2016 Modular Drive Platform
(http://simhardware.org//img/FTC 2016 Drive Platform URS-Rev0_cr 19jul15.pdf)

[DavisDad]

I've purchased the Modern Robotics Inc (RBI) new modules from their website as well as 4 of the new Matrix 12V gear-motors. We used the 9V motors for our previous mecanum platform with good success and want to test these. Matrix has yet to publish specs for their 12V motors. There's a lot of information on the AndyMark and Tetrix motors and I want to evaluate and compare the Matrix option.

I've modeled the motor with OnShape (my first use of this CAD software). The model is "public" and may be viewed and copied by anyone with an OnShape account : LINK (https://www.onshape.com/)

http://simhardware.org/img/Matrix 12V GearMotor_CAD_cr 26jul15.png

I'm setting up a test rig and will publish torque/RPM/power data next week. From what I've tested so far, the motor has the following:


52:1 planetary gear set
Approximately 200 rpm no load speed


The shaft end dimensions are identical to last years 9V motor. Specs here: LINK (http://matrixrobotics.com/wp-content/uploads/2013/07/MATRIX_HTMotor_Spec_v2.pdf). I'd anticipate a stall torque above 500 in-ounces (36 Kg-cm).

[DavisDad]

OnShape (OS) hasn't yet released the drawing function: "Coming soon for all users". The OS model exported easily to SolidWorks where I made this dim drawing of the Matrix motor:

http://simhardware.org/img/Matrix 12V GearMotor-50-0014_cr 26jul15.PNG
http://simhardware.org/img/Matrix 12V GearMotor-50-0014.PDF

[DavisDad]

Tests for Matrix 12V motor below:

http://simhardware.org/img/Matrix 12V GearMotor test_cr 26jul15.JPG

http://simhardware.org/img/Matrix 12V GearMotor test rig_cr 26jul15.JPG

[wgardner]

Thanks for the nice data!

Did you test the motor at only the 4 points shown in the plot, or at other points? If only the 4 points, then they would suggest that the stall torque is 516 oz-in or below. Linear extrapolation of the first 3 points would put the stall torque around 467 oz-in. Would you agree? I think if the stall torque were around 467 oz-in, it would also make the power curve end up being closer to the more traditional inverted parabola.

How did you like your DIY experimental setup? How hot did the wood pieces get? How long did you run the Matrix motor stalled, and did it show any signs of failure (e.g., smoking, or reduced performance afterwards)?

Did you measure the voltage of the battery (i.e., was it truly around 12 v or was it higher as they often are when they are fully charged)? Do you have any comments on the usage and performance of the tachometer (i.e., did it work as expected, would you buy it again, and were there any unexpected issues you ran into when using it)?

Given that you went to the trouble of creating such a nice DIY setup, I'd love to see you run the same tests with a Tetrix and Neverest motor to see how they compare on the identical setup, if you'd be willing.

Thanks again!

[DavisDad]

Did you test the motor at only the 4 points shown in the plot, or at other points? If only the 4 points, then they would suggest that the stall torque is 516 oz-in or below.

At the 4 points; the graph is a connect-the dots type. I’m ordering an in-line Watts/Volts power analyzer and will repeat again with more points.

Linear extrapolation of the first 3 points would put the stall torque around 450 oz-in. Would you agree?

Yes, my data aren’t linear.

How did you like your DIY experimental setup? Was easy to use. With power analyzer and scale hooked to PC (USB), I’d like to be able to log force, Watts, Volts and Amps data to a file for plotting.

How hot did the wood pieces get? Didn’t feel with touch any heat generated.

How long did you run the Matrix motor stalled, and did it show any signs of failure (e.g., smoking, or reduced performance afterwards)?

3-4 seconds; long enough to get scale reading. No noticeable effect on motor.

Did you measure the voltage of the batteryNo, can’t find my volt meter. :)

Do you have any comments on the usage and performance of the tachometer No problems. I also used it to measure the motor speed of about 11,000 rpm.

I'd love to see you run the same tests with a Tetrix and Neverest motor to see how they compare on the identical setup, if you'd be willing. Will do… other motors are at school and won’t be able to test them until September. We also want to test the secondary gearbox performance we’re adding as part of this project.

[DavisDad]

I've been spending some time working with OnShape. I'm having good success doing the typical cadding we done in the past for First. Below is the MRI Power Module. OnShape has the following advantages over other CAD packages:


FREE
Cloud Based- works like Google Docs
Works on any platform- PC, MAC, Tablet, even smartphones. The computing is done "in the cloud", so device is only a browser interface.
No IT required
Revision control is very advanced- similar to GitHub
Collaboration capabilities are terrific- multiple users can work on the same project in real time.
No files to maintain


http://simhardware.org/img/FTC Power Module CAD_cr 01aug15.png

[mozrila]

Can you invite a user to use this software? I think it would be interesting to play with and I need an invite to access it. Thanks!

[DavisDad]

Can you invite a user to use this software? I think it would be interesting to play with and I need an invite to access it. Thanks!

Once you set up an account, you can invite other users to access private documents. I've set mine up as public, so anyone can view or copy. My project name is "FTC 2015/2016"

[DavisDad]

Current design using Matrix 12V motor, Vex 4" Mecanum and Dremel angle drive for gearbox:

http://simhardware.org/img/TechnadoBot_OS%20model_cr%2004aug15.png

[wgardner]

Current design using Matrix 12V motor, Vex 4" Mecanum and Dremel angle drive for gearbox:

Looks great, and I'm looking forward to playing with Onshape soon! Thanks for letting us know about it.

FYI, if you're considering this CAD model for use on a real robot, you might want to read some of the reviews on the Dremel angle drive complaining of lack of durability. It's probably made for high speed but not necessarily high torque. It would be a shame to buy 4 of them at $20 each, build a robot based on them, and then find that they break the first time your robot runs into a wall or another robot, stalling your motor.

[DavisDad]

... you might want to read some of the reviews on the Dremel angle drive complaining of lack of durability...

Hi wgardner,

Thanks for the heads-up. I have read the reviews. I think the failures are due to the very small square shaft that connects to the Dremel. The rest looks substantial enough. I plan to test with torque numbers x 3, and if it breaks, rework the connection to the motor. A nice feature of the square shaft is that it's very forgiving of alignment. I'll post a screen-shot later...

Craig

[wgardner]

Great! I look forward to seeing pix of the final result, and learning how much torque it can withstand.

Cheers.

[DavisDad]

OnShape has just published a curriculum package: LINK (https://www.onshape.com/cad-blog/onshape-free-professional-3d-cad-in-the-classroom?utm_source=hs_email&utm_medium=email&utm_content=21055719&_hsenc=p2ANqtz-9fcPFysiXfrIM9cAs4OYq4eCAzyBdx7TkmDxArFwm_YgGG2wbt SX_aIWyrwoqoQDgoieWyk7eS6-AQGmSXhXYy4RI8FJ0BnCkeT9PxDXxdqSApIh8&_hsmi=21055719)

Onshape offers a completely free version of its software with all the same functionality as the professional version – and it’s engineered to be easy to set up and get started.
Immediate Access: You and your students can go here and set up your free account in less than two minutes!

Curriculum Guidance: Onshape is creating curriculum for teachers to use in their classrooms. A free Instructor Kit is available now. The kit contains videos, exercises, and quizzes – including an instructional video teaching you how to use the kit – and covers everything that first-time users need to know to learn CAD.

[GeeTwo]

FYI, if you're considering this CAD model for use on a real robot, you might want to read some of the reviews on the Dremel angle drive complaining of lack of durability. It's probably made for high speed but not necessarily high torque. It would be a shame to buy 4 of them at $20 each, build a robot based on them, and then find that they break the first time your robot runs into a wall or another robot, stalling your motor.

Even if you solve the durability problem, the roller-on-roller transfer of energy from one axle to the other is not likely to transfer much torque (though it would be good for high-speed, low torque applications, like attaching to a dremel). With that device in your drivetrain on the wheel side of the gearbox, I doubt you would be able to get anywhere near stalling the motor; I'd be more worried about not getting enough traction to get the robot rolling at all. I don't know the contact force or coefficient of friction, so I can't even give a rough numerical estimate of the torque, but it's something else you should check before including it in your design.

[DavisDad]

...the roller-on-roller transfer of energy from one axle to the other is not likely to transfer much torque...

The gearbox has straight bevel gears; my model's simplified representation doesn't show the the teeth.

[mhaeberli]

Nice work!

On a very distantly related note, are there any suggestions anywhere as to how to set up an Android Virtual Device Emulator to closely track the ZTE Speed? Obviously, one wouldn't be able to do more than test out stuff not directly related to motor control, etc, except maybe with some input and output test files...

Thanks,

Martin

(one of the mentors for FTC #7593 TigerBots).

[DavisDad]

Hi Martin,

Have you seen the threads at the FTC forum. There's a lot of activity there. Here's an example:

Thread: End to end response times (http://ftcforum.usfirst.org/showthread.php?4364-End-to-end-response-times&p=14927&viewfull=1#post14927)

[mhaeberli]

Thanks!

[DavisDad]

Here's a photo and CAD of angle gear. The square shaft is pretty light, but the design is cool as square drive shaft is routed through the hollow shaft and press fitted at the gear end. There's a lot of flex which make alignment with motor easy. I'll test for ability to handle about 1500 in-oz.

http://simhardware.org/img/Dremel Angle Drive.JPG
http://simhardware.org/img/Dremel Angle Drive_CAD.JPG

[DavisDad]

Looked at stress in square shaft. Assumed round shaft 2.5mm diam and 500 in-oz (3.53 Nm) and plugged into this on-line calculator: TORSION OF SOLID AND HOLLOW SHAFTS (http://www.amesweb.info/Torsion/TorsionalStressCalculator.aspx)

It returns 160 kPSI (1100 MPa). That about 5x the the stress to break a steel rod. It's not looking good for the square shaft. Now I need to look at the gears; they probably aren't designed for the torque either...

[wgardner]

If the dremel drive doesn't work out, you could probably make your own version using the bevel gears at ServoCity and some Actobotics parts, like what is shown at the bottom of this link (https://www.servocity.com/html/bevel_gears.html). So far, we're quite happy with the 1/4" axles of the Actobotics set: they're much stronger than the Tetrix axles and the bearings for the Actobotics axles seem much nicer than the bronze bushings used in the Tetrix set.

[DavisDad]

If the dremel drive doesn't work out, you could probably make your own version using the bevel gears at ServoCity and some Actobotics parts, like what is shown at the bottom of this link (https://www.servocity.com/html/bevel_gears.html). So far, we're quite happy with the 1/4" axles of the Actobotics set: they're much stronger than the Tetrix axles and the bearings for the Actobotics axles seem much nicer than the bronze bushings used in the Tetrix set.

Thanks for the link, and the price is right. The same steel gears from mfgr are about $25 ea.

[DavisDad]

I tested the angle drive for torque strength. I jigged it up and applied force with a torque wrench set at 20, 25 & 30 in-lb (480 in-oz). At 30 in-lb, the shaft started "unraveling", twisted and broke. It's a bundle of wires formed into a square shaft.

I'll drill out the wire shaft and make a coupling to press fit into the 4mm ID/6mm OD bearing shaft.

http://simhardware.org/img/ShaftTest-03.JPG
http://simhardware.org/img/ShaftTest-01.jpghttp://simhardware.org/img/ShaftTest-02.jpg

[wgardner]

I've been spending some time working with OnShape.
I'm looking for CAD models of the Modern Robotics components and your nice picture is all that I can find so far.

Did you make that model yourself or get it from somewhere? Are there models for the other components? If you made them yourself, would you be willing to export them and share them?

Thanks!

[DavisDad]

I've modeled the new motor, servo and main power modules. They are "public" at OnShape. I can export to most file types; what do you prefer?

[wgardner]

I've modeled the new motor, servo and main power modules. They are "public" at OnShape. I can export to most file types; what do you prefer?

Great! I'll just find them myself on OnShape! Thanks!

[DavisDad]

http://simhardware.org/img/MRI%20Control%20Modules_cr%2011aug15.jpg

[DavisDad]

Modern Robotics Inc. has posted CAD files for the new controls modules here:Download Files (http://modernroboticsinc.com/Downloads.aspx)


Core Modules STEP files
Core Device Interface PDF
Core Device Interface 3D PDF
Core Legacy Module PDF
Core Legacy Module 3D PDF
Core Motor Controller PDF
Core Motor Controller 3D PDF
Core Power Distribution Module PDF
Core Power Distribution Module 3D PDF
Core Servo Controller PDF
Core Servo Controller 3D PDF

[DavisDad]

Made the coupling:

http://simhardware.org/img/MotorCoupling_cr%2017aug15.JPG

[JohnMMcD]

Modern Robotics Inc. has posted CAD files for the new controls modules here:Download Files (http://modernroboticsinc.com/Downloads.aspx)

...

Thanks for posting this, Craig. To anybody else who is interested in downloading these, just grab the STEP files - this zip file includes all the PDFs.

The PDFs are a little disappointing - they don't include an orthographic projection or dimensions.

[DavisDad]

Hi John,

Yes, the PDFs don't help much. Have you worked with CAD solid modelling software? I recommend checking out OnShape. It's free and requires no software installation or difficult IT maintenance. Projects at OnShape can be "public" and anyone can view & copy. The MRI files have been imported to OnShape and are available for anyone to use.

Craig

[JohnMMcD]

Yes, I took a look at OnShape based on your previous posts. It looks interesting, but my CAD skills are quite rusty, so I can't give it a fair evaluation. I'm going to show it to my team's CAD person to see if he's interested.

[DavisDad]

Completed the basics of the platform design. Trying to maximize the open space inside the 18in square limit. Additional structure, particularly front, will be designed as determined by the game functions. If the open space is not required, a simpler straight drive design could be used. We built and competed with the straight drive and had no failures other than a broken mecanum roller from dropping during transport.

http://simhardware.org/img/DrivePlatform_cr27aug15.png

http://simhardware.org/img/StraightDrive_cr27aug15.png

[DavisDad]

Oh well, the mecanum design is pretty much worthless for this year's game; back to the drawing board. I'm thinking BIG tires:

http://simhardware.org/img/BigWheelBot_15sep15.png

[Gdeaver]

A 30 degree slope is bad. Sixty is quite a problem.

[DavisDad]

A 30 degree slope is bad. Sixty is quite a problem.

I get 30 & 50 deg from CAD model. Yes, keeping the COG low enough to climb the 50 deg bars will be a challenge.

[MattRain]

I get 30 & 50 deg from CAD model. Yes, keeping the COG low enough to climb the 50 deg bars will be a challenge.

I don't have the exact measurements, and not currently in the room, but I would agree that the angles are around 30 and 50 degrees.

Who said you had to "climb" the 50 degree section.... (I see the more advance bots just dragging themselves past that section in the endgame, I.e. starting from the low zone, and reaching to the bar.) (During the regular 2 minute time period, just driving to the low zone, and extending to the high goal as well, over the churros)

[DavisDad]

...over the churros)

Where's the term churro come from?

[Michael Coleman]

Where's the term churro come from?

They look like the churro fried-dough pastry: https://en.wikipedia.org/wiki/Churro.

[MattRain]

Where's the term churro come from?

FRC came up with the term for them. I think it was an intern at Andymark actually. Well known little product, used mainly in the Kit of Parts drive train for FRC.

[wgardner]

They look like the churro fried-dough pastry: https://en.wikipedia.org/wiki/Churro.

:) Yeah, that. Must be a regional thing.

I lived for a long time in San Diego and I understood the reference immediately as my kids grew up eating them with their Mexican food kids meals.
http://www.rubios.com/menu/other-fare-and-kids/churro/

[orangemoore]

Where's the term churro come from?

The bars running across the mountain are known in FRC as a churro.
http://www.andymark.com/product-p/am-churro.htm

[wgardner]

The bars running across the mountain are known in FRC as a churro.
http://www.andymark.com/product-p/am-churro.htm
Yeah, but they're called a churro in FRC too because they're just like the mexican dessert. It's not like FRC came up with the term out of nowhere. ;)

[DavisDad]

Here's a revised version of the drive platform User Requirements document: FTC 2016 Drive Platform URS-Rev1 (http://simhardware.org/img/FTC 2016 Drive Platform URS-Rev1_cr 16sep15.pdf)

[orangemoore]

:) Yeah, but they're called a churro in FRC too because they're just like the mexican dessert. It's not like FRC came up with the term out of nowhere. ;)

I was just trying to explain the origin of the term that most FTC teams wouldn't know about.:)

[GeeTwo]

:)

I was just trying to explain the origin of the term that most FTC teams wouldn't know about.:)

Really? Are there that many FIRST teams in places without Taco Bell or Panchos? I know they aren't "real" churros, but when I read the name on an AndyMark parts list, I knew sort of what to expect. Maybe if the world were a bit more like Demolition Man, where "all restaurants are Taco Bell now"...I'd still like to know how the three seashells work without massive chafing.

[orangemoore]

Really? Are there that many FIRST teams in places without Taco Bell or Panchos? I know they aren't "real" churros, but when I read the name on an AndyMark parts list, I knew sort of what to expect. Maybe if the world were a bit more like Demolition Man, where "all restaurants are Taco Bell now"...I'd still like to know how the three seashells work without massive chafing.

What I mean is that in the post that was first questioned about the term "churro" came from. (To my knowledge) he was asking what a churro part was and not the actual piece of food.

But hey, I might be totally wrong.:) Because we seem to be talking about two different issues. I am talking about what the actual part a churro is. While everyone else is talking about the food term and what type of food it is.

[DavisDad]

Drive Platform Design Strategy

My son and I have been thinking about this season's game vs. drive platform design. The "Mountain" element provides new and difficult challenges that are very different from previous years. Here are some of the issues we've been thinking about:


Scoring- The scoring capability related to drive design is challenging related to climbing the mountain. We estimate that purely driving/climbing ability can score 80 points by driving up to the "Mountain High Zone" (40 autonomous & 40 tele-op). And... if the robot can climb to the High Zone, we'll be able "hang" using fairly simple mechanisms (80 points hang & 20 points "All Clear Signal"). So... climbing could affect a total of 180 points for the team.

http://simhardware.org/img/Scoring%20Table_dr%2020sep15.png


Drive vs. Climbing- To climb into the High Zone, the robot has to climb the 30 deg angle ramp and drive over the "churros" (rungs), and then climb the rungs at 50 deg. We're thinking of the High Zone as a ladder leaned at a 50 deg angle with rungs spaced at 5.33" intervals. Possible drive types:


Standard 4" wheels- will fall through the rungs
Big wheels- approximately 8", wheel base is only about 8" and center of gravity (COG) must be low or robot will flip. Wheels could "trip over" debris; hindering autonomous navigation.
Tank treads- much more complex system to design than wheels.


http://simhardware.org/img/BigWheelBot_cr%2020sep15.pnghttp://simhardware.org/img/Big%20Wheel%20Hang_cr%2020sep15.png


Physics- Any wheel or tank tread design will not have enough friction to climb at 50 deg with smooth contact with the rungs (assume < 1 coeff friction) . The treads or wheels must be able to "grab" the charro or the charro's ribs. The power required to climb 50 deg is much higher than previous years’ 15 deg incline. It’s complicated, but we’ve done a rough estimate for a 30 lb robot with wheels, and got about 500 in-lb torque at each axle.


http://simhardware.org/img/Wheel%20Torque_cr%2020sep15.png

[DavisDad]

Big Wheel Design

We did some design and testing. We modeled the AM-0420 (http://www.andymark.com/product-p/am-0420.htm) 8" Wheel with an automotive "cogged V-belt", model # AX-23 (http://www.amazon.com/gp/product/B002HAT0XY?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00). The idea is that the belt will be flipped inside out and snugly fit the wheel OD. We're thinking well cement the 2 rubber surfaces together.

The auto parts store didn't have this small a fan belt, but I got a longer one with the same cog pattern and cross-section. We mocked up the 50 deg angle with a churro at the correct alignment, rigged the belt around an 8" wheel and rolled the wheel per design by hand. It felt like it should work; worked well enough that we ordered 4 wheels and 4 belts.

http://simhardware.org/img/8in%20Wheel%20VBelt.pnghttp://simhardware.org/img/Wheel%20Protype_cr%2020sep15.JPG

[Gdeaver]

Time to review the concept of center of mass with the students. Both static and dynamic. Saturday we let the students go on design for different aspects of the game. Half way into the meeting, we gave them a power point presentation on COM that we give the FRC students. After a little playing on the mountain with this summers practice bot, the concept of COM really sunk in. We can "crash" the practice bot up the 30 degree slope. To drive up the 50 degree slope is challenging.

[GeeTwo]

What I mean is that in the post that was first questioned about the term "churro" came from. (To my knowledge) he was asking what a churro part was and not the actual piece of food.

My quote then was a response to the side discussion about familiarity with the food. I fully understand that the original question was about the aluminum stock, not the fried dough. My point was that if you are familiar with the food, you wouldn't ask the question about the aluminum.

Big Wheel Design

We did some design and testing. We modeled the AM-0420 (http://www.andymark.com/product-p/am-0420.htm) 8" Wheel with an automotive "cogged V-belt", model # AX-23 (http://www.amazon.com/gp/product/B002HAT0XY?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00). The idea is that the belt will be flipped inside out and snugly fit the wheel OD. We're thinking well cement the 2 rubber surfaces together.

This looks like a great solution - if you can find the right pitch timing belt, it should interface well with the churros even at the steep angle. If rubber cement doesn't do the trick for you, you might want to check on glues meant to hold a patch in a tire. These glues are usually painted on, set in place, and then partially burned to form a solid joint. Of course, I suggest doing the burning outside, on a metal pad, away from other combustibles, with a class A+B fire extinguisher handy just in case things go awry.

Time to review the concept of center of mass with the students. Both static and dynamic. Saturday we let the students go on design for different aspects of the game. Half way into the meeting, we gave them a power point presentation on COM that we give the FRC students. After a little playing on the mountain with this summers practice bot, the concept of COM really sunk in. We can "crash" the practice bot up the 30 degree slope. To drive up the 50 degree slope is challenging.

Thanks! I'll incorporate a bit of this into our FRC pre-season training this year.

[DavisDad]

... - if you can find the right pitch timing belt, it should interface well with the churros even at the steep angle...

I have one of these arriving tomorrow:

Gates 255L050 PowerGrip Timing Belt (http://www.amazon.com/Gates-255L050-PowerGrip-Timing-Length/dp/B00CMIXQ72/ref=sr_1_1?s=industrial&ie=UTF8&qid=1442832234&sr=1-1&keywords=255L050)

http://ecx.images-amazon.com/images/I/41q-lQNJKYL._AA160_.jpg

[manojkr]

Thanks for all the information on this thread. We are a rookie team of 6 with mostly 7th graders this year. While the team is starting to use PTC, I came across this thread and got quite interested in onshape. We are using tetrix kit. Are there tetrix models available on onshape? How does that work? Thanks in advance for the help.

-Manoj
FTC 10295 - Yellow Jackets

[DavisDad]

...Are there tetrix models available on onshape? How does that work? Thanks in advance for the help....

Hi Manoj,

Yes, there are Tetrix as well as Modern Robotics Inc. and Matrix models that have been added to OnShape. You asked: "How does that work?" Are you asking about how use OnShape? Or... specifically how to use the "Public" models at the OnShape site?


Craig

[cadandcookies]

Looking at that spreadsheet, I might consider re-reading the rules. To my knowledge you cannot score points for both hanging and parking in the high zone during the same match-- see 1.5.3-4 in the Game Manual Part 2.

I'm also interested in your numbers for debris scoring-- were you able to fit 20 pieces of debris in the goals? My team isn't meeting again until Thursday, so I can't check this myself.

Thanks, and have a great season!

[DavisDad]

...you cannot score points for both hanging and parking in the high zone during the same match-- see 1.5.3-4 in the Game Manual Part 2.

Hmm... looking at the scoring table in Scoring Summary 1.7, it looks like you can. I don't understand what 1.5.3.4.e means: "e. Cliff Zone: See End Game scoring". But... we'd be in the "High Zone", not the "Cliff Zone", at the end of Driver-control period.

...were you able to fit 20 pieces of debris in the goals? ...

We haven't set up the field; just eye-balling it from the CAD models.

[DavisDad]

...were you able to fit 20 pieces of debris in the goals? ...!

I took a closer look at the CAD model and it looks like about 10 pieces will fill the bin.

http://simhardware.org/img/bin_fill.jpg

[cadandcookies]

Hmm... looking at the scoring table in Scoring Summary 1.7, it looks like you can. I don't understand what 1.5.3.4.e means: "e. Cliff Zone: See End Game scoring". But... we'd be in the "High Zone", not the "Cliff Zone", at the end of Driver-control period.


According to the manual:
Point levels are
based on the Area of the Mountain that Supports the Robot. The Score is not dependent upon being In or Completely In an Area.

Also relevant:
The last thirty seconds of the Driver-Controlled Period is called the End Game.

and I'm not sure what conditions you could find where you could be scored to be both fully supported by the mountain High Zone and the Pull-Up Bar at the end of the match, as they're mutually exclusive conditions, since the End-Game is part of the Driver Controlled Period.

Could you explain how you came to a different conclusion?

I took a closer look at the CAD model and it looks like about 10 pieces will fill the bin.


Nice! This is a bit higher than my estimate, which was 6 based on the CAD model.

[DavisDad]

...and I'm not sure what conditions you could find where you could be scored to be both fully supported by the mountain High Zone and the Pull-Up Bar at the end of the match, as they're mutually exclusive conditions, since the End-Game is part of the Driver Controlled Period.

Could you explain how you came to a different conclusion?

The statements below seem to conflict, but I agree your interpretation makes more sense.

"The Driver-Controlled Score is based on the location of the Scoring Elements, all Clear Signals, and Robots at the end of the Match after all objects have come to rest."

"Robots earn points based on where they are Parked On the Mountain at the end of the Driver-Controlled Period."

I was assuming,and the Scoring Summary (1.7) seems to indicate, that "Driver Control Period" and "End Game" are 2 different periods. But... the robots are under driver control during the End Game.

[manojkr]

Hi Manoj,

Yes, there are Tetrix as well as Modern Robotics Inc. and Matrix models that have been added to OnShape. You asked: "How does that work?" Are you asking about how use OnShape? Or... specifically how to use the "Public" models at the OnShape site?


Craig

Hi Craig, thanks for confirming that. I meant if those models are readily available to use or do I need to do additional importing of the models. I guess when I start using it might become more clearer. Let me try it tonight and I'll get back if I've more questions.

Thanks
Manoj

[DavisDad]

Thanks Nick (cadandcookies) for pointing out my error in scoring related to driving/climbing of the robot, as well as capacity of the goals for Debris. Below is revised scoring:

Scoring- The scoring capability related to drive design is challenging related to climbing the mountain. We estimate that purely driving/climbing ability can score 40 points by driving up to the "Mountain High Zone" in Autonomous Mode. And... if the robot can climb to the High Zone, we'll be able "hang" using fairly simple mechanisms (80 points hang & 20 points "All Clear Signal"). So... climbing could affect a total of 140 points for the team.

http://simhardware.org/img/Scoring%20Table%20REV2_cr%2021sep15.png

[DavisDad]

... if those models are readily available to use or do I need to do additional importing of the models. ...

They are available in 2 ways within OnShape.

Any "Public" workspace can be copied by anyone using OnShape. Parts and assemblies created with OnShape have all the attributes of the original.
Models created in other CAD software can be uploaded and used within OnShape, but don't have the original detail (e.g. sketch dimensions). Tetrix, AndyMark, Modern Robotics Inc, McMaster-Carr, etc. CAD models are available at their websites as STEP files and are very useful for CADing.


The above is true for all the mainstream CAD packages: Solidworks, Creo, Inventor and more. My opinion is that OnShape is ideal for FIRST as all computing and file handling is done "in the cloud" and eliminates the IT headaches for PC installed software. OnShape can be used from any machine and any OS using web browsers: Safari (Mac OS only), Mozilla Firefox, Google Chrome & Opera (not IE). And... it's FREE with easy account set-up.

[manojkr]

....They are available in 2 ways within OnShape. ....


Thank you so much for your help. I was able to import the field setup from Andymark.

[DavisDad]

We've done some work on the "Big Wheel" concept design to look at the center of mass (CoM) issues:


8" wheels result in a narrow wheel base ~8"
When climbing the 50 deg churros rungs, the contact point of the wheels narrows to 5.3" and the vertical distance inside the wheel base narrows to ~3.5"
Not only must the CoM be kept inside the 3.5" zone, torque from the rear wheel can flip the robot.
We want to maintain 2" clearance between robot bottom to floor. This prevents lowering the motors, battery, etc. This will allow "debris" to pass under without obstructing travel of the robot. "Tripping" over the blocks could hinder autonomous navigation.


We sketched a design where the motors are set forward and battery is at front. Even this does not put the CoM in the "safe zone".

http://simhardware.org/img/CoM%20Sketch-2_cr%2025sep15.png
http://simhardware.org/img/CoM%20Sketch_cr%2025sep15.png

[GeeTwo]

We sketched a design where the motors are set forward and battery is at front. Even this does not put the CoM in the "safe zone".

Have you moved your arm fully forward and/or down? That could move your CoM a good bit.

Another thing that might help would be to make your wheelbase (distance between axle centers) a multiple of the churro spacing (4.8"?). This would keep you from rocking back and forth as you climb, though you would need a bit of extra torque as you come up out of a trough. In order to do this and remain under the size limit and not fall into the spaces, you may have to have more than one plane of wheels on each side.

[Greg Needel]

We've done some work on the "Big Wheel" concept design to look at the center of mass (CoM) issues:


We sketched a design where the motors are set forward and battery is at front. Even this does not put the CoM in the "safe zone".




So my team is playing with this also, and while the problems of weight distribution are important, we feel that you can get around it because there is no weight limit on FTC bots. While you want to keep the robot as light as possible since power is limited, it also is very realistic to add ballast exactly where you need it using things besides the battery and motors. With a few lbs of steel riding right on the front of your chassis you should be able to compensate to make this concept work.

[DavisDad]

Have you moved your arm fully forward and/or down? That could move your CoM a good...

Yes, extending arm forward, with 1lb weight, moves CoM to about centerline of safe zone. And... has better distribution when level.

[DavisDad]

...it also is very realistic to add ballast exactly where you need it using things besides the battery and motors. With a few lbs of steel riding right on the front of your chassis you should be able to compensate to make this concept work.

Yes, ballast will be used after the other mechanisms are chosen. We've found weight balance and precise alignment of the wheels make a big different in how the drive platform tracks.

For this design exercise, we're looking at using the arm as follows:

http://simhardware.org/img/CoM%20Sketch-4_cr%2025sep15.pnghttp://simhardware.org/img/CoM%20Sketch-3_cr%2025sep15.png

[GeeTwo]

Yes, extending arm forward, with 1lb weight, moves CoM to about centerline of safe zone. And... has better distribution when level.

For this design exercise, we're looking at using the arm as follows:

Cool - almost exactly what I had in mind when I suggested moving the arm forward and down. Glad to see it's working out.

[wgardner]

Will do… other motors are at school and won’t be able to test them until September. We also want to test the secondary gearbox performance we’re adding as part of this project.

Hi,

Any chance for these tests to be rerun with the Tetrix and Neverest motors now that school is open and the motors are presumably available? Thanks so much!

[DavisDad]

Hi,

Any chance for these tests to be rerun with the Tetrix and Neverest motors now that school is open and the motors are presumably available? Thanks so much!

I've been preoccupied with the new controls and changes in drive platform requirements. Hopefully I'll get to it this weekend.

[DavisDad]

We received the AndyMark wheels and v-belts. The inside-out v-belt fits snugly over the wheel. The cogs grab the churro nicely.

http://simhardware.org/img/BigWheel_cr%2002oct15.JPG

http://simhardware.org/img/BigWheel-2_cr%2002oct15.JPG

[GeeTwo]

Looks like a good fit, on both the wheel and the churro! Are you planning to use adhesive between the wheel and the belt?

[DavisDad]

... Are you planning to use adhesive between the wheel and the belt?

It's tight enough not to slip in rotation. I'm thinking a thin bead of heat glue would keep the belt from moving laterally. Rubber cement would work too.

[GeeTwo]

It's tight enough not to slip in rotation. I'm thinking a thin bead of heat glue would keep the belt from moving laterally. Rubber cement would work too.

Same two primary answers I was thinking of, with a slight advantage towards the rubber cement. CA is too likely to be brittle under game stresses. Hot glue doesn't really stick to anything, and might not grab the smooth tire tread well. Rubber cement is more flexible than either, and would provide more friction even if it doesn't serve as an actual adhesive on one side or the other. Contact cement is flexible, but would be a royal pain to get right. Silicone glues are also worthy of consideration, for the same reasons as rubber cement.

[DavisDad]

OK- time to start building the prototype. The plan is to build one half of the chassis; Chassis Rails, 2 wheels & 2 motors. We'll test on "Mountain" for ability to climb.

http://simhardware.org/img/Half%20Platform%20Prototype_cr%2003oct15.png

[DavisDad]

Here's a Bill of Materials (BOM) for the prototype:

Link to Excel spreadsheet with BOM and other analyses: Chassi Build_cr 03oct15.xls (http://simhardware.org/img/Chassi Build_cr 03oct15.xls)

http://simhardware.org/img/Chassis%20Build%20BOM_cr%2003oct15.png

[DavisDad]

We've made some modifications to the design:


We had used 2" for chassis clearance of balls and blocks. This is incorrect as the ball is 2.8" in diameter. We raised the motors to clear 3".
We made the Chassis Rail 4" tall and symmetrical about the wheel axle. This allows a standoff at top of Rail.


The BOM in the previous post has been updated.

http://simhardware.org/img/Half%20Platform%20Prototype_cr%2012oct15.png

[DavisDad]

The first fabrication activity will be to modify the 8" AndyMark wheels. They will be turned on the lathe to narrow to 1" and allow the hub to attach within the 1" width.

http://simhardware.org/img/Modified%20AM%20Wheel_cr%2012oct15.png

http://simhardware.org/img/Modified%20AM%20Wheel_cr%2012oct15-2.png

[DavisDad]

http://simhardware.org/img/8in%20Wheel%20on%20lateh_cr%2012oct15.JPG

http://simhardware.org/img/Half%20Chassis_cr%2012oct15.JPG

[DavisDad]

I found an interesting robot with similar design. The video may shed some light on how the bot will drive on tiles...

LINK to video (https://www.youtube.com/watch?v=jtjtp8Jbu38)

http://www.societyofrobots.com/images/robot_asme_drive_train.jpg

[RRLedford]

It's tight enough not to slip in rotation. I'm thinking a thin bead of heat glue would keep the belt from moving laterally. Rubber cement would work too.

Rubber cement is fast drying, but Shoe Goo urethane adhesive is way stronger in the key spec of its => peel strength.

We are evaluating a strange design that uses four overlapping pairs of half wheels that have their flat sides oriented 180º out of phase within the four pairs, and each pair is driven by one of four motors..

By correctly spacing the axles within the pair and by optimally separating the pairs on each side (front to back), we expect them to roll over the churros where we have plastic and them climb them on the high zone churros.

Our Plan B wheels are going to be 8" AndyMark, like yours, but with thick walled pieces of 5/8"-3/4" OD surgical or urethane rubber tube pieces tied around the circumference to function as as large and somewhat individually "floppy" cleats.

Notches in rim will keep the cleats' tied on with the capture cord at properly equal spaced locations around the circumference of the wheel. Shoe Goo adhesive may be needed to better stabilize cleats against the wheels' urethane if cleats flex too much. with just cord holding them on.

We considered your style of cogged belt too, but felt the cogs might be a little too shallow for maintaining good grip engagement with the churro bars.

Appreciate all the time spent documenting your design and build process here.

-Dick Ledford

[Gdeaver]

A good quality CA will bond belts and wheels in this application. Medium set will give a little more work time. Be fast if you use it.

[DavisDad]

Rubber cement is fast drying, but Shoe Goo urethane adhesive is way stronger in the key spec of its => peel strength.



Good idea using Shoo Goo- thanks!

I converted the above robot's SolidWorks model to OnShape here: ASME CMU Robot 2004 (https://cad.onshape.com/documents/ccf8f12f73d04b36bcc9afa8/w/fa5fa31446744377ac13a452/e/46e75487556d45f49e11db01)

The design has nice mechanisms for arm using servos.

[DavisDad]

We tested the chassis & wheels on the "Mountain" today; no motors yet:


It's not certain that the rig will climb as hoped. Turning the wheels by hand doesn't give enough info about slip, as the front and back wheels work together and we couldn't apply the torque on both in sync.


When a wheel is resting on 2 rungs, I'm concerned that the bot will get stuck; the notches could bind on the churros and not climb forward. Momentum will probably be a factor in this.


We did have a problem with the chassis hitting the churro as shown below. Something's off with my CAD model, the mountain CAD, or both.



http://simhardware.org/img/Chassis%20Test_cr%2015oct15.png

[DavisDad]

http://cuttingsarchive.org/images/thumb/5/56/1981-05-08_Punch.jpg/650px-1981-05-08_Punch.jpg

[DavisDad]

Almost done with the prototype...

http://simhardware.org/img/Prototype%20Build_cr%2019oct15.JPG

[DavisDad]

Prototype is ready to test, but having problems with App Inventor. Old programs won't run with newly installed Driver Station App. Where's IT when you need them? :)

http://simhardware.org/img/Prototype%20Build_cr%2021oct15.JPG

[DavisDad]

I got the App Inventor program working by installing the latest Driver Station app and reinstalling "LocalAppInventor_win.ova" to the newest version. I've got to say, the programming platform has worked well for me; given my limited programming ability. I'm having fewer configuration issues compared to RobotC.

The prototype ran nicely on the floor. I like the belt drive for efficiency and smoothness. We tested on a whiteboard and it had no problem driving up 30 deg. It started slipping at about 40 deg. We'll test on the mountain at today's meeting.

http://simhardware.org/img/Prototype%20App%20Inv-02_cr%20%2022oct15.JPGhttp://simhardware.org/img/Prototype%20App%20Inv-01_cr%20%2022oct15.JPG

[DavisDad]

We ran two test for the prototype yesterday:


Climb Test
Wheel/Tile Damage Test


Both were unsuccessful. :(

I wasn't able to attend the meeting and can only view the videos my son made. There are a couple of additional things I'd like to test and will set up a home test rig for the churro climb. Here are links to the videos:

FTC 2016 Prototype Climb Test (https://youtu.be/ys1BMau-d8w)
FTC 2016 Prototype Wheel Test (https://youtu.be/-63vg4V7UfM)

The damage inflicted was worse than the picture obelow shows. The wheel abraded the surface about 1/16th inch depth. This seems to be a "show stopper" for the cogged belt idea.

http://simhardware.org/img/Prototype%20Tile%20Test_dr%2022oct15.jpg

[DavisDad]

Thinking about the wheel design and passing the tile damage test. I posted the following to the build Q&A forum:

The 10-08-2015 Q&A post (#39) in the "Robot Inspection and Build Rules" thread defines how tires can be tested for passing inspection. We have tested a cogged drive belt idea and the prototype design failed the test requirement: "run the wheels at full power for 15 seconds". The wheels spun and abraded the surface of the tile. See video of test: https://youtu.be/-63vg4V7UfM

Question: May we limit the power of the wheels in programming so that static friction force is not exceeded by the torque from the motor and the wheels do not spin? Is "full power" 100% of motor controller available power, or 100% of game controller command to robot.

I'm concerned that it's going to be difficult to design a wheel or tread that can both climb the mountain, and not damage the floor tiles.

[Gdeaver]

Yes, The mountain is a beast of a problem. We have invested allot of time and money into a Irobot style tank tread robot with wheels. Early prototypes show it should work. If it doesn't what do we do?

[DavisDad]

Yes, The mountain is a beast of a problem. We have invested allot of time and money into a Irobot style tank tread robot with wheels. Early prototypes show it should work. If it doesn't what do we do?

We can always do this: YouTube Scrimmage (https://www.youtube.com/watch?v=5gv1Bv3sujY)

[wgardner]

Yes, The mountain is a beast of a problem. We have invested allot of time and money into a Irobot style tank tread robot with wheels. Early prototypes show it should work. If it doesn't what do we do?

You don't have to go over any churros to score in the goals or even to "climb": you just need to be on the low part of the mountain with your drive train above the tape on the bottom 2 inches.

Everybody seems to be obsessed with driving over the churros, but you can do pretty much everything without driving over any of them...

[DavisDad]

...Everybody seems to be obsessed with driving over the churros, but you can do pretty much everything without driving over any of them...

I totally agree, if you analyze the scoring potential, being able to climb the churros is worth a max of 80 (not including chin-up). Blocks in the bins are worth a lot; 300 point by my calculation (10 pieces in 1 low, 1 med, 1 high).

[DavisDad]

We built a test rig to simulate the 30 deg ramp and curros. We thought that the cogs didn't have enough bite on the churros' ridges. We ran the prototype on the test rig and got a repeat of Thursday's failure. We ground off every other cog of the drive belt (inside out on wheel) and got a bit better performance. See link to YouTube video):

https://youtu.be/glkYs-dqP5I

We only had a long enough churro to make 4 stubs. We'll move the lower stubs up and test for the 50 deg High Zone.

http://simhardware.org/img/Prototype%20Wheel%20Mod_cr%2024oct15.jpg

[DavisDad]

We moved the lower churro stubs up to the 50 deg part. See video below. It gets stuck most of the time with the back wheel locked in and doing a wheelie. A few pounds force on the front enabled it to climb past (not shown).

Prototype Climb Test 2.5 (https://youtu.be/t4ECV3sNNdI)

I think the performance warrants going the next step to make the other side rail and test full functionality. This will ensure our holding the cross bar hasn't introduced something to the test that doesn't represent what a 4 wheel platform does.

If we get a positive ruling on using code or clutch to limit torque while on the floor, we'll proceed with the design.

[wgardner]

I totally agree, if you analyze the scoring potential, being able to climb the churros is worth a max of 80 (not including chin-up). Blocks in the bins are worth a lot; 300 point by my calculation (10 pieces in 1 low, 1 med, 1 high).

It's possible to do the chinup without driving over churros. About the only thing you sacrifice by not driving over the churros is possibly 40 points in autonomous for getting to the high zone, but you get 10 for getting in the low zone and you get more points anyway by going for the beacon, putting the climbers in the shelter, maybe scoring debris during autonomous (which counts at the end of the driver period, but if you score some in autonomous then you can keep piling it on during driver control), etc.

For teams that can climb the mountain, awesome and kudos! But for teams that can't, there are other ways to score as many points (or more) with different types of scoring mechanism designs. Don't give up!

[DavisDad]

...But for teams that can't [climb mountain], there are other ways to score as many points (or more) with different types of scoring mechanism designs. Don't give up!

Amen brother! Often the simpler, less glamorous strategies win the day.

Ok... time to check our progress against the "User Requirements Specification" (http://simhardware.org/img/FTC%202016%20Drive%20Platform%20URS-Rev1_cr%2016sep15.pdf) written after the game was revealed.

5.1 All materials. Components and controls must be legal per “2015-2016 FIRST® Tech Challenge Game Manual Part I” and “2015-2016 FIRST® Tech Challenge Game Manual Part II”The prototype failed the first wheel test of "against wall for 15 seconds at full power". Plans are to limit torque to the wheels while on level ground to prevent slipping and abrading the tiles. A question has been posted on the Q&A forum regarding this strategy.

5.2 The control system will be based on the new Modern Robotics Inc. control modules. The legacy module will not be used.Requirement meet

5.3 The platform must be no larger than, or collapsible to 18 inches square.Requirement meet

5.4 The motors will be one of the allowed 12VDC gear-motors.Requirement meet

5.5 The platform, when loaded to a total weight of 35 lb, will be able to climb a 50 degree incline with ladder rung spacing per game manual and field design.The prototype (1/2 bot) will be loaded and tested at approximately 18 lb

5.6 The platform should have a loaded (35 lb) full speed of 2 ft/sec on the level field.Requirement meet so far by estimate of speed from motor testing and drive train calculation:
*Motor RPM @ 20% of max power = 175 RPM (see test data (http://simhardware.org/img/Matrix%2012V%20GearMotor%20test_cr%2026jul15.JPG))
*Wheel diameter = 8.75"
*Wheel to motor ratio = 0.5 rot/rot

Calculated speed = 0.5 rot/rot x Pi x 8.75 in/rot ft/12 in x 175 rot/min x min/60 sec = 3.34 ft/sec

5.7 The platform should have a pushing force of 20 lb.
To be tested if prototype completed

5.8 The platform should be able perform with the field littered with “debris” game elements and still meet all user requirements.
To be tested if prototype completed

5.9 The platform must be capable of supporting navigation systems for the
autonomous period with driving through the “debris”.
To be tested if prototype completed

[wgardner]

I'm concerned that it's going to be difficult to design a wheel or tread that can both climb the mountain, and not damage the floor tiles.

FYI, I've asked a few questions on the official Q&A forum that have gone unanswered for weeks. Maybe they'll answer you and maybe they won't.

My opinion only: there's nothing in the rules to prevent you from doing the things you described (as long as they're not COTS with 2+ DOF, etc). If you don't hear back, I'd suggest that you go forward with your plans. After all, you're following the rules in an attempt to prevent field damage.

Limiting the power so the motor stalls is a little dangerous as it can heat up the motor/ smoke the motor/ prematurely drain the battery/ etc. Finding that power setting may also be tricky as it will depend on robot weight, battery charge level, etc.

Adding a clutch is a good idea if you can pull it off without limiting your power when you need it.

Another option is a software mechanism that detects wheel slippage and kills the power when it is detected until the gamepad controls are released and re-engaged. I think there are threads on this on CD on the FRC side. Then during inspection, your robot drives, detects wheel slippage and then stops the motors so there's no way for it to grind into the field for 15 seconds. This can be demonstrated to the inspector.

Also keep in mind that field damage is going to be dependent on robot weight. I fear many teams may build tread-based robots, test the light drive-train-only chassis and find it to be non-damaging, then add another 20 pounds of scoring mechanisms, and then find at the tournament that their new, heavier robot damages the field.

Good luck!

[DavisDad]

FYI, I've asked a few questions on the official Q&A forum that have gone unanswered for weeks. Maybe they'll answer you and maybe they won't.

My opinion only: there's nothing in the rules to prevent you from doing the things you described (as long as they're not COTS with 2+ DOF, etc). If you don't hear back, I'd suggest that you go forward with your plans. After all, you're following the rules in an attempt to prevent field damage.

Hi wgardner - thanks for the thoughtful feedback; much appreciated! This "design exercise" has been a project my son (FTC alum) and I have been working on for over 2 years. It's not my FTC team's design, so won't be going into competition. My team is leaning toward a tank tread design.

If this project is successful, anyone could use the info to inform their designs. If not, I hope they can learn something from our dead ends. We're posting the work here as an example of applying engineering principles to the design/build process.

Limiting the power so the motor stalls is a little dangerous as it can heat up the motor/ smoke the motor/ prematurely drain the battery/ etc. Finding that power setting may also be tricky as it will depend on robot weight, battery charge level, etc.

Roger that- I've tested the Matrix 12V gearmotor direct from battery, stalled for about 3 seconds. But... 15 seconds is scary.

Adding a clutch is a good idea if you can pull it off without limiting your power when you need it.

... and complicated. :(

Another option is a software mechanism that detects wheel slippage and kills the power when it is detected until the gamepad controls are released and re-engaged. I think there are threads on this on CD on the FRC side. Then during inspection, your robot drives, detects wheel slippage and then stops the motors so there's no way for it to grind into the field for 15 seconds. This can be demonstrated to the inspector.
Great idea about kill and reset from the game pad! If we get that far, we'll try that. I'll look for the posts in the FRC threads.

Also keep in mind that field damage is going to be dependent on robot weight. I fear many teams may build tread-based robots, test the light drive-train-only chassis and find it to be non-damaging, then add another 20 pounds of scoring mechanisms, and then find at the tournament that their new, heavier robot damages the field.
We're working on weight testing today. We've added weight to simulate a 35 lb bot (~18 lb for the 1/2 bot) and tested on the test ramp. We're seeing the motors loose power when they get near stall speed; <~ 10 rpm @ motor pulley. We're not getting enough power to climb 50 deg with the added weight. That was with encoder control of speed. We're making another Op Mode to run straight power control while we charge the battery to full.

I've calculated we should get about 350 in-ounces (21 in-lb) torque from the motor; so should be seeing about 9 lb tangential force at each wheel. The dynamics are complicated and 9 lbs probably won't be enough. We can always increase the driven pulley diameter. and design for a super-light build.

Good luck!
Thanks!- we're going to need some luck. :)

[DavisDad]

We added about 7 lbs to prototype and tested (with a fully charged battery) and the prototype had enough power to climb. See link to video below; sorry for wrong orientation.
https://www.youtube.com/watch?v=Kt9V27x_JaA
Butt.. now the modified cogs fold down and loose grip. We're working on a better profile for grinding the cogs that will be stronger in bending:

http://simhardware.org/img/Prototype%20Wheel%20Mod%20CAD_cr%2025oct15.jpghttp ://simhardware.org/img/Prototype%20Wheel%20Mod%20CAD-2_cr%2025oct15.jpg

http://simhardware.org/img/Prototype%20Wheel%20Mod%20CAD-3_cr%2025oct15.jpg

[DavisDad]

Hello,

The 10-08-2015 Q&A post (#39) in the "Robot Inspection and Build Rules" thread defines how tires can be tested for passing inspection. We have tested a cogged drive belt idea and the prototype design failed the test requirement: "run the wheels at full power for 15 seconds". The wheels spun and abraded the surface of the tile. See video of test: https://youtu.be/-63vg4V7UfM

Question: May we limit the power of the wheels in programming so that static friction force is not exceeded by the torque from the motor and the wheels do not spin?Is "full power" 100% of motor controller available power, or 100% of game controller command to robot.

a: If there is any possibility that the motor will run at 100% power during either autonomous or tele-operated mode, then the tread must be tested at 100% power. It is a violation of Gracious Professionalism for a team to run the motors at one power during inspection and at a higher power level during a match. Teams that are caught doing this will be disqualified from the event.

I guess they think we work for VW ;)

[DavisDad]

I've been thinking about the Q&A response about limiting the wheel spin and how we might design/code the bot to ensure that the field is not damaged. In my engineering job, there's a formal method of evaluating how systems can fail: "Failure Modes and Effects Analysis (FMEA)" (https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis). I'm thinking we analyze, test and documented our work with this engineering tool. A team could present the work to the inspectors.

Here's the next prototype wheel profile we plan to test for gripping the churros:
http://simhardware.org/img/Prototype%20Wheel%20Mod%20CAD-6_cr%2027oct15.jpg
http://simhardware.org/img/Prototype%20Wheel%20Mod%20CAD-5_cr%2027oct15.jpghttp://simhardware.org/img/Prototype%20Wheel%20Mod%20CAD-4_cr%2027oct15.jpg

[DavisDad]

We got the prototype to climb the 50 deg section: Test-5 YouTube Video
(https://youtu.be/dwbDkl0pFik)
We did the following to modify cogged belt for optimize profile to engage with churros:


Made a grinding wheel with optimized profile. This was interesting as we stacked 4 1/16" grinding wheels and shaped the negative profile with diamond grinding blade.
Made a jig to hold grinder and wheel on mill. This allowed us to index the wheel on every other cog and raise/lower the grinder with pretty accurate x-axis location and good control of the z-axis (up/down) grinding travel.
Ground each profile. Removed every-other cog and small vertical cut on adjacent cogs.
Cleaned each cogged belt to remove gummy residue. Grinding makes a gummy, tarry residue (burned rubber) which needs to be removed from belt. We used mineral spirits and then TSP to remove the mineral spirits.


http://simhardware.org/img/FTC%202016%20Wheel%20Profile_cr%2001nov15.JPG
http://simhardware.org/img/FTC%202016%20Grinding%20Wheel%20Profile-3_cr%2001nov15.JPG
http://simhardware.org/img/FTC%202016%20Grinding%20Wheel%20Profile-1_cr%2001nov15.JPGhttp://simhardware.org/img/FTC%202016%20Grinding%20Wheel%20Profile_cr%2001nov 15.JPG
http://simhardware.org/img/FTC%202016%20Grinding%20Wheel%20Profile-2_cr%2001nov15.JPG

[DavisDad]

Review of prototype performance to date:


Successful climb of the 30 and 50 deg zones requires very precise design of wheels
Center of gravity (COG) will need to be controlled. At 50 deg zone, the COG needs to be at the front axle to have equal force on front and back wheels.
The wheels need to be controlled to a slow rotation to keep the wheels' contact with the churros in static friction; too fast causes slip (dynamic friction) and chatter (bounces on the cogs). We had issues with the motor controllers maintaining full power at the slow speeds and high torque; when the battery wasn't fully charged, the back motor would loose torque.
This prototype only models half the drive platform and does not account for potential problems with left/right wheels being out of alignment.
The cogged belt failed the sSoftTile damage test. It is possible to use current design if we could prove to the inspector we have controls to prevent wheel slippage on level ground. But... this would be difficult to do in software and we couldn't be sure the inspectors would pass the design.


I'm thinking this design is too risky to pursue for FTC 2016. We're going to continue developing the platform as part of this "design exercise", but do not recommend this design for competition build.

Next steps:


Increase gear ratio from 2:1 to 3:1 by using a larger wheel pulley.
Build other half of the drive platform to see how the whole design performs.
With whole platform, test different controls set-ups for tele-op driving and autonomous climbs.

[wgardner]

I'm looking forward to seeing how it works with both sides built! Thanks for continuing to share!

[DavisDad]

Modern Robotics is selling a new version of the Matrix 12V motor: 12v 6mm Motor Kit (http://modernroboticsinc.com/12v-6mm-motor-kit-2)

This fixes the only thing I don't like about the Matrix motor; 4mm shaft requires pretty high precision machining of couplings and we've had issues with the set-screws loosening. 6mm (just under 1/4") shaft has more meat and is now compatible w/ Tetrix and AM gear. Now adapting to 1/8"square shafts will be a lot easier: drill a rod half way 6mm and other half with No. 30 drill size, then broach through No. 30 hole.

I prefer the Matrix planetary gears to the others' spur gear designs.

http://modernroboticsinc.com/content/images/thumbs/0000253_12v-6mm-motor-kit_125.png

[DavisDad]

We've completed the first whole prototype chassis build. We increased the pulley" gear ratios from 2:2 to 3:1. Now ready to mount electronics.

http://simhardware.org/img/WholePrototype_cr%2015nov15JPG.jpg

[Greg Needel]

Modern Robotics is selling a new version of the Matrix 12V motor: 12v 6mm Motor Kit (http://modernroboticsinc.com/12v-6mm-motor-kit-2)


http://modernroboticsinc.com/content/images/thumbs/0000253_12v-6mm-motor-kit_125.png

Is this a legal motor for use in FTC? It does not seem to be listed in the game manual on the approved motor list.

[DavisDad]

Probably not legal. Maybe next year...

[DavisDad]

19 lbs

http://simhardware.org/img/WholePrototypeWired_cr%2015nov15JPG.jpg

[DavisDad]

We won't be able to test on mountain for a while; don't want to distract the team with this "design exercise". Here's a video running it around the house. Need to glue the fan belts on AM wheels; they work their way off when pivoting.

It has better turning than I expected; not much chatter.

https://youtu.be/h68eNyzMy44

[RRLedford]

We won't be able to test on mountain for a while; don't want to distract the team with this "design exercise". Here's a video running it around the house. Need to glue the fan belts on AM wheels; they work their way off when pivoting.

It has better turning than I expected; not much chatter.

https://youtu.be/h68eNyzMy44


I highly recommend that you use black Shoe Goo urethane adhesive to glue the treads to the wheels. It has extremely high peel strength, and bonds exceptional well to most materials. We use it in FRC for the attachment of tread to hubs and have now ceased using any rivets at all, since it bonds so aggressively and durably. Multiple years and no failures

Beware though that it is solvent based and needs at a lot of time to dry and cure. I suggest at least 48 hours, or even more if the path for solvent to escape from is long.

[DavisDad]

I highly recommend that you use black Shoe Goo urethane adhesive ...

Thanks RRLedford- I've ordered some. I haven't used it, but it sounds like just the right stuff. Thanks for the advice!

[DavisDad]

The next step is to develop a controls design strategy. Since were're only designing the drive platform, with little consideration of other game functions, we're looking at these requirements:


We must address the wheel's damage to the SoftTiles as required by FTC test: "run the wheels at full power for 15 seconds". We'll need to have controls that prevent the wheels from spinning on the tiles.
In order to score the maximum autonomous climbing points, we'll need to navigate accurately to the high zone.
We'll need to be able to drive through debris (balls & blocks) in autonomous while maintaining our course to the high zone.


For effective navigation, we've purchased a sensor that I've been interested in for a while: navX-MXP Robotics Navigation Sensor (http://ftcforum.usfirst.org/showthread.php?4974-new-FTC-compatible-navX-Micro-IMU-AHRS-Sensor-Announced&highlight=navx). This board uses the Invensense MPU-9250 (http://www.invensense.com/products/motion-tracking/9-axis/). I got interested in this when I saw David Sachs' video: Sensor Fusion on Android Devices: A Revolution in Motion Processing (https://www.youtube.com/watch?v=C7JQ7Rpwn2k). I'm hoping that with the FTC specific Android software support by Kauai Labs (http://pdocs.kauailabs.com/navx-micro/) and my son finds the time to help me with JAVA, we can achieve the navigation requirements. The sensor may also be useful for anti-slip control.

I've done the simple programming so far using App Inventor (AI), but will need to use Android Studio with the navX-Micro.

NOTE: I don't think that driving into the high zone is the best approach for the Res-Q game; the most successful teams I've seen (YouTube) are reaching from the low or mid zones and avoiding the difficulties of the high zone. But... my son and I want to bring this prototype design as far as possible to achieve the original design intent.

[Gdeaver]

We used the NavXMXP For many things on our 2015 FRC robot. This was done before the software and firm ware upgrade. Have been very satisfied with it. It may be a little simpler with the Adafruit Bosch IMU board which also has proven to be good. I think for 2016 we will stay with the naxmxp.

[DavisDad]

We used the NavXMXP For many things on our 2015 FRC robot. This was done before the software and firm ware upgrade. Have been very satisfied with it. It may be a little simpler with the Adafruit Bosch IMU board which also has proven to be good. I think for 2016 we will stay with the naxmxp.

Thanks Gdeaver- do you have any advice for me, a complete novice in Android Studio, where to start with:


Installation and use of FTC SDK with navX "Software libraries"
Any special considerations for programming in Android Studio vs. use of the navX
Good tutorials or discussions re IMU use for FTC or FRC


I got Android Studio working with FTC SDK early in the season. I got the ZTEs driving a single motor with the game controller; so I think I have the programming environment set up correctly. I was just blindly following Tom Eng's tutorial. I'm not sure my son (the programmer in the family) will have a lot of time for this. I need to "beg, borrow or steal" enough programming to test navigation and anti-slip functionality.

Any help much appreciated!

[DavisDad]

We translated the App Inventor teleOp program into an Android Studio (AS) version. My son helped me a bit, although I had to hear what an idiot I am with programming. :)

I followed the tutorials by Swerve Robotics (https://www.youtube.com/channel/UCHZQb2RKh2hu89M9L2rUxhw/videos) for updating the AS SDK files and programming an Op mode. The prototype is now running as before with AS code.

Thanks Swerve Robotics!!

Now to work on a "dead reckoning" autonomous version, with run-to-position encoder control, and see how repeatable "dumb" navigation is.

[OllieK]

Craig,

I am in process of creating a tutorial/blog to compare a built-in fusion, such as in Adafruit bno055, with a lower cost simple gyro where the integration/fusion is done in OpMode library.

You can find an example how to create your own I2C device drivers in this blog (http://olliesworkshops.blogspot.com/2015/11/bno055-imu-sensor-with-ftc-wire-library.html). This example is for the bno055 IMU..

The source code can be found in Github (https://github.com/OliviliK/FTC_Library).

Cheers, Ollie

PS. I have been a long term fan of your mechanical designs and CAD files.

[DavisDad]

Hi Ollie,

Thank you for the links, and kind words. I'll look forward to reading your comparison. It'll be interesting to know how much the fancy "sensor fusion" devices help with FTC navigation.

Best,

Craig

[slibert]

do you have any advice for me, a complete novice in Android Studio, where to start with:

Installation and use of FTC SDK with navX "Software libraries"
Any special considerations for programming in Android Studio vs. use of the navX
Good tutorials or discussions re IMU use for FTC or FRC



Start with these instructions (http://pdocs.kauailabs.com/navx-micro/software/libraries/android/) for installing the NavX-Micro FTC libraries into Android Studio. Then review the sample code like rotate to angle. (http://pdocs.kauailabs.com/navx-micro/examples/rotate-to-angle/) After you install the latest build, all the samples are installed to subdirectories underneath <home_directory>\navx-micro\java\examples (e.g., C:\Users\Robot\navx-micro\java\examples).

There are many helpful items to help your team use and learn more about on the website, start with the links above, and you can ask questions at the support forum.

[DavisDad]

Hi Scott,

Thank you for the instructions. Using the "Getting Started" guide, I have successfully installed the libraries and configured the "rotate to angle" opMode to compile without error. I'm really looking forward to getting the robot navigating with the navX over Thanksgiving weekend.

Thanks again,

Craig

[slibert]

I need to "beg, borrow or steal" enough programming to test navigation and anti-slip functionality.

Any help much appreciated!
Regarding anti-slip, I'd recommend you look into using encoders on each motor shaft and having the motor controller maintain whatever speed (in revolutions per minute) it is commanded to based on input from the encoders. Not only will that provide predictable behavior even as the battery charge level changes, but it's also the general principle behind traction control in cars. We use this technique very effectively on FRC robots, it should work ok for FTC robots too.

[DavisDad]

Regarding anti-slip, I'd recommend you look into using encoders on each motor shaft and having the motor controller maintain whatever speed (in revolutions per minute) it is commanded to based on input from the encoders. Not only will that provide predictable behavior even as the battery charge level changes, but it's also the general principle behind traction control in cars. We use this technique very effectively on FRC robots, it should work ok for FTC robots too.

Yes- that's how we're controlling and it's so much better than power control! But... the wheels will still slip at the set speed (RPM). I'm thinking we'll need to determine slip by sensing motion with IMU and stop the wheels from rotating (and/or slow way down) if the bot stops moving when wheels are commanded to rotate.

[DavisDad]

Start with these instructions (http://pdocs.kauailabs.com/navx-micro/software/libraries/android/) for installing the NavX-Micro FTC libraries into Android Studio. Then review the sample code like rotate to angle. (http://pdocs.kauailabs.com/navx-micro/examples/rotate-to-angle/)...

We got the "rotate to angel" example working this morning. The first time we started the opMode, it work great; would very repeatably rotate to the same angle and return when pushed by hand. I mounted the IMU more solidly and now it's erratic. I need to understand better how the unit works vs. the code, calibration and magnetic interference from the motors.

[slibert]

We got the "rotate to angel" example working this morning. The first time we started the opMode, it work great; would very repeatably rotate to the same angle and return when pushed by hand. I mounted the IMU more solidly and now it's erratic. I need to understand better how the unit works vs. the code, calibration and magnetic interference from the motors.
My intuition is that the mounting may not be the issue, most likely the "P" coefficient needs to be tuned a bit. A lower battery voltage than last time, or a change in robot weight could account for the change in performance. Do make sure the sensor has completed calibration before using it. For rotate to angle which uses the yaw angle, the magnetometer is not involved, so magnetic interference shouldn't be an issue.

[ArtemusMaximus]

I wish we'd have opportunity to play with that 9-DOF sensor. Sound like a way to go for Autonomous mode. May be next year.
It would be nice to have color and gyro sensor in KOP.

[DavisDad]

My intuition is that the mounting may not be the issue, most likely the "P" coefficient needs to be tuned a bit. A lower battery voltage than last time, or a change in robot weight could account for the change in performance. Do make sure the sensor has completed calibration before using it. For rotate to angle which uses the yaw angle, the magnetometer is not involved, so magnetic interference shouldn't be an issue.

Thanks slibert- I think I wasn't waiting for the calibration to complete. I've been trying various PI gains and max speed combinations. I looks like "I" gain, set at 0.0001, winds up and overshoots quite a bit.

I ended up increasing "P" = 0.01, setting the min/max speed at +/- 0.5 and the "Tolerance Deg" = 1. This performed nicely.

Next is run_to_position coding for straight travel segments.

[DavisDad]

No progress on this as we had to cannibalize the motors from the Big Wheel bot for our team bot. MRI has been out of the Matrix motors for a while...