Hey everyone. I am working on some programming with middle school students (Clawbot IQ), but we are having a problem with one of the robots turning quite a bit when trying to drive a straight line. They all veer slightly, but this one is pretty severe. I’ve checked for stability of the frame and sources of friction (that might be making the robot veer to the left) and have also swapped motors. Finally, I tried changing the motor speed in the device menu on the brain, but the adjustments I make are temporary and do not save. I reached out to support, but they also referred me here. Does anyone have any other ideas? Thanks in advance!
Hi. There are a lot of factors that can cause this from mechanical to programming. Is this teleop or autonomous? Are you using omni wheels? Can you post your code and some pictures of the robot?
I just had the students write a quick forward motion code for this. You can see that it veered a few inches to the left over about 6 feet of movement. We see the same thing with longer code, also, but we wanted to eliminate some of the other variables. We’ve tried dropping the speed, as well, but that doesn’t seem to help.
Sorry, I can only post one pic at a time since I’m a new user.
Probably a silly question, but I am assuming you are using the edges of the tiles to determine “straight”? If so, are you sure the tiles are square to the door frame? They appear to be, but could be moving off. Also, another probably silly question, is the floor level?
This level of error will almost always happen unless you write your own error correcting code. To give you an idea, 3 inches over 6 feet is only an error of ~2.4 degrees. When giving a motor a position or speed target, its own internal logic handles the details of achieving that speed or position, and it will do it as quickly as your program and physics allows. Because the motors aren’t exactly identical, one motor will always reach its target speed a little faster than the other motor, even if their allowed top speeds are the same.
To combat this, your code would have to look for those differences in acceleration in real time. Usually this is done by comparing the elapsed distance for each motor, and then slightly adjusting the speeds if they aren’t within an acceptable margin of error.
This can also be combined with acceleration control: limiting how fast the motors ramp up to cruising speed. After setting a distance target and speed limit for your algorithm, you then pick some initial speed that the motors should get to on their way to the speed limit. Your code then does error correction until the motors reach that initial speed target or some amount of time has elapsed, then you increase the speed target if it was below the speed limit. (It also works on the other end of a run for coming to a stop, but IQ robots are usually quite good at stopping on a dime so it makes less of a difference there.) You keep repeating this process of incremental speed increases while correcting for error until the desired distance is covered.
If you code all this up and it doesn’t work, then it’s probably something silly like the wheels not being close enough to the same diameter or something like that.
1 Like
Thanks for posting the code and pictures. As John mentioned, this is a mechanical problem. There’s nothing causing this in code.
As you mentioned all of the robots veer, and this is normal since there is always some play with spacers and collars. There’s nothing mechanically that will eliminate it 100%… but here are some suggestions to keep it under control based what our team has done. The idea is to eliminate as much play as possible, and have a rigid frame. Others may have more suggestions
-
Place the wheels between two beams with a single shaft going through the beams and wheel to the motor.
-
Avoid using shaft bushing to couple 2 shafts together. Use a single shaft only.
-
Fill the space between the wheel and the inner beam (where the motor is mounted) with spacers that way there’s no movement towards the center, but allows the wheel to still spin freely.
-
Put collars between the wheel and the outer beam. One next to the wheel and one on the inside of the outer beam. This will lock the shaft from having any play in either direction, and from moving out and getting dislodged from the motor housing.
-
Use corner or offset connectors to connect the outer and inner beams. This will square up the beam together and make the wheels level and the frame square and rigid. Next, connect the left and right wheels beams with perpendicular beams (at least 1 in the back). Use corner connectors. Without doing this you’ll notice the wheels sag due to the weight of the robot .
Motors are tougher to deal with as no two motors are exactly alike. You should try to find 2 motors that have same amount of power, but to do this you may want to look into building a motor dyno. Use the search feature… there have been some posts of that.
1 Like
Not a silly question, but it is square, as far as I can tell. In terms of the level floor, it probably isn’t. I don’t have a level, but I’m in a classroom made of 3 separate portables. That said, I see similar movement in different directions.
Thank you for all of the suggestions, everyone! I truly appreciate it.
1 Like
We are having a similar issue. If we place the robot on a smooth flat surface and drive forward, it will drift to the left, increasingly so until it is doing donuts. We are using tank control on the joystick.
That sounds like an entirely different issue. Your description makes it seem like there is excess drag on your left motor that is causing it to overheat and shutdown for thermal protection.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.