I been testing vex code in easyC the software my daughter’s team is using. I volunteered to help teach the kids different coding skills they can use to make more reliable and functional robots. I built a test bench for the kids and I to test ideas. I have been testing PID using the IME’s. I found I had to reverse the motor wires RED>>BLACK on both motors that are currently connected to Motor Ports 2 & 3 using the MC-29’s and IME’s 1 and 2 respectively. Is this an expected requirement. I have searched around the forums on how to reverse the encoder direction or polarity with results leading me to believe this is not possible.
You can not electronically reverse the encoder direction. That is, you cannot flip wires to get the encoder to start counting positive in the other direction. If you need to flip the polarity, you can effectively do this in software by multiplying the IME value you get by -1.
I have seen reference to flipping the counts by multiplying by -1 and would be a solution if I was atempting to drive a logical encoder count.
Seems wrong to me that the Motor and IME system is designed out of the box backwards to each-other. I can not flip the encoder feed back because I’m simply using the PID Control listed in the IME functions folder and not witting my own PID function. Seem to use this block you either need to wire the motors to satisfy the error correction direction. Or maybe in the INITINTEGRATEDMOTORENCODERS() block we need an optional variable to flip the direction. Or even better on the Controller Configuration screen an option to flip the motor or IME direction. Similar to the DIO where we tell the program if the ports a Input or Output.
I don’t like the idea that I have to flip the wires. I like matching colors.
The real problem was if the current encoder value = 0 and I update the target to 300 clicks the motor spun in a negative direction when wired RED>>RED
It really just depends upon how you look at it. In the case of motors on each side of a drivetrain, one will always be opposite. Same is true for paired motors on lifts, etc… The only time it is a problem is if you have one motor doing one thing and you don’t like the default direction, but that depends upon what orientation you put the motor on the thing that you are driving.
I understand the paired motors that if on a drivetrain I command to go 3000 clicks that one motor will need to be commanded +3000 the other will have to be commanded -3000. That can be easily corrected in software. The point I found that if wired RED >> RED the motor spins away from the target and will never stop.
Hello my team is trying to get PID to work for EasyC but we cannot firgure it out since we havent really done anything like this in coding before, can you pm me your code please?
I sent you the Code but for others here it is. Its not secretive. Its a modification of the sample code PID Control with Joystick Digital Buttons. My code removed the Joystick and replaced with Digital buttons as my test bench has. This way I can Print diagnostics data to the terminal window.
My PID Control with Digital Buttons.zip (3.47 KB)
I wouldn’t suggest commanding one + and one - when running positioning PID. That will be far more confusing than either swapping Red/Black. Especially as you get into PID controlling 10+ motors on lifts and things. There is no polarity on a brushed DC motor, it just needs to be consistent.
The fact that the motor spins away from your target is only because of the side of the shaft you put the motor on. If you put it on the other side it would have been “correct” for you.
It’s all relative, there is no right/wrong.
For RobotC, we have the ability to mark the motor as +/- in the hardware setup, not sure if you can in EasyC. It drives the polarity at the lowest level when the function that send power to the motor is called. This allows RED>>RED on the wiring and keeps the correct polarity invisible to the kids as they program. Makes it a bit easier.
The IME is on the motor. There is no other side
My point exactly. RED>>RED makes it simpler.
What I think is happening is I personally would enjoy ROBOTC as I’m Sure its more flexible and powerful. The EasyC function blocks I assume are created to get new students started and when they need more complex functions to move on to ROBOTC. With the team I’m associated that is a first year team, and before I started helping was using the default joystick to cortex mappings. EasyC is a first step. When the kids start to ask what is happening in the back grown we can open the C-code tab. I have also made a simple user function that depicts what is happening in side the EasyC block “Tank2 - with Joystick”.
With that said I would hope that when using the caned function blocks in easyC V4 like that under the Integrated Motor Encoders folder that the connections of the devices under control be connected in a arguably correct manner ie. RED>>RED, BLACK>>BLACK, GROUND>>GROUND, A>>A, B>>B