Go to Post 90% of innovation is inspiration. - martin417 [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 12-02-2016, 19:33
MisterG's Avatar
MisterG MisterG is offline
Think twice post once.
AKA: Alan Gilgenbach
FRC #2062 (C.O.R.E. - Community of Robotics Engineers)
Team Role: Team Spirit / Cheering
 
Join Date: Mar 2011
Rookie Year: 2011
Location: Waukesha, WI
Posts: 120
MisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to all
Two Motors on the same mechanism: risks and mitigations

Dig if you will the picture.

Ball pickup assembly with two arms parallel to the sides of the chassis one on each side. At the outermost point of the arms there is a roller assembly. Each arm is mounted to a motor/gearbox that is used to raise/lower the pickup mechanism. It rotates one direction to go up over frame perimeter and the other direction to go down to pickup.

The concern is that it will be difficult to synchronize control of the two motors and that there will be 'racking' problems resulting in the two sides raising and lowering unevenly and/or fighting with each other.

Would you a) build with no concerns over this particular risk, b) proceed with caution or c) abandon hope and find another configuration?

What control schemes would you suggest for best results?

The proposed plan is to use a master / slave configuration. This would feature an encoder (pot) on one arm which will close a PID on that motor. The command to the other motor is a mirror of the first (same magnitude adjusted for rotation).

Thoughts? Suggestions? Lessons Learned?
__________________
Alan Gilgenbach
C.O.R.E 2062
  #2   Spotlight this post!  
Unread 12-02-2016, 19:41
Rangel's Avatar
Rangel Rangel is online now
John Rangel
FRC #0842 (Falcon Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2009
Location: Phoenix, AZ
Posts: 745
Rangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond reputeRangel has a reputation beyond repute
Re: Two Motors on the same mechanism: risks and mitigations

We used a similar type of set up in 2013 for our climbing robot. Because it was such a compact design, our climbing hooks couldnt be mechanically synchronized. We ended up using encoders on both sets of hooks to have one controlled with pid for position while the other side tries to follow the master side. Overall it worked out fine as long as they started in the same place. Whatever you decide to do, I recommend against a potentiometer. That way if you are using any belts or chains, you dont have to worry about slippage or skipping and having to re adjust the sensor or code.
__________________
2012 Dean's List Winner
2011-2014 Arizona Regional Winners
2016 Las Vegas Regional Winner
2014-? Mentor


  #3   Spotlight this post!  
Unread 12-02-2016, 19:46
SenorZ's Avatar
SenorZ SenorZ is offline
Physics Teacher
AKA: Tom Zook
FRC #4276 (Surf City Vikings)
Team Role: Teacher
 
Join Date: Jan 2011
Rookie Year: 2011
Location: Huntington Beach, California
Posts: 946
SenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond repute
Re: Two Motors on the same mechanism: risks and mitigations

'a)' shouldn't be an option! What you're describing sounds good. We have a similar setup right now. We haven't had any real issues. We've also been testing it since week 2 with the motors and parts we are going to use at competition.

If you're using chain to drive the assembly you need to be wary of skipping after an impact. Then one of the two motors can get out of sync.
__________________
2013-present: FRC Team 4276, Surf City Vikings
2011-2012: FRC Team 3677, The Don Bots
  #4   Spotlight this post!  
Unread 12-02-2016, 19:56
Joe Johnson's Avatar Unsung FIRST Hero
Joe Johnson Joe Johnson is offline
Engineer at Medrobotics
AKA: Dr. Joe
FRC #0088 (TJ2)
Team Role: Engineer
 
Join Date: May 2001
Rookie Year: 1996
Location: Raynham, MA
Posts: 2,648
Joe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond repute
Re: Two Motors on the same mechanism: risks and mitigations

Quote:
Originally Posted by Rangel(kf7fdb) View Post
We used a similar type of set up in 2013 for our climbing robot. Because it was such a compact design, our climbing hooks couldnt be mechanically synchronized. We ended up using encoders on both sets of hooks to have one controlled with pid for position while the other side tries to follow the master side. Overall it worked out fine as long as they started in the same place. Whatever you decide to do, I recommend against a potentiometer. That way if you are using any belts or chains, you dont have to worry about slippage or skipping and having to re adjust the sensor or code.
I am a big fan of mechanical synchronization if you can get it -- hex shaft and hex bearings have really made this a much easier task...


...but if you can't get it to work, putting the computer in the middle doing the sync can be made to work.

I would actually suggest that you stay away from Master/Slave idea. I would put in independent PIDF loops to control each arm but I would have the RoboRio monitor the situation and take action if the two arms get more than X different.

As to sensors, I am going the opposite direct that Rangel(kf7fdb), absolute encoders like pots are your friend rather than incremental. You'll want your code to be tolerate of pot adjustments (e.g. have a simple way to offset the pots in code rather than forcing you to chase your tail tweaking pot position). The main reason I don't like encoders is that the have the problem of loosing position information when the RoboRio is not paying attention. You'll have to start the arms in exactly the same position each time. If your robot goes brain dead during a match you'll lose your arm position...

