Here at Brooklyn Tech, our Robotics team is, for the first time, using mecanum wheels in combination with a circular frame. Our goal is to program our robot to do what we refer to as a spiral: a motion of simultaneous spinning and going forward. If anyone could offer any help or advice in making this happen we would be eternally grateful.
M. Williams
Unfortunately I won’t be much help with your programming question, but I do feel compelled to ask:
Why you would want to spin and move forward at the same time?
OK, so you want the robot to travel in a straight line one way while spinning in circles in place??? Ouch.
I think the easiest way is, don’t. Then again, I’m not a programmer.
From what I know of what a mecanum can do, I know they can arc while sliding in any direction (which may be what you want). They can spin in place. They can go straight in any direction. I don’t think they’re quite capable of doing what you apparently want. Then again, I can’t think of any drive that can do that, unless you take a TechnoKat ball drive and put it on a freely rotating turret in the middle of an omnidrive base.
The only way I can think of is to have the direction and rotation separate sticks, then put something like a mouseball on the robot to tell which way you were going (set up something like the ball drive referenced above, but with a rotation sensor of some sort) and program the robot to reorient its own programming based on the feedback… I’m out of my depth now.
1675’s mecanum code this year may be able to perform what you describe…
(I admit i have not seen almost any of the driver practice, as I was sick for the last couple days of build :P) but it may come out as more of an forward arc. I’m not sure.
What our algorithm does is get velocity and angle from one stick, and rotation from another, then calculates the PWM value of each individual motor taking those 3 variables into account. You can see our algorithm here:
http://team1675.org/forum/viewtopic.php?p=1352#1352
Most of the calculations are not shown (ex: getting the velocity and angle, scaling the rotation value), but the key lines are
MotorOutput = (((WORD)mySin( Heading ) * (WORD)Speed) >> 8) + ((256 - Speed) >> 1);
MotorOutput += Rotation;
This is called for each motor. It first sets the value of each motor based on velocity and angle, then adds/subtracts the rotation value from each wheel.
This should create a spinning effect, but while moving forward, as I said, I am not sure, it may come out as an arc.
I don’t know about programming the robot in a spiral moving forward at the same time, you would most likely have to get a compass sensor implimited onto the robot to know which way is is facing, if you need help or need some guidence in the normal programming of the robotmoving forward, backward, sideways, diagnal and then turn in place I can help you with that.
It’s not extremely hard, it’s called operator (or field) oriented control, as opposed to robot oriented control. You need a gyro (comes in the KOP) and simple trig.
Operator oriented means that controller directions are defined (with the help of the gyro) so that ‘up’ is always the operator’s ‘up’, not the robot’s ‘up’. Field oriented is a little more specific and means it’s zeroed relative to the field’s directions, so that the robot’s ‘up’ is the same as what you might call the field’s ‘up’.
You can’t just have it do what you say, at least not in a practical way that I can think of, without being operator oriented. When the robot is spinning and going in a straight line at the same time, ‘forward’ is defined relative to a reference heading kept track of with the gyro. So ‘forward’ can’t also be whichever direction the robot is facing, not without having a switch to turn the operator oriented control on and off.
Here’s my $.02, but be warned that we’re still trouble-shooting this. I don’t remember what the exact bugs are right now, but I do know it doesn’t frisbee very well.
There are two halves to the trick you described (also called “frisbeeing”, iirc). The first is indeed having field-oriented controls. Your other option is to precisely spin the strafing joystick opposite the way the bot is spinning. I don’t have that coordination.
The second step is to be able to combine spin with driving properly. As of right now, my team’s mecanum code determines the strafing speeds first, sets temp vars, and adjusts the temp vars for spin, then sets the PWMs to those temp vars. If you do this, you may need to reduce your spin adjustments in order for the spin to not totally override the strafing.
Good luck!
Thank you all for taking the time out to help us. The programming division here at 334 isn’t too psyched about it but one of our advisors insists that if we’re going to do this properly we have to be able to do this also.
Thanks for the offer Cow Bell Solo, however we already have the front/back ect. down.