My team is currently building a new robot from scratch for our next competition.
Once we started programming the base and the lift, everything went well. Two days later, the base wheels twitched or didn’t move at all when we used the controllers.
When we used the online window to check the error, the wheels moved just fine. After we switched some of the motor ports, the base worked fine.
Later on, we built the intake and we had the same issue we had with the base, but on two ports that hadn’t been used by either the base or the lift. Any help here?
By controllers, do you mean the handheld controllers, or the Motor Controller 29s you plug in the motors with?
Have you checked that your wiring is fine and that there isn’t excess friction in the systems? If the motors move fine for a short time and then stall and twitch, it is most likely because the PTC thermal fuses in the Cortex or motor are tripping.
How exactly do the motors “twitch”? Is it random, after some time of running it, or is always the same when you move the joystick? Perhaps a video would make it easier to understand what you mean.
Edit: As described above, your program might also be causing this. Not sure why changing ports would have fixed it in that case, but it would help if you can post your code.
I mean the handheld controlers. I did check the wiring of the Cortex and its set up like its supposed to. I also checked the cables to see if there were damages, but there weren’t any.
The twiching is random. I searched my code for anything that might have caused this, and I found two controlers that were activated with the same jumper setting, but I fixed it. Some of the twitching went away, but it still persists.
There is one controller that still isn’t working, that works with buttons only. All the others work well as of now. 2252D.zip (5.83 KB)
Since you posted the code, it is possible to help.
tl/dr;
There are still multiple Driver and Autonomous sections that are activated by the same jumper settings.
Details:
OperatorControl: looks like this pseudo code
while(1){
get jumpers;
if (J6==0){DriverA}
if (J6==1){DriverB}
if (J6==1 && J7==0){DriverC)
...}// #wend
Example Driver code looks like this (no while loop);
Arcade4(); Tank4(); ...
An example of the problem is that when J6=1 and J7=0, both DriverB and DriverC routines are called. I assume you only want one driver active at a time. Autonomous jumper decoding has the same ‘feature’, where J1+J2 will execute both Auto1+Auto2 in sequence, and possibly other stuff too.
You can avoid this problem by checking state of ALL jumpers before doing any specific thing.
I would have coded it like this to achieve similar goals, since it is clean, and the switch/case/break syntax shows you mean to make only one choice per while loop
Jumper = j0+j1*2+j3*4+j4*8; // Jumper is now a number from 0..15, and i assume it does not need to change during the match
while(1){
switch(Jumper){
case 1: { DriverA; break;}
case 2: {DriverB; break;}
...} // end switch See example code in Help page for switch/case
} // end while
Its not as clean, and more prone to errors, but if you are uncomfortable with switch/case, you can just fully encode all your if statements.
Using ‘Continue’, shows that you mean to do just one thing, then go back to while;
getJumpers; // no point in getting these inside the while loop, right?
while(1){
if (Jumper6==0 && Jumper7==0 && Jumper8==0) { DriverA; Continue;}
if (Jumper6==0 && Jumper7==0 && Jumper8==1) { DriverB; Continue;}
if (Jumper6==0 && Jumper7==1 && Jumper8==0) { DriverC; Continue;}
if (Jumper6==0 && Jumper7==1 && Jumper8==1) { DriverD; Continue;}
if (Jumper6==1 && Jumper7==0 && Jumper8==0) { DriverE; Continue;}
if (Jumper6==1 && Jumper7==0 && Jumper8==1) { DriverF; Continue;}
if (Jumper6==1 && Jumper7==1 && Jumper8==0) { DriverG; Continue;}
if (Jumper6==1 && Jumper7==1 && Jumper8==1) { DriverH; Continue;}
// never gets here. or remove last If and leave this as otherwise default
} // wend
If twitching still exists after this, it should be local to one (or more) of the Driver routines, and should be easier to find there. One of the way to make it easier to find, is to make Global constants M1=1, … M10=10, and then using M# instead of just # in all the EasyC calls to Arcarde(), etc. That way it is easier to see the Motor numbers in the mix of all the other numbers.