Crab Programing

[Tytus Gerrish]

How is a crab robot programed,

i mean i hear things (probably rumors) like Krunch has 4 steering chains and they all point the wheels in the direction the joystick is pointed

there is the 1 link system where all the fenders are linked together and you stear kinda like a car with the joystick x-axis binded to the power output of the steer motor But, how can you tell where the wheels are pointed when there inside the bot?

I heard krunch used there Mini_krunch Edu-robot to figure out their programing and i think i saw the kids just pressing the stick in the direction they wanted it to go, How did they do that? or was i just imagining it?

Im designing a crab bot by my lonesome and want a program system where i can just point and it goes instead of trying to see where the wheels are pointed, I need to know as much as i can so i can make a nice impressive presentation to my team when its time to chose a design

Any Information Would Be Very helpful

[Rickertsen2]

The way Wildstang accomplished this, was to link a potentiometer rigged up as a voltage divider to one of the analog imputs. Then you can use a simple proportional control to figure out how to steer.

[FotoPlasma]

Using a potentiometer attached to a plastic sprocket, we could determine the orientation of the modules on our swerve system to within 1/255 of a rotation (except around the couple degrees where the potentiometer recycled). There's little to no need for visual cues of module orientation if two things: a) you can control direction electronically, and b) your driver is good enough.

If you want a feedback system like this, I suggest you first find someone familiar with PBASIC enough to attempt writing the code for you, if you don't think you're up to it (I seem to recall a couple threads in which you asked for programming help).

If you need any more intensive help, feel free to ask. I'm willing to explain most of our system (only "most" because I don't know the software algorithm used to actually steer). Mechanical and electrical aspects of it, though, I am very familiar with.

Oh, here's a picture of one side of our swerve. You can see the black plastic sprocket on the right, next to the drive module sprocket.

[WakeZero]

Honestly there are so many different types of swerve, and all of them require a different programming technique. For instance, are there motors on each individual wheel, or are they all controlled by one motor/gearbox?

edit: The later is MUCH easier, because you don't have to compensate for individual motor differences... that was the hardest part when I programmed our swerve in 2002

[miketwalker]

I think most of it comes down to the driver's capability. You can find out how comfortable he is, and you can have a 2nd joystick to power the steering motor, or you can use the x-axis... but if you do that, it can become a mess, cause naturally you angle sometimes when going forward, and if u angle it a bit, the wheels will keep turning... not good. I know Krunch had a flip switch they did on the joystick, in 1 mode the wheels would turn the same and it would maneuver left and right, but couldnt turn, the other would have it where when the front wheels turned left, the back would turn right, so the robot would spin and act like a normal bot, you could program this by using the inverse number (so instead of I.e. 255 [which would be too fast more than likely] it would inverse and use 0 if you used a math equation) and the wheels would turn opposite so u could turn. All depends in how the steering is setup, but I imagine it could be easy to code, then you can adjust numbers to make it not spin so fast, or spin faster, and then the driver just has to learn it and get a feel for it.

[Rickertsen2]

o and as far as pushing the stick where you want to go:
you must take the XY position and convert it to a polar vector. You use the method i mentioned earlier to align the angle of the wheels with the direction f the vector. The magnitude of the vector is the power you apply to the wheels. If you need help i will write a more in-depth description.

If u need any code help, i can give you some pointers as well.

[Tytus Gerrish]

TytusG@Coolgoose.com

Yeppie! Send it to me IM ready Obi-one

[FotoPlasma]

I way overcomplicated the whole situation with my first post. If this is just a proof-of-concept/feasibility project, you don't need to get into the nitty gritty of making a fully functional program for it.

All you really need is to be able to define four basic things: 1) direction of wheel rotation (robot goes forward or backward), 2) magnitude of drive (how fast to go), 3) direction of module rotation (clockwise or counterclockwise), and 4) magnitude of module rotation. In PBASIC, you'd do this with two PWM outputs.

If you're using an EduBot, it'd be pretty simple for someone to hack up some code for you.

[Tytus Gerrish]

can i see an example in PBASIC please?

[FotoPlasma]

Originally posted by Tytus Gerrish
can i see an example in PBASIC please?

Well, the problem with that is that hardware and software are interdependant. I (or any fairly competent team programmer) could write you a program that takes the y-axis of the joystick on port 1 and maps it to the output(s) controlling the drive motor(s), and then takes the x-axis of the same joystick, and maps it to the output(s) controlling the rotational motor(s).

If you want a program ready to be slapped into an EduBot, I suggest you get in contact with 179's programmer(s), and get them to do this as a side project.

Fundamentally, though, here's how you would define the two variables which would be used to determine the four things in my previous post:

PWM1 = p1_y
PWM2 = p1_x

The default EduBot code uses some funky conventions concerning variable names and whatnot. They use the variables drive_L and drive_R, instead of PWM#.

But anyway, back to the topic at hand. Because of the actual structure of the Basic Stamp program, there're a lot of very important pieces of the program that, obviously, aren't included in the above excerpt.

Really, I suggest you find someone whom you can talk to in person about your system. Ambiguity of description isn't safe when programming robots, generally, and it's a lot easier to be clear and concise in real life, than online.

[EricS-Team180]

Hi Tytus,

Matt Reiland has graciously provided a reference to his team's (226) swerve drive code in this thread:


http://www.chiefdelphi.com/forums/s...?threadid=14703

It may be useful!

Eric

[Matt Reiland]

Yikes the link didn't work, here it is again

http://www.chiefdelphi.com/forums/sh...threadid=14703

This is everything you need to control a crab drive, modify as you would like. In our case, all 4 modules were linked together. Using the code as an example you can easily break it into more complex steering (However variable space becomes an issue quickly when calculating angles)

Enjoy......

[Damian Manda]

Last year we used a swerve/crab/translational drive. Eventually we had the program working pretty well. We used a custom circuit to detect wher the wheels where, bu a pot could also be used. I you want to see the code, ask Adam Collet on my team (159).

[Tytus Gerrish]

i can sucuessfully program the crab in lego mindstorms
I dont quite get the text verision