hello, im trying to design a 3-motor h-drive with omniwheels. how would i code the drive system to be able to drive forwards, backwards, sideways, and rotate around the middle? here is a picture of the base im trying to base my design off of:
if possible i want a way to limit the controls to one joystick for forward, backwards, and rotation around the center. sideways motion can be controlled by a L and R button on the Joystick controller
If you are going to use the left joystick to control forward, backward, and rotation, you would need to set the back right motor to channel 3 - channel 4 and the back left motor to channel 3 + channel 4. This would mean that when channel 3 is forward all the way, both the left and right motors will move forward. Then if channel 4 is to one side all the way, the right and left motors will spin opposite of each other. I have never build an H drive before so I’m not sure if it would rotate around the center. If you are planning on using 3 wheels per side, then powering the middle wheel would make it most likely to rotate around the center wheel. To program the middle wheel, you could make some if statements for the L and R buttons that sets the middle motor to specific values such as 127 and -127. I have only used PROS to program so I’m not sure how useful sample code would be for you but I can write some if you need more help.
all the wheels on the same side will be connected to a single motor. but what youre saying is to essentially use a standard arcade tank drive code plus a two button statement?
I would think that would work best. I’m not sure how well connecting all the wheels together on each side will work with turning but it should work.
Exactly. Although I would suggest using a joystick to control speed of the sideways drive, but I guess you can use buttons if you wanted.
Hmm. From the restrictions you’ve listed, are you planning to run the whole robot off of one handheld controller? I would very much advise using two controllers to run a holonomic robot. Utilizing the holonomic drive and controlling the game mechanisms at the same time demands a lot of coordination, and you only have about four fingers that can control things at once. If you have two drivers, one can run the chassis to its fullest while the other worries about game mechanisms. (And add a coach to worry about watching the field and choosing objectives, and the division of labor is complete.)
As for control schemes within the limits you’ve presented, the one others have presented here of Arcade Drive Plus Sliding Buttons is one solution. However, it doesn’t give you much control over how fast you slide sideways, and if you put the Slide Left and Slide Right buttons on opposite shoulders of the controller it involves both hands, when you might want the other hand free to run other mechanisms. Another could be that holding one of the buttons swaps the joystick to an Orthogonal Translate mode where the joystick won’t rotate the robot around Z, but only do motion along X and Y. That is, the horizontal axis of the joystick swaps from being turning to being sliding at the push or hold of a button. The second button could enable a Crab Arcade Mode where the horizontal axis of the joystick moves the robot left and right, and the vertical axis either turns the robot towards its front or back while in motion.
If you do want to do Sliding Arcade Drive, you might consider making the sliding speed of the robot dependent on robot state. Like if you have a raised arm or open claw, it slides slower, but if everything is buttoned up and stowed, it slides faster.
That’s my two cents on non-standard control schemes. Hopefully you find it useful. Unless you were just asking for details on implementation, for which this is rather useless.
huh, is there any rule against just sitting on the ground and placing the controller on the mat so that you have more fingers to use?
no, but I am fairly sure I read a rule about how the drive team members need to stand unless there is a disability. Also, this would not pan out very well at worlds, where the fields will be raised by 3 feet.
I like @John TYler 's suggestion. You give up a lot of control only being able to slide sideways at a single speed. Meanwhile, you probably aren’t going to be trying to rotate while moving in weird directions (strafing while potentially moving forward/backward, let’s call it “slide”) too often, partly because it’s just hard to drive that way. If you aren’t going to rotate and slide at the same time, then there is minimal loss toggling between the two options.
Are you trying to avoid the second stick because it has another use? Are you avoiding it because of the driver’s number of hands/fingers? I’m wondering because, depending on the reason, there may be other alternatives to the provided constraints.
yes, exactly that is why im trying to avoid the second stick. it controls the arm of the bot. im at a school and we cant afford the partner-controller
this is the type of solution that would be useful to me. how would i code this
is this a good starting point? for defining the two different drive modes, ill add the second drivemode soon
#pragma config(Motor, port2, leftdrive, tmotorVex393_MC29, openLoop, driveLeft)
#pragma config(Motor, port3, rightdrive, tmotorVex393_MC29, openLoop, reversed, driveRight)
#pragma config(Motor, port4, middrive, tmotorVex393_MC29, openLoop)
//!!Code automatically generated by ‘ROBOTC’ configuration wizard !!//
task drivemode();
task main()
{
while(1==1)
{
if(vexRT[Btn5D] == 1)
{
startTask(drivemode);
}
else
{
stopTask(drivemode);
motor[port2] = 0;
motor[port3] = 0;
motor[port4] = 0;
}
}
}
task drivemode()
{
while(true)
{
motor[port2] = vexRT[Ch1];
motor[port3] = vexRT[Ch1];
motor[port4] = vexRT[Ch2];
}
}
Honestly, I would just use buttons for a thing such as an arm and have it run at an optimum speed, or have a toggle button as well so the arm can run at 2 different speeds.
hmm, alright. also i need help with something else. i cant get any form of deadband for the joysticks to work. ive tried multiple versions people sent on this forum but i cant get it to work
While (1=1){
LeftDrive = JoyVERT + ((1-BtnSHFT)*JoyHORZ)
RightDrive = JoyVERT - ((1-BtnSHFT)*JoyHORZ)
CrabDrive = BtnSHFT * JoyHORZ
}
Something like that should make it so that when your shift button is NOT pressed, side to side would rotate the robot, and when the shift button IS pressed, you would strafe.
is that even capable of being used on the vexRT system? the whole “JoyVERT and joyHORZ and BtnSHFT?”
Those are probably just placeholders for whatever you decide to use as the joystick channels/button.
#pragma config(Motor, port2, leftdrive, tmotorVex393_MC29, openLoop, driveLeft)
#pragma config(Motor, port3, rightdrive, tmotorVex393_MC29, openLoop, reversed, driveRight)
#pragma config(Motor, port4, middrive, tmotorVex393_MC29, openLoop)
//!!Code automatically generated by ‘ROBOTC’ configuration wizard !!//
task main()
{
while(1==1)
{
motor[leftdrive] = vexRT[Ch1] + ((1-vexRT[Btn5D]) * vexRT[Ch2]);
motor[rightdrive] = vexRT[Ch1] - ((1-vexRT[Btn5D]) * vexRT[Ch2]);
motor[middrive] = vexRT[Btn5D] * vexRT[Ch2];
}
}
is this what it should look like? the compiler isnt displaying any errors but i dont know if this is how its supposed to be
At a glance, it looks good to me.
may i ask how exactly the code is meant to work? like, how the math plays a part in the channel controls?