That's my two cents anyway.

Dr. Joe J.
__________________
Joseph M. Johnson, Ph.D., P.E.
Mentor
Team #88, TJ2
  #5   Spotlight this post!  
Unread 12-02-2016, 19:57
GeeTwo's Avatar
GeeTwo GeeTwo is offline
Technical Director
AKA: Gus Michel II
FRC #3946 (Tiger Robotics)
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 3,723
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: Two Motors on the same mechanism: risks and mitigations

While a mechanical linkage between the two to keep them in sync would be even better, your plan sounds good. Do some stress testing before bagging (or at least before competition) to determine how closely one arm follows the other; you may have to limit the top speed or acceleration of the master through all or part of the raise/lower cycle to stay in adequate sync.
__________________

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.
  #6   Spotlight this post!  
Unread 12-02-2016, 20:20
MisterG's Avatar
MisterG MisterG is offline
Think twice post once.
AKA: Alan Gilgenbach
FRC #2062 (C.O.R.E. - Community of Robotics Engineers)
Team Role: Team Spirit / Cheering
 
Join Date: Mar 2011
Rookie Year: 2011
Location: Waukesha, WI
Posts: 120
MisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to all
Re: Two Motors on the same mechanism: risks and mitigations

Quote:
Originally Posted by GeeTwo View Post
While a mechanical linkage between the two to keep them in sync would be even better
I may have neglected to mention that the reduction on each side is 324 to 1. This means that the gears will not back drive easily if at all and therefore linking will not be a practical way to sync them.
__________________
Alan Gilgenbach
C.O.R.E 2062
  #7   Spotlight this post!  
Unread 12-02-2016, 20:46
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Two Motors on the same mechanism: risks and mitigations

Quote:
Originally Posted by MisterG View Post
The proposed plan is to use a master / slave configuration

Consider this instead,

using x(t) motion profile for RLPC.


  #8   Spotlight this post!  
Unread 14-02-2016, 20:52
MisterG's Avatar
MisterG MisterG is offline
Think twice post once.
AKA: Alan Gilgenbach
FRC #2062 (C.O.R.E. - Community of Robotics Engineers)
Team Role: Team Spirit / Cheering
 
Join Date: Mar 2011
Rookie Year: 2011
Location: Waukesha, WI
Posts: 120
MisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to all
Re: Two Motors on the same mechanism: risks and mitigations

Ether,

Thanks, I was secretly hoping that you would chime in.

Question about the notation: is each of those four blocks is a separate PID with sp being the command and pv being the feedback?

Did you just come up with this now or is this a scheme that you have known about for some time and if so do you know of any cases where this has been used successfully?
__________________
Alan Gilgenbach
C.O.R.E 2062
  #9   Spotlight this post!  
Unread 14-02-2016, 21:12
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Two Motors on the same mechanism: risks and mitigations

Quote:
Originally Posted by MisterG View Post
is each of those four blocks is a separate PID
They are separate closed-loop controllers. You can use PID if you like.

Block#1 (the top one) and Block#3 are identical (but separate) and should have similar tuning parameters.

Block#2 and Block#4 (the bottom one) are identical (but separate) and should have similar tuning parameters.

EDIT: Get one side working by tuning Block#1. Then use the same type of controller (and gains) to drive Block#3. Then add Block#2 and Block#4 and tune them to make the sides synchronous, using the same gains in each.

Quote:
with sp being the command and pv being the feedback?
Yes. sp is SetPoint (command) and pv is ProcessVariable (feedback).

Quote:
Did you just come up with this now or is this a scheme that you have known about for some time and if so do you know of any cases where this has been used successfully?
Hat tip to Jared Russell.

Lengthy discussion at this thread.

Here's a simple method for getting a nice smooth x(t) motion profile (if smoothness is desired).




Last edited by Ether : 14-02-2016 at 21:32.
  #10   Spotlight this post!  
Unread 23-02-2016, 21:45
MisterG's Avatar
MisterG MisterG is offline
Think twice post once.
AKA: Alan Gilgenbach
FRC #2062 (C.O.R.E. - Community of Robotics Engineers)
Team Role: Team Spirit / Cheering
 
Join Date: Mar 2011
Rookie Year: 2011
Location: Waukesha, WI
Posts: 120
MisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to allMisterG is a name known to all
Re: Two Motors on the same mechanism: risks and mitigations

This is what we ended up using for feedback. They are AMS AS5030; they are similar to the CTR encoders that came out this year. These were reputedly in the KOP at some point in the past.



The magnets are inserted into the bolts at the ends of the shafts.



They are pretty compact compared to potentiometers.
__________________
Alan Gilgenbach
C.O.R.E 2062
Closed Thread


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 01:31.

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


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