Most of the competition robots I see have very similar drive characteristics, a square base one or two inches off the ground.
Post pictures if you did something a little unusual.
Here’s a prototype I’ve been working on that’s a bit different.
1 Like
This looks like a great design. There would be a good COG and could get over the bump quite easily.
I would like to see this used on a competition robot, it’s different.
Now it’d be really cool if it had a joint at the top and you could fold up your whole robot to fit it under the 12" barrier in the middle 
It does fit under the barrier, just over 11 inches high. Built from 5x25 structure with no cutting required, 17.75 inches long and wide. No idea what an intake would look like yet.
1 Like
If you would put the cross brace more on one end instead of in the middle, you would have the whole middle area through the opposite end to place an intake, but lose stability in the frame.
Last year our Z team (not me) did a pretty unique drive system. They decided to really focus on being able to drive over sacks and ended up with this …
They used their plastic allowance to make triangular drive pods and used 4 interconnected single-acting pneumatic pistons per pod to act as shocks (we have a lot of single acting cylinders now :)). Not entirely necessary in my opinion but definitely pretty cool
Driven Robotics, team 1224J I believe, actually used a very similar drive design last year for sack attack with a spatula design. It can definitely drive over sacks very well.
I saw one of Asian team had same chassis configuration .
Link? (too short)
Over the summer, I was kicking around an idea for a three-wheeled base. The back two wheels would be at 45 degree angles, like the back two wheels of an X-Drive. The third wheel would be in front of those, in the center. It looked like this.
In theory, it was capable of full holonomic travel with three (or six) motors. The biggest problem was that you have to keep the motor power for the wheels at different levels. AURA’s description of vector forces in an X-Drive is great for understanding why. Basically, the back two wheels would be going faster than the middle wheel, meaning they would need to be slowed down from their maximum.
Between the need to have the CoG way in the back of the robot the entire time, and not turning around the center of the robot (it would turn along the interior chassis rails) it had some things we would have needed to experiment with. I don’t know if those would be real issues, though. The potential damage to the motors (if the code wasn’t perfect, you could end up trashing the interior components) scared a bunch of people on our team, and we never got the chance to build it. I’m thinking about trying to make it work later, but we’ve got our actual robots to build first.
This is sort of like what is colloquially called a kiwi drive ( http://botsnstuff.com/wiki/Kiwi_Drive )
I don’t believe a kiwi drive would work if the wheels were not in a regular triangle formation, so yours allows the front wheel to be much further forward.
Also, the code doesn’t seem like it’d be horribly difficult for running the back motors at the correct, slower speeds. You would just divide the speed for the rear motors by sqrt(2), would you not? I realize there’s the whole speed curve to take into consideration since the speed output isn’t linear but I imagine dividing by sqrt(2) would be a good enough approximation and if you wanted to get more exact than that then it wouldn’t be horribly difficult to do.
I also like that this design allows using the front wheel for driving forward unlike a Kiwi Drive. I agree that the in-place rotation, though, would be a nightmare. It would basically be a more versatile tank drive with arcade controls. Weird to get used to but I’d be interested in trying it for sh!ts and giggles.
1 Like
That 3-wheeled base was the design that I looked at to start the idea. I had seen it on some FRC Robots, and wanted to improve it. Except for when the robot is spinning in a circle, one of the wheels is inactive at all times. My goal was to get the third wheel doing something more often, and hopefully in a more useful application.
Yeah, the code seemed simple to me. It’s just that when you try to explain code to non-programmers, they get antsy about things going wrong. I think what you have there would work, but my memory is slightly foggy. I actually wrote it at one point, but it seems to be on a different computer.
It seems challenging to use, yeah. I’ve got all the parts to make one, and it wouldn’t take more than an hour. Once I get our three competition bots running, I might try my hand at this.
here’s a something similar I’ve tinkered with.
I probably would have used it but it didn’t fit with my lift configuration.
The challenge is to make side C (the horizontal side) flat.
it’s looking to be an interesting game so far.
cheers
Phillip.
1 Like
What is that? It looks like half of a Mecanum drive.
It’s a side view, the other two wheels are hiding behind it.
In function (and configuration) it is the same as any other mechenum drive (sort of like Jpearmans). Mechenums have been (in my experience) difficult this year because they lack traction on the bump.
Sorry for the confusion:)
Phillip.
edit:
I just realized that this was an earlier pic when I only had one side of together. my fault
Here is the screen shot form a video. It was in the competition on August, 2013 in China.
The red arrow points to the robot.
Would you mind posting the video? I’d be interested in seeing that at work
Can you post a link for the video?
Hi, Guys.
The file has more than 200 MB and it is quick time format. I don’t have software to edit and change it to smaller file to post on Youtube. Sorry about that.
It looks ok and a little bit clumsy. I didn’t see any advantage over others.
I got the video posted