I made a 3 wheeled Omni wheel robot, but am having an issue with programming. The rear motor is slower than the other 2 and I cannot get it to go faster. I have slowed down the other 2 to fix it but would like to make it faster. Is there any way to make the motor full speed? I also am having an issue uploading .v5blocks files here from my Chromebook. Could anyone help me with these issues?
Just a few questions to help us help you (regarding the first issue):
- Is this IQ or V5?
- How are you programming your bot? Blocks or Code?
- Could you send us your code to look at?
It might be as simple as ensuring all your motor velocities are manually set to 100% at the start of your program. (Edit: it’s a driver control program + kiwi drive I see)
If you’re using V5, you can look in your devices menu and set your motors to spin separate from a program. This might help you isolate the issue if it is a faulty motor.
wheel1 = Xj + Zj
wheel2 = -Xj/2 +0.866Yj + Zj
wheel3 = -Xj/2 -0.866Yj + Zj
Where Xj is the X axis joystick, Yj is the Y axis joystick, Zj is the “rotation” joystick.
So you need to do some math on the values to get it right.
For any holonomic drive, you must combine three vectors X (side to side), Y (front to back) and W (turn) to determine the power needed at each motor. This can be done fairly simply for 4-wheel holonomic by adding and subtracting signal values from 3 axes of the controller. For 3 wheel holonomic, each motor needs to read the signal from the controller at different proportions.
There is a very thorough video explaining the math here: HOWTO Design a 3-Wheels Holonomic Robot: The Theory - YouTube
I wrote some robotC code for a 3-wheel holonomic bot for NbN season. It’s not blocks, so you will need to do some head scratching …
// calculate variables and increase result by fMod fL = (-.58 * vexRT[Ch3]) + (-.33 * vexRT[Ch4]) * fMod; // force for left motor based on matrix math video fR = (.58 * vexRT[Ch3]) + (-.33 * vexRT[Ch4]) * fMod; // force for right fB = .67 * vexRT[Ch4] * fMod; // force for back // turn component of holonomic motion. large dead zone allows use of Ch2 for fly wheel control. halve the signal to turn slowly turn = abs(vexRT[Ch1]) >= 60 ? vexRT[Ch1]/2 : 0; // motor output in ternary to provide a dead zone on controller (only signals over 15 result in motor value changes) motor[driveL] = abs(fL - turn) >= 15 ? fL - turn : 0 ; motor[driveR] = abs(fR - turn) >= 15 ? fR - turn : 0 ; motor[driveB] = abs(fB - turn) >= 15 ? fB - turn : 0 ;
The first bit shows the proportional signal value for each motor in finding power levels for X and Y vectors. I have multiplied them by fMod = 1.5. The proportions remain the same, but the total power value is increased.
Second bit is the W (turn) vector, which is the same proportion for all 3 wheels. It is written as a ternary and only accepts high turn values and reduces the weight of that signal (holonomic drives turn fast.) In plain language you can read that line as “If the signal from channel 1 is greater than 60, set the value of turn to 1/2 the value of channel one, if it is not set the value of turn to 0.”
The third bit is the motor command to spin the motors. Also a ternary to ignore low values to make a dead zone on the controller.
Also, adding to what @DougMoyers said, in my experience with kiwi drives, their performance depends on the weight-over-the-wheel distribution much more than it is for tank and x-drives.
For the best results you should experimentally offset the power going to each wheel by some constant value and then tweak the individual multiplier coefficients that depend on the weight distribution and corresponding friction in each wheel rollers/axles.
We used the method of directing robot to drive at certain fixed angle and then observing if it drives in a straight line or its path curves to one side or the other - then tweaking coefficients to make it drive straight. However, we couldn’t achieve perfect straight line for asymmetrical robot, so we just made it as good as it gets and spent time practice driving the way it is.
For a robot that is not perfectly symmetric and if there is a preferred direction of forward motion based on the gameplay, the trick might be to tweak the angle of the forward wheels to be more parallel, which will reduce friction losses in the rollers.
Edit: you may have more predictable results when, instead of target power you send target velocity commands to each motor as is in your example, but you will still need to tweak the individual scaling coefficients for each motor.
This is the Robot Mesh version of the code in Python. It’s for the VEXIQ version of the Kiwibot, so you can ignore the lights and stuff.
This is the code I have now. Do you think this will work? I don’t have access to my robot to test right now.
Pretty close, good job interpreting text to blocks. The abs assessments in my code were to filter out low numbers. You need to remove them from your code. Taking the absolute would turn negative signals into positive signals. You might also find that your bot turns opposite of what you expect based on how your motors are oriented. If so change
- turn into
edit: and as @technik3k points out, the .58, .33 and .67 are theoretical correct values based on a perfectly balance robot. You may want to adjust those values for each wheel based on observation.
thank you for helping
Works now with only a small amount of right turn. This is what my code looks like now.Screenshot 2022-05-04 3.48.09 PM|506x500
If you are still having problems with uploading from your chromebook, try another computer that is more up-to-date or with higher levels of cloud connection.