OCCRA
Go to Post WHAT!?!?!? YOU DON'T DEVOTE YOUR LIFE TO APPLE!?!?!?!? ;) :p - Joe Matt [more]
Home
Go Back   Chief Delphi > Technical > Programming > Java
CD-Media  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 11-20-2018, 04:57 AM
M3ri M3ri is offline
Registered User
FRC #5554
 
Join Date: Oct 2018
Location: Israel
Posts: 3
M3ri is an unknown quantity at this point
Smile Programming Mechanisms Right

Hey, so in preparations for the upcoming season our team is trying to take our code a few steps forward.
We successfully genaretad and followed paths and motion profiles using Jaci's pathfinder and used Vannaka's motion profile generator to generate the csv files and as a visual aid.

I am now trying to improve the way we code mechanisms, and I have a few questions.
First of all, I noticed during my years in frc that there are 2 types of mechanisms.
Mechanisms like an elavator or an arm that can't go further than a certain range of motion, I'll call them in this post limited mechanisms.
On the other hand there are mechanisms like shooters and feeder that can go on and on and don't have a movement limit, I'll call them in this post free mechanisms (I'm sorry if I'm not familiar with the technical terms).

So, these are my questions:
1. Which sensors are recommend to use on which type of mechanism?
2. During autonomous, what is the best way to move mechanisms? I'm guessing the options for the limited ones are using position PID loop or maybe generating a profile.
For the free ones, I'm guessing a velocity PID loop. Are there better ways or am I on the right track?
3. Same for teleop, what is the best way to move mechanisms? For the free ones is there a better way to run them other than SpeedController.set(pwmvalue)? For the limited ones, what type of control loop should I run on the limited mechanisms during teleop and does it take into account the range of motion?

Thanks for taking time to try and help me.
Reply With Quote
  #2   Spotlight this post!  
Unread 11-20-2018, 07:59 AM
gerthworm's Avatar
gerthworm gerthworm is offline
Making the 1's and 0's
FRC #1736 (Robot Casserole)
Team Role: Mentor
 
Join Date: Jan 2015
Rookie Year: 2015
Location: Peoria, IL
Posts: 740
gerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond repute
Re: Programming Mechanisms Right

My answers apply to both categories you mention:

0) Remember simpler is better. If your mechanism works well without sensors or closed-loop control, adding it will not necessarily help you. As a rule, our team does closed loop only when absolutely necessary.

Once you've determined you need some sort of closed loop control:

1) Encoders to measure rotation (or rotational velocity) through a continuous range, potentiometers to measure rotation through a fixed range. Limit switches to measure contact at specific points, ultrasonic or lidar distance sensors to measure linear displacement. Check the spec sheet on all of these prior to purchase to be sure they match your requirements. If at all possible, connect them such that they measure the endpoint manipulator (the thing you actually care about the position/velocity of), not some intermediate variable. The analogy here is for your drivetrain - encoders should go on the output shaft, not the input.

2 & 3) Structure your software such that the control logic for the mechanism accepts a "desired state" as input - could be the position, velocity, etc. In teleop, derive this desired state command from operator inputs. In Autonomous, derive this from some code that's controlling the sequence of your autonomous routine overall.

There are other types of controllers than PID too - "Bang Bang" is another common controller seen in FRC. Take-back-half is another one that's made the rounds here. Again, keep in mind, to maximize success, simpler is usually better.

Last edited by gerthworm : 11-20-2018 at 08:04 AM.
Reply With Quote
  #3   Spotlight this post!  
Unread 11-20-2018, 11:31 AM
GeeTwo GeeTwo is offline
Somebody Else
AKA: Gus Michel II
no team
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 6,038
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: Programming Mechanisms Right

^^^ This - measure what you need to measure, preferably through the fewest number of proxy stages.

Another sensor type to keep in mind is the absolute encoder. This is used for continuous rotating sensors where you need to know not only the speed or total amount of motion, but directly need to know the angle of your rotating item; examples include swerve module rotations and full-cycle four-bar linkages.

On rangefinders, if you're on a tight budget, IR is usually a better choice at short ranges (less than about a foot) and ultrasonic at longer ranges.

As you move your sensors farther out to the edge, they become harder to protect. The more critical the measurement is to your activities, and the more expensive the part is, the greater a concern this is.

Always try to determine up front how well and how quickly you need sensor information - often this will result in a significant change in your sensor selection.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.
[Quoting brennonbrimhall]: We design a new robot every year, but we can't forget that we also design a new team every year as folks come and go.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:09 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi