My team is building and programming (in Vexcode IQ Blocks) an “X-drive” omnibot, and we want to add a drivetrain device to have the robot drive forward/back in a straight line (with the help of a gyro sensor), and we also want to have direct access to the same motors for turning/spinning. So we added a drivetrain device with motors connected to ports 1 and 2, and wanted to add 4 motor devices on ports 1,2, 3, and 4. That doesn’t seem possible (ports 1 and 2 aren’t available), unless we’re overlooking something?
If indeed that is not possible and we have to pick one or the other, how much less accurate would
be versus
?
Actual distances would be typical for navigating around a 4’x8’ field.
Even if you set up the drivetrain, the distances won’t be correct because the wheels are not facing forward. Just control the motors individually.
When they implement “my blocks” you will be able to write functions that will make the process a lot easier.
1 Like
“X-drive” may not be a very accurate description, we got our inspiration from this pic:
I haven’t found the right term for this build, but we wanted to hook up the left and the right wheels to a drivetrain device, and have four motor devices on top of that.
Do you want all 4 motors to powering the robot at the same time? The picture you show is oriented to look like a tank drive with 2 strafing wheels on top and bottom. Which, would be going forwards, backwards, and left/right turns using left and right motors. And going side to side using the top/bottom motors. This would be your typical Tank Drive.
But, if you orient the base 45 degrees to the left or right, it would be an X Drive, where all 4 wheels are powered to allow it to move forwards, backwards, strafe, turns, etc.
If you have your robot set up as a Tank Drive, then you can use the Drivetrain setup, and the simpler “forward” command. You will just need to give separate commands to the strafe motor(s).
With an X drive, no, a Drive Train setup will not work. You will need an algorithm to move in any direction.
We’re not building a true X-drive, this team (the coach included) seriously lacks building/programming expertise.
Yes, we’d be using only two motors when going forwards/backwards, and side-to-side. For turning/spinning, however, wouldn’t we have to run all four to avoid unnecessary drag?
I imagine it could also move diagonally in driver skills if we program the controller right.
We previously used some of the drivetrain commands to program a squarebot, so I’m trying to figure out how much of that we could leverage with this setup, and how much accuracy we’d lose by programming each motor individually.
So, what you’re building is basically an H drive… motor to left wheel, motor to right wheel, and 1 motor to top or bottom wheel (other wheel is to help keep robot going in straight line). There’s no need for 4 motors when making an H-drive.
correct on the 2 motors going forwards/backwards. you will use the top/bottom motor to go side to side.
No, you can only use omni wheels in this type of setup. Omnis will have no drag.
You’re now talking about a true X-Drive, where the base and wheels are all oriented 45 degrees to left or right, and would require all 4 motors. Again, you will need to setup your controller in a certain way, and all movement is based on a formula.
You could pretty much reuse all of it. Only the strafe motor will be individually controlled. Even if you program your motors individually, you will not lose any accuracy.
Actually, the whole concept of the drivetrain commands is to make the programming simpler by reducing the number of commands needed on the students part. What is really happening is that your drivetrain command is interpreted and 2 individual commands are given to the robot for the left and right motors. So, it’s the same. Just that it’s simplified for the student to write.
1 Like
OK… 4 motors, left right front back…
Driver control…
This should do it… I think the two that I circled should be negative and you will have to reverse some of the motors.
In other words, this is the idea but you will have to fix the polarity of the motors.
2 Likes
I understand the polarity bit… but you got input from three different axes, and that I’m still trying to digest. I thought we’d have axis A control front to back (powering the left and the right motors equally), and axis C control left to right (powering the front and the back motor equally). That way the kids could even make it move diagonally if they wanted to. And turning/spinning would be controlled by one of the other buttons.
@sankeydd, so I’ve been running this code snippet in my head for an hour, and it’s starting to make sense, but then a different question popped up in my head: how do I explain this to a handful of 6-graders who have had exactly 2 hours of experience with Vex IQ, or even should I? Or would they be better off programming their bot to move like a rook on a chessboard, and spin it with E or F?
Oh I wouldn’t do that, no… If it is either going to move OR spin then that would simplify things…
This will be easier to explain to the kids, but a little messier when coded…
I tried uploading as a picture but it seems like the maximum height is 500 and won’t be very readable…
VEXcode Project.pdf (3.7 MB)
The main thing they have to watch out for is that only one thing is commanding the motors, which is why you have to waituntil the buttons are not being pushed before you go back to the driver control loop.
1 Like
Thank you, will give it a try tonight.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.