pic: Basketball Drive

This is the first custom chassis I have designed. It is inspired by this robot:

It uses 4 toughboxes, 4 CIMs, and 4 basketballs.
It is mostly likely useless for competition because of weight/size. It might make a great demo bot though if you mount something on it (t-shirt cannon). The basketballs wouldn’t be ripped up by asphalt or cement like omni wheels or mecanums. It also would look really cool when it drives around.

This looks awesome! We might have to try something like this ourselves :stuck_out_tongue:

Would moving diagonally be an issue though, with the scrub force on the wheels you are using to drive the balls? Omniwheels might be better to use to drive the balls.

I agree, omni wheels theoretically would be a better wheel to drive the balls with.

It might be simpler and easier to replace the red basketball supports with a ball transfer like this. It could also help with the tiny scrub forces from the bearings.

Leaving some room for the motor leads may help. :wink:

I built something very similar (four balls and no wheels) in 2005. Unfortunately I’m not sure if any pictures or video survive.

This is feasible. Don’t expect this to be something useful in a FIRST game though. If you build it I will be interested to see if this ends up with the same sorts of issues as the one I built.

It is great that you have attempted to make it as compact as possible. In regards to the leads, you should be ok as the curvature of the adjacent CIM case should allow adequate space( unlike BAG’s the leads come out rear). But you will need to check this.

I disagree. The balls should never be moving perpendicular to one of those wheels, which is what an omni would help with. Drive just one wheel and the basketball will spin around the other wheel.

I think the problem would be that your traction is based on how much you’re compressing ball, since there’s no weight transfer from the robot. Plus compressing the ball is likely to make it pop out of where you’re capturing it. I’d suggest moving the wheels up to get more weight transfer, but then you would need omnis, and you’d run out of room for the balls unless you used bigger wheels…

Interesting points. Perhaps tires instead of hard wheels?

The issue is when you would move diagonally. Wheels on both sides of the ball would have to spin, and the axis the ball is turning around would be no longer be perpendicular to either of the wheels.

Here is a quick sketch of where I would think the axis would be when moving diagonally: https://docs.google.com/drawings/d/11VqwdAdUHyRPn18JtLDMhWrUNKzKlGVhxnDOI4KIXro/edit?usp=sharing

What were the issues that you had?

I would only see this useful in a wide open game or flat floored like overdrive or aerial assist. But it is a very cool concept that I would like to see passed around from what other people can do.

Reminds me of this guy’s rideable ball balancing robot, that sat on top of a bowling ball

The major problem was that when you impart a force to make the balls turn you’re also giving a force that wants to make some of the balls come out. So you couldn’t immediately go full power without risking unseating some of the balls. You could just go partial throttle to start though and you’d be ok, but that basically meant that you wouldn’t want to ever get in a pushing match either.

These balls are larger and heavier than the ones that I used while having an identical amount of power so it’s possible it might not be quite so bad. Another difference is that in this system the spring is the balls. I don’t know if that’s good or bad though. I don’t know that this system is radically better as far as keeping the balls in.

To me it’s almost uncanny how similar it looks: We used a 1x1 tube frame with two different levels that was mostly 90 degrees except for the pieces at 45 degrees over the top of the ball. Also, this doesn’t matter functionally, but seeing this image really surprised me because one of the types of balls we tested was bright yellow. We also ran with 4 CIMs, one per side, but we used belts and pulleys rather than large wheels to distribute the power.

The second issue that we had was that it wasn’t super controllable. There are plenty of robots that don’t like to drive quite straight - most of them will just sort of wander off into a big cicrle though. This one liked to be going straight and then it would decide that one of the sides was going to just start going slower at unpredictable times. So you could be walking down a hallway with it and things are going smoothely and then the robot decides that it’s going 30 degrees to the left of where it had been a second ago. I’d be interested to know if that was due to a flaw in our robot or if that’s sort of inherent to this type of drive.

The third issue was how it stacked up to the alternatives for that year’s game. It used four CIMs, which was as many as were allowed, but 2005 was also the first year with the AndyMark C-base drive chassis and gearboxes that could take all four of those CIMs. It wasn’t the first year with powerful tank drives, but it was the year that it became easy and common. And this was before mandatory bumpers and for a game that was played in a largely open field. The name of the game was go someplace fast don’t be movable once you’re there - exactly the opposite of what this kind of drive gives you.

It looks like each ball is in contact with 2 wheels. that would make every ball turn at the same rpm since they are all tied together which would just make the bot rotate in circles.

Only when all 4 CIMs are engaged in the same direction. When moving left/right or forward/backward with 2 CIMs engaged the balls should just pivot around the inactive wheel. You may receive some rotational movement when trying to move diagonally.

I dug up a couple photos in my email of the ball drive Eric was talking about, we were both on the team in 2005 when it was developed in the offseason. As Eric mentioned, it shared a lot of conceptual similarities with yours - 4 corner balls in a square frame, driven by 4 motors between each ball. It was also inspired by the 2-ball omni drive that Technocats built in 2003.

These were taken when we first assembled everything, as a first pass fit/function check of the captive ball. The lego tires shown on the rollers are just placeholders, and we later had to switch to a stronger hinge at the pivot point above the springs.

We tried several different balls to get something to work - we wanted something in the 4-5" diameter range. Many balls we tried were not quite round enough or too rough (dimpled pitching machine softballs). What is pictured are actually garden gazing balls. They were cheap and light, but welded together from two halves, so they had a bit of an oblong shape. The springs helped accommodate this. Also to Eric’s point about preventing driving the balls out from under the chassis, our outer corner ball transfer unit was placed below centerline of the ball (much like your latest update) to mitigate this.

Some of the biggest functional issues stem from the contact point between the ball and the driving rollers/wheels. To drive, you need friction here to transmit torque to the ball, necessitating a fairly significant normal force on the roller, and a grippy material. When the ball is being driven by the opposite roller, you want the ball to spin freely with low friction about the roller contact point. Finding the right balance here can be tricky.

I do like the use of larger wheels as a single roller contacting two balls. It is simpler (less moving parts) than the belt/roller system we had, and there should be minimal load on the wheel shaft, as the normal forces from the balls on either side are balanced. The layout works pretty well because of your choice of larger, basketball-sized balls.

I’ll try and do some more digging. Somewhere I have a low quality video of ours driving down a hallway.

Thank you everyone for the help! From what you have have told/shown me it looks as though I am moving in the right direction.

If we build this we would absouloutly have to use these balls.

Now to find a way to power them from the robot battery:yikes: .