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.
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.
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.