Motors Overheating
My team and I have a competition this Saturday, and we’ve finally gotten a solid bot together. We don’t have access to pneumatics, but have a four motors driver running at ~280 RPM (green cartridges geared up 7:5), a one motor ‘scoop’ on the back that lift up and tilt a goal towards us, and a two motor arm geared down 3:7 using red cartridges. The lift is a standard four bar with rubber bands on either side to help with lifting. We also have a direct drive (red motor) clamp for grabbing mobile goals.
However, after just two or three practice runs, or sometimes even less, the lift seizes up and can’t go above a quarter of it’s maximum height with even an empty alliance goal. It still lifts on it’s own fine, just to give some perspective that it’s not severe to that extent.
I programmed (using blocks as I’m not greatly experienced in it) the lift to have maximum torque of 100% and tried lowering the velocity to 50%. No change. I couldn’t get the brain itself to show the temperature of the motor; any that I chose it said were at 0. So I added the temperature of our arm to the display on our controller and it said 70; no change still as to be expected. However, after having just attempted to and failed to lift a mogo, the temperature dropped down to 60. I tried again and could actually get it to lift the tall mogo a few times; even push down the unbalanced platform to try and ride up it. But it quickly went back to being unable to lift again–still saying 60 however.
Note that both motors felt hot to the touch, hence the reason overheating and temperature became an immediate concern.
At this point I had to leave for the day (this was only a few hours ago) and I’m still unsure as to what the main issue is. I see plenty of teams using one motor lifts, albeit geared down farther to 1:7. But is it that far off to think that two motors should be able to handle the increase in stress? Looking at the actual numbers, I’m aware that this is three times the load based on the gearing (3/7 = .429) / (1/7 = .143) = 3. Is this simply too much to expect of the motors or is there any visible concern with the build?
The only issue I can see with the lift itself is that one of the pieces of c-channel is bent, which leads to a slight offset of the lift itself. But I wouldn’t think that this would effect it so drastically, and both motors seem to be struggling equally when feeling them, not just the one on the bent side. I’d like to swap this out, but I’m not sure if there’s enough time before our next competition. I’m also just curious if that can have such a major effect.
We cannot cut aluminum because of how expensive it is and we don’t have any pieces the size of the front. Hence, I used steel for the end.
The bent side. This photo makes this side look bent, but it isn’t. I know the claw is cursed, I’ll be adding supports for the axle ASAP.
Brains Reading Motors Incorrectly
As I was trying to read the temperature of the motors on the brain, I was reminded again that the motors always show green here. This is under the devices category → any motor on the actual brain. I can change it by tapping the color, but it always reverts back after starting a program or anything. Is this normal? Does the default drive option (no program or anything) simply always assume and run the motors as if they were all green cartridges? Does this effect the programs downloaded and run in any way, including autonomous and programmed driver controls in driver control?
Rubber Bands
Currently, on the sides of the lift, we have four rubber bands (per side) that are highly tensioned when the lift is at it’s lowest and come to right around neutral when the lift is fully up (though not enough that they’ll come off). We’ve experimented with three, four, and five. I believe that they’re the longer of the two versions that VEX allows, but I’m sure the pictures will make that far more obvious. Does any of that sound like too much or too little?
Also, what is the optimal triangle for rubber banding? I know that there’s teams that use triangles and I’ve heard that they’re better, but I don’t know the sort of triangle shape I should be aiming for.
Static
Ever since adding any sort of lift (our first robot didn’t have one, but this one and our last one did) my team and I have had serious issues with static. We would constantly be disconnected and even white screen again and again. Having read through other posts, I think that the main issues is that, since there is no metal-on-metal contact between our lift and the base of our robot, the static is building up and ultimately discharging through the wire to our claw and shocking our robot. We’ve blown out four or five ports this year because of this at least.
I saw people suggesting using wire (as long as it’s less than 1/8 of an inch to be qualified as string) to ground the arm and potentially even the robot’s base itself to the tiles. I got the genius idea to grab a coat hanger that was in the room (I have no idea why it was there, but there was a pile of dozens with it), cut a section off, and stick it through the c-channel our lift is attached to. I then took screw-swapped shaft collars and clamped them to the ends to hold them on.
No, I’m not crazy. I think I’m quite a genius.
When the lift is up it presses against the metal, grounding it. I plan to add a second at the bottom too. Though I need to take a proper measurement of the width and may have to swap it out for something thinner.
Regardless, does this seem like it would be an effective solution to static? I know that having a piece of wire that can move with the lift, like a normal motor wire going down it, would be best. But as an actual concept–grounding through attaching a metal wire between lift and base–is this effective? Would having some piece of metal that runs across the floor do anything to help prevent static?
!
