Forward on controller doesn't work

edit: Nevermind, I’m an idiot. Sorry to waste your time! I didn’t think the program required everything to be set just right to drive around - including the gyro, which I didn’t have on.

Another problem.

On Driver Control, everything else works except forward on both sticks. It will occasionally jerk forwards, and the timing is the same for both motors. I have the controller tethered, tried multiple times to recalibrate (even trying to purposefully calibrate one stick differently), tried multiple times to reinstall firmware for the brain, controller and all motors. I’ve also made sure the cables are connected properly. Going backwards works perfectly. If I program it to go forwards, it works fine. Using tankControl in RobotC Graphical also works great, so I guess it’s not a big deal, but would be nice to have it fixed anyways.

Thanks for any help

I’m experiencing this same problem. I’ve verified all sensors are plugged into the correct ports. I’ve also tried disconnecting the gyro for Driver Control. The only way I can gain the ability to move the robot forward is by disconnecting the speaker (port 7) and rebooting. When the speaker is unplugged, moving forward with Driver Control is restored. Any ideas?

Hi jhenline,

We’re sorry that you have encountered this issue.

The built-in Driver Control program contains sample behaviors to demonstrate a potential use for each of the sensors included in the Super Kit. The Color Sensor (if it sees red), the Touch LED (if it is red), the Distance Sensor (if it sees an object too close), and the Gyro Sensor (if the robot is not pointing in the same direction as when it was turned on) will override the commands from the Controller.

If you wish to directly drive the Clawbot IQ from your Controller, and do not wish for any of these sample sensor behaviors to override the Controller commands in the Driver Control program, you simply can unplug these four sensors. This disables the advanced sensor demonstration part of the Driver Control program, but allows you to continue driving your robot with the Controller.

You can read more about the sample behaviors of the sensors in the Driver Control program in Section 6.1 of the Control System User Guide.


  • Art

I just realized what jhenline is talking about… the ultrasonic sensor/distance sensor/“Speaker”

As Art said, the distance sensor will prevent the robot from driving forward, if it detect something is in front of it. Unplugging will solve that (as you’ve discovered)


Ah, that makes sense. I’m a total noob over here, first time playing with VexIQ. (Note to self, just because something looks like a speaker…)

It kind of is a speaker in a way. However, the sound is ultrasonic and can’t be heard. It emits an ultrasonic pulse and times how long it takes to hear the echo (when the sound bounces off an object). From this information, it can work out how far it is from the object.

I’d like to express that I still think this DriverControls behavior is unfortunate. Many (I’d venture to say most) elementary-school teams use the built-in Driver Controls in matches, even for custom robots, and this added behaviour is confusing for them (there is also the “arm-stop button” behaviour that prevents further motion of one motor if given button is pressed).
Sure, they don’t need to populate such sensors, but they still do for the programming challenge and have only one robot per event. That means a lot of unplugging throughout the day.
You may argue that when they program, they could as well write their own remote control program, but there is still quite some difference between simple imperative do-this-then-that (good enough to score some points in a local event) and a real, reliable interactive teleop.

My elementary team last year had a constant struggle between the “drivers” and the “programmers”, where “drivers” sometimes forgot to disconnect the gyro.

Can we get a real Driver Controls and a separate demo?

Hi nenik,

Thank you for this feedback. We agree that this sensor behavior in the Driver Control program can be confusing, and we are exploring potential methods to solve this issue.


  • Art