Quote:
Originally Posted by Max Boord
Also what performance gains (if any) where found by switching the drive and intake wheels for worlds. I had heard that they where switched for weight but the intake appeared to be a little faster at centering the ball as well.
|
It was all for weight. Any other improvements were purely accidental. Thanks to 254 and 118 for their suggestions! There may have been a software update to speed the intake up (can't remember). We geared the intake and bottom kicker roller for 25+ FPS and then started out by running them at 8 volts (8/12 duty cycle) to take the nicer motor and make a less powerful motor out of it.
Quote:
Originally Posted by aphelps231
Would someone be willing to speak a bit on how power is managed and brownouts are prevented on this robot? Maybe it's a non-issue, but with the amount of motors on the robot and the large forces they (seemingly) must endure, it seems some kind of smart power management would be necessary.
|
It turned out to be a non-issue. We don't drive with the superstructure up, so that makes it such that most of the motors aren't in use most of the time. The intake is motion profiled, so that effectively current limits it in 99% of the cases, and none of the other motors are really loaded.
If that didn't turn out to be correct, we were ready to fix it in software. We would have current limited each control loop by looking at the velocity of the motor, backing out the BEMF voltage, and using that to limit the current. I think that was on the original plan, but wasn't an issue and got forgotten about.
4 CIMs in the drivetrain helps a lot as well.
Quote:
Originally Posted by aphelps231
Maybe the answer to this is related to that of the above, but what drove the decision behind which reductions and how many motors to put on each gearbox?
|
Here's our arm calculation spreadsheet. It is the most interesting one in terms of pushing the limits. We really should have either slowed it down or put a second motor on the joint for power dissipation. It was plenty fast and torquey with just 1 motor. We had to motion profile it to prevent the superstructure from setting up an ugly torsional mode when accelerating. 2015 taught us a lot about motion profiling, such that we no longer let any of our superstructure joints run without motion profiles.
https://docs.google.com/spreadsheets...it?usp=sharing
We look at time to make a characteristic move (assuming that the motor is working against gravity but at steady state), and the holding voltage/power required to hold the arm at that set point. VP released awesome charts about motor life at various holding voltages this year. We targeted a peak of 4 volts holding voltage on all our joints. I'm thinking next year we should drop that down to closer to 3 volts since we had to add fans to the shoulder motor, and replace it a couple times. We like to target ~1/2 second max for motions. Too much longer and you end up waiting on the robot too much.
We started out by putting 1 775 pro on each joint and looking at what that was going to mean in terms of power dissipation and speed. The analysis showed that everything was fast enough that way, and we didn't have to look any further.
Over the past couple years (really starting in 2014), we've been working on iterating our designs to remove common and known failure modes and weaknesses. We've focused on trying to not burn out motors, rate belts, chains and gears for the required load, and put weight into places where we see consistent failures. Our goal is to go through a season where we perform to our fullest potential without failure on the field.
One fascinating thing I learned this year is that for some subsystems, you should gain schedule your controller based on whether you are sourcing power from your motor and using that to drive your load, or pulling power out of your load with your motor. This flips the efficiency. If you assume that the efficiency reduces the torque of your motor by ~5% per reduction and hard-code that into your model, it essentially means that when the motor decelerates the load, the torque is reduced. The physics contradicts this. When you decelerate the load, the load is putting power into your motor, and the gearbox has losses during that transaction. The result is that accelerations reduce effective motor torque, and decelerations actually increase effective motor torque.
I bring this up because we had a lot of trouble tuning the arm controller. The only way we could get smooth behavior when both lifting and lowering the arm was to design an "accelerating" controller and a "decelerating" controller and switch between the two depending on whether we were accelerating or decelerating. It was really cool to finally figure that out. I've seen this for probably close to a decade (I remember struggling in 2005 to tune a controller to go up and down nicely), but hadn't ever gotten fully to the bottom of the issue and had a good physics explanation for what was wrong.
I'm not sure our switching logic is right, though it was better than no switching. This summer, I want to have someone analyze how we switch between the two controllers and make sure the transition is continuous. I've got summer project ideas to keep the students and myself busy all summer
(yea, yea, we are working on releasing our code. We just finished the last code reviews, and are working on hosting it correctly. Code quality is important!)