So I just started to mess around with WindRiver on an old robot outfitted with a cRio and the who 2009 electronics equipment, when I ran into a couple of issues… here are some of the questions which arose:
Whenever I changed the “SimpleRobot” code, I right clicked on the program name in the explorer windom, and clicked “build”… then I clicked on First–>download… is this the correct way to upload code to the cRio or is there a better/proper way, or what?
Because of (possibly) some weird wiring issues, it took me some time to finally get the robot to respond to the joystick, as it should in “SimpleRobot”… but, as it turned out… the x and y axis were backwards… I have looked everywhere and tried a lot of things in the code to fix this issue, but came to no change… can someone please tell me exactly how to change the x and y axis control when it comes to the “SimpleRobot” program in WindRiver?
I am sure more questions will arise from me soon enough, as I am completely new to WindRiver, which makes me absolutely oblivious, besides what I can actually piece together from my knowledge of other C++ libraries… But yea, if someone could help me out that would be great, and would be appreciated tremendously…
This is with single-joystick “arcade” style control? You are probably misinterpreting the problem. I suspect that the axes are correct, and the motor wiring is merely “backwards” on one side. If that’s the situation, pushing the joystick forward or backward will make one side of the robot go forward and the other go backward, spinning the robot and making it act like a correctly-wired robot with the joystick pushed to the side. Pushing the joystick to the side will make both motors go in the same direction, emulating correct wiring with the joystick pushed forward or backward.
The appropriate fix is either to swap the wiring on the “backwards” motor, or to tell the software that the motor control on one side or the other needs to be inverted. The software fix is applied when you instantiate the arcade drive.
I am guessing you are talking about the leads going directly to the motor (from the jaguar) being backward… well that does make sense, so I can check… but wow thats really pathetic that this issue on the robot has gone unnoticed for about 2 years now… hopefully ure right
Some people prefer to keep the motor wiring consistent (e.g. positive polarity yields clockwise rotation) rather than make the speed controller values consistent (e.g. higher numbers yield faster forward travel). I’m sure the software running that robot in the past properly accounted for the need to reverse that motor’s control.
The WPI library has a place to say “please invert this motor” in the drivetrain definition. That’s probably all you need to do.
to build,(make sure you have a Remot esystem connection, look in C:\Windriver\docs\frc\C programming guide for frc.pdf for details) right click project (dont need to build)> Run kernel task and the entry point is FRC_UserProgram_StartupLibraryInit then hit Run. It will download, and run. Reboot to stop debugging and get rid of the file on the crio
also, the joystick Y (forward and back) forward is negative, back is positive
I have just spend 2 hours looking through the code and the manual(s) and still have no idea how to invert the motors… exactly in which file should I look?
If you don’t see the file byteit101 pointed to, try http://first.wpi.edu/Images/CMS/First/C_CPP_Programming_Guide.pdf online. Look at the RobotDrive class, specifically its SetInvertedMotor() method. I found it in about three seconds by searching for the text “invert”.
