Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Technical Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=22)
-   -   Which sensors should be used throughout the robot? (http://www.chiefdelphi.com/forums/showthread.php?t=137836)

tickspe15 21-08-2015 21:03

Re: Which sensors should be used throughout the robot?
 
Quote:

Originally Posted by marshall (Post 1494100)
They have also since said that they have implemented more secure techniques to deal with the backlash.

yes but it still won them a couple championships

asid61 21-08-2015 21:11

Re: Which sensors should be used throughout the robot?
 
Quote:

Originally Posted by tickspe15 (Post 1494102)
yes but it still won them a couple championships

It probably worked for them for a number of reasons. 254 runs very well-built and smooth robots; correct me if I'm wrong, but I bet the runout on those shafts and the encoder bore itself was extremely low, for one. The average team might not have all the construction techniques that go into making a floating encoder setup work.

RyanCahoon 22-08-2015 03:46

Re: Which sensors should be used throughout the robot?
 
Quote:

Originally Posted by garyk (Post 1494097)
Oh, geez, let's not do this - anchoring the housing/body of the encoder via securing its wires (and I've seen it). If you're using an encoder with 360 counts/rev for example, a wobble of one degree is one count. Although we're not going to use them ($$$) encoders are available with > 10K counts/rev. and imagine the error if it's poorly mounted. What you are learning (and I'm supposed to be teaching) should be applicable to an engineering job.

Engineering is about creating a solution to solve some specified problem. If there's 15* of backlash to the encoder, than on my 4in wheel, that's 0.5in of linear error in position - the resolution of the encoder doesn't really matter. If you're driving an elaborate trajectory (e.g. some of the advanced game piece acquisition routines in 2011, 2013, and 2014), then the error will stack up, but if the average team is just driving forward 10ft to be in range of the high goal, it's probably sufficient, considering even the best drivers will have an order of magnitude larger positioning error in teleop.

When instrumenting arms, elevators, wheel pod steering, etc, the problem specifications are different.

I think it's well established that many of the techniques that are used in FIRST to create machines that run for a few tens or maybe hundreds of hours (and for only 15 seconds "unsupervised" at a time) aren't on parity with the techniques used in industry where machines have to run for tens of thousands of hours or more.

Nate Laverdure 22-08-2015 10:12

Re: Which sensors should be used throughout the robot?
 
Quote:

Originally Posted by RyanCahoon (Post 1494112)
I think it's well established that many of the techniques that are used in FIRST to create machines that run for a few tens or maybe hundreds of hours (and for only 15 seconds "unsupervised" at a time) aren't on parity with the techniques used in industry where machines have to run for tens of thousands of hours or more.

Exactly. It's OK to have FRC 'good' design practices diverge from professional 'good' design practices. This is not the same thing as cutting corners-- it reflects the fundamental differences in the design environment. There's several examples of this in the 973 RAMP videos.

MichaelBick 23-08-2015 20:53

Re: Which sensors should be used throughout the robot?
 
Quote:

Originally Posted by garyk (Post 1494097)
Oh, geez, let's not do this - anchoring the housing/body of the encoder via securing its wires (and I've seen it). If you're using an encoder with 360 counts/rev for example, a wobble of one degree is one count. Although we're not going to use them ($$$) encoders are available with > 10K counts/rev. and imagine the error if it's poorly mounted. What you are learning (and I'm supposed to be teaching) should be applicable to an engineering job. Please mount encoders such that the threads on its body go through an appropriately-sized hole, and secure it with the lock washer and nut that come with the encoder. Have this in your CAD!

It's a good idea to mark the position of the encoder on its mount by drawing a line (sharpie, etc.) from the body of the encoder onto its bracket/panel, same thing for a pot. That way, if it comes loose (as did ours at Champs in 2010) you can put it back in about the right place, until you have time between matches to accurately remount it.

It's all about understanding the situation. One needs to understand the system accuracy requirements, and then develop a solution that meets the requirement. For example, 10* of error on our 1.5" elevator pulley amounts to slightly over an 1/8" of error. This was plenty tolerable for us. 10* of error would not be acceptable however, for example, on a 5' long arm.

Even better than drawing a line is using a zeroing sensor. Hall effects are great for this, and you won't have to worry during sensor replacements.


All times are GMT -5. The time now is 05:59.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi