Go to Post There is no rule that specifically states that you must obey the law of physics during the competition. This may be an oversight. - bmather [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 Rating: Thread Rating: 2 votes, 5.00 average. Display Modes
  #1   Spotlight this post!  
Unread 21-01-2015, 17:58
vinharish7 vinharish7 is offline
Registered User
FRC #4188
 
Join Date: Jan 2015
Location: United States
Posts: 9
vinharish7 is an unknown quantity at this point
Constant Rate of Acceleration

Hello I am a rookie programmer and I am struggling! Does anyone know how to set the constant rate of acceleration for mecanum drive!!! Any help will be appreciated! THANKS
  #2   Spotlight this post!  
Unread 21-01-2015, 19:21
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: Constant Rate of Acceleration

Quote:
Originally Posted by vinharish7 View Post
how to set the constant rate of acceleration for mecanum drive!!!
More context and detail please.


  #3   Spotlight this post!  
Unread 21-01-2015, 22:54
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: Constant Rate of Acceleration

When you have all wheels going forward or reverse, the rate of acceleration for mecanum is calculated essentially the same as that of traction wheels as long as you don't lose traction and "spin out". The maximum rate of acceleration (at low speeds) is going to be equal to the coefficient of friction in rolling motion times gravity. For most of the FRC mecanum wheels is going to be about 0.7 * 32 fps/sec, or 22 fps/sec. Because of the way mecanums interact with the floor, the maximum strafing acceleration is a bit lower than forward, and on a 45 degree bias, it will be off about 30%. Curiously, the fastest "acceleration" you can manage with mecanums is to spin; all of the wheels engage with the floor just as well as they ever do, all at the same time.

Last edited by GeeTwo : 21-01-2015 at 22:55. Reason: add "calculated"
  #4   Spotlight this post!  
Unread 22-01-2015, 16:38
vinharish7 vinharish7 is offline
Registered User
FRC #4188
 
Join Date: Jan 2015
Location: United States
Posts: 9
vinharish7 is an unknown quantity at this point
Re: Constant Rate of Acceleration

Hi guys, thanks for your help; I understand how the rate of acceleration is derived with physics but I want to know how to limit the Volts/sec on our Mecanum drive motor controllers. We are using CANTalons, we're programming in Java--Command-Based, and we have implemented the setVoltageRampRate() method. That works pretty well to prevent the robot from zooming to a really high speed or stopping abruptly (which would cause totes to fall!) but the problem is driving is much tougher as drivers have to account for the time it takes for the robot to decelerate, making our positioning senses go out of whack.

Is there a way to program the mecanum drive so we can set a fixed low rate of acceleration without losing accurate drive position control? So we researched PID loops and such but since we have never implemented them before we wanted to know if this would solve our issue (I think it would?) and if so, how exactly... Do we have to create a new PID subsystem and somehow connect that to our motor controls?

Thank you! Any help will be greatly appreciated
  #5   Spotlight this post!  
Unread 22-01-2015, 23:23
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: Constant Rate of Acceleration

Quote:
Originally Posted by vinharish7 View Post
.. I want to know how to limit the Volts/sec on our Mecanum drive motor controllers. We are using CANTalons, we're programming in Java--Command-Based, and we have implemented the setVoltageRampRate() method. That works pretty well to prevent the robot from zooming to a really high speed or stopping abruptly (which would cause totes to fall!) but the problem is driving is much tougher as drivers have to account for the time it takes for the robot to decelerate, making our positioning senses go out of whack.
Perhaps you can call the setVoltageRampRate() function every time you change the target voltage -- to a lower value when increasing speed and to a somewhat higher rate when reducing speed.
  #6   Spotlight this post!  
Unread 25-01-2015, 12:24
Toa Circuit's Avatar
Toa Circuit Toa Circuit is offline
Thaddeus Maximus
AKA: Thad Hughes
FRC #4213 (MetalCow Robotics)
Team Role: Leadership
 
Join Date: Nov 2012
Rookie Year: 2012
Location: Shirley, IL
Posts: 131
Toa Circuit is an unknown quantity at this point
Re: Constant Rate of Acceleration

Quote:
Originally Posted by vinharish7 View Post
Hi guys, thanks for your help; I understand how the rate of acceleration is derived with physics but I want to know how to limit the Volts/sec on our Mecanum drive motor controllers. We are using CANTalons, we're programming in Java--Command-Based, and we have implemented the setVoltageRampRate() method. That works pretty well to prevent the robot from zooming to a really high speed or stopping abruptly (which would cause totes to fall!) but the problem is driving is much tougher as drivers have to account for the time it takes for the robot to decelerate, making our positioning senses go out of whack.

Is there a way to program the mecanum drive so we can set a fixed low rate of acceleration without losing accurate drive position control? So we researched PID loops and such but since we have never implemented them before we wanted to know if this would solve our issue (I think it would?) and if so, how exactly... Do we have to create a new PID subsystem and somehow connect that to our motor controls?

Thank you! Any help will be greatly appreciated
It sounds like you should use an integrated motion unit like the NAV6 or NAVX, or use encoders on you wheels (and derive acceleration from them). You could then run a control loop (not sure what exactly it should be- maybe Take-back-half?) to keep your acceleration constant, up to top speed (where power produced by the motor(s) is equal to the power consumed by friction).

You can possibly do some tweaking with the voltage ramping, but even then, that's just voltage, not acceleration. Your acceleration will be a function of input voltage, losses due to friction, (possibly traction), mass of vehicle, and current speed (because brushed motors produce linearly less torque as their speed rises).

This is a problem I've actually never seen tackled before, and one which we might look into using the nav6 board...
__________________

2012 Head of Programming and Electrical
2013-14 Overall Team Captain and Programming Head
2012-14 Mentor of FLL Team Power Surge
2014 Dean's List Finalist
2014 CIR Xerox Creativity Award
Webpage
  #7   Spotlight this post!  
Unread 25-01-2015, 12:58
gpetilli gpetilli is offline
Registered User
FRC #1559
 
Join Date: Jan 2009
Location: Victor, NY
Posts: 286
gpetilli is a name known to allgpetilli is a name known to allgpetilli is a name known to allgpetilli is a name known to allgpetilli is a name known to allgpetilli is a name known to all
Re: Constant Rate of Acceleration

Many teams will impose a ramp on the joystick command input to limit the change in velocity (a.k.a acceleration) command. Some of the speed controllers can also do this for an individual wheel (which will mess up the mecanum kinematics). Yet another way is to use the accelerometer built into the roboRIO and reduce the command value if the acceleration is getting too close to the "spin out" speed. The accelerometer is probably better suited to detecting that you already spun out and therefor maybe the least useful option.

I would recommend imposing a software ramp on the joystick command even if you implement some other control method. It also helps to limit peak motor current - especially if the driver is going full velocity forward and throw the robot into full reverse - which will often pop a breaker.
  #8   Spotlight this post!  
Unread 27-01-2015, 10:37
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 359
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: Constant Rate of Acceleration

Quote:
Originally Posted by Toa Circuit View Post
It sounds like you should use an integrated motion unit like the NAV6 or NAVX, or use encoders on you wheels (and derive acceleration from them). You could then run a control loop (not sure what exactly it should be- maybe Take-back-half?) to keep your acceleration constant, up to top speed (where power produced by the motor(s) is equal to the power consumed by friction).

You can possibly do some tweaking with the voltage ramping, but even then, that's just voltage, not acceleration. Your acceleration will be a function of input voltage, losses due to friction, (possibly traction), mass of vehicle, and current speed (because brushed motors produce linearly less torque as their speed rises).

This is a problem I've actually never seen tackled before, and one which we might look into using the nav6 board...
Based on the various requests for this capability (which by the way hasn't really been assessed for accuracy yet), what follows is a snippet of code which is an extension to the nav6's IMUAdvanced class to calculate displacement. Your feedback is welcomed, if there's enough interest we'll create a separate thread on this topic, where the method and the results from the investigation can be gathered and reviewed:


Code:
    private float last_velocity[] = new float[2];
    private float displacement[] = new float[2];
   
    /**
     * Zeros the displacement integration variables.   Invoke this at the moment when
     * integration begins.
     * @return none.
     */
    public void resetDisplacement() {
    	for ( int i = 0; i < 2; i++ ) {
    		last_velocity[i] = 0.0f;
    		displacement[i] = 0.0f;
    	}
    }
    
    /**
     * Each time new linear acceleration samples are received, this function should be invoked.
     * This function transforms acceleration in G to meters/sec^2, then converts this value to
     * Velocity in meters/sec (based upon velocity in the previous sample).  Finally, this value
     * is converted to displacement in meters, and integrated.
     * @return none.
     */
    
    private void updateDisplacement( float accel_x_g, float accel_y_g, int update_rate_hz ) {
    	
    	float accel_g[] = new float[2];
    	float accel_m_s2[] = new float[2];
    	float curr_velocity_m_s[] = new float[2];
    	float sample_time = (1.0f / update_rate_hz);
    	accel_g[0] = accel_x_g;
    	accel_g[1] = accel_y_g;
    	for ( int i = 0; i < 2; i++ ) {
    		accel_m_s2[i] = accel_g[i] * 9.8f;
    		curr_velocity_m_s[i] = last_velocity[i] * (accel_m_s2[i] * sample_time);
    		last_velocity[i] = curr_velocity_m_s[i];
    		displacement[i] = displacement[i] + (curr_velocity_m_s[i] * sample_time);
    	}
    }
    
    /**
     * Returns the displacement (in meters) of the X axis since resetDisplacement()
     * was invoked.
     * @return none.
     */
    private float getDisplacementX() {
    	return displacement[0];
    }
    
    /**
     * Returns the displacement (in meters) of the Y axis since resetDisplacement()
     * was invoked.
     * @return none.
     */
    private float getDisplacementY() {
    	return displacement[1];
    }
  #9   Spotlight this post!  
Unread 30-01-2015, 20:06
vinharish7 vinharish7 is offline
Registered User
FRC #4188
 
Join Date: Jan 2015
Location: United States
Posts: 9
vinharish7 is an unknown quantity at this point
Re: Constant Rate of Acceleration

Quote:
Originally Posted by GeeTwo View Post
When you have all wheels going forward or reverse, the rate of acceleration for mecanum is calculated essentially the same as that of traction wheels as long as you don't lose traction and "spin out". The maximum rate of acceleration (at low speeds) is going to be equal to the coefficient of friction in rolling motion times gravity. For most of the FRC mecanum wheels is going to be about 0.7 * 32 fps/sec, or 22 fps/sec. Because of the way mecanums interact with the floor, the maximum strafing acceleration is a bit lower than forward, and on a 45 degree bias, it will be off about 30%. Curiously, the fastest "acceleration" you can manage with mecanums is to spin; all of the wheels engage with the floor just as well as they ever do, all at the same time.

Yes! This is what we did for the simplest solution, and it's working wonderfully! I might also try to limit the joystick-set correlation to acceleration.
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 02:53.

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