I have a simple drive train robot and it seems to have an issue I cannot find. The latency between the joysticks and the robot is very bad and same with the cameras. I am using 4 victors and 4 cims for drive and use java and command based programming and the default open mesh radio. When I drive voltage drops to about 11.4 and stutters a bit. The only thing on this robot is just drive. I believe my programming is correct so I do not think it is that. I’m also using a raspberry pi to get the camera stream using pi vision.
dropping 1 volt while driving is not uncommon. Batteries tend to drop voltage when a lot of current is being supplied. As for your stuttering: you said your programming is correct. I’m going to assume you are right. I would make sure that the motors that are paired together are going in the same direction and they are not fighting each other.
1 Like
I’m hoping it isn’t that. Personally I’m not sure how to test for that as mechanical built the base and I just did the electrical. Is there a way I can test that? Should I use the shuffleboard and just see where the motors are going? If you’d like, I’ll upload the subsystem.
If it has two motors on each side of the robot, disconnect one of the wires between the speed controller, and one of the motors, on each side of the robot, and see what it does.
If you can post video of the robot driving, it will help immensely with our ability to help you troubleshoot your issues.
Absolutely, I will test all of that when I am able to get to the shop. Currently in class until 3 so will have to test that later.
checking for motor direction is pretty easy: put the robot on blocks so the wheels aren’t touching the ground and disconnect one of the paired motors (removing power or signal will do it) then run the robot forward and note the direction the wheels turn. Reconnect the disabled motor and disconnect the motor you just tested. Drive the robot forward and note the wheel’s direction of rotation. Do this for all 4 motors. If you notice they are all not going in the same direction, you will need to adjust polarity physically or in code.
Thanks! As for the camera latency and all responsiveness have you got any clue why that could be happening? I have never been able to get cameras working well…
The first place I would look, is the setup of the driver station laptop computer. Internet, firewall, USB, power saving settings, etc.
Also, if you post your code, you can get verification that it is not a coding issue…from folks here who are knowledgeable about such stuff. That is not me.
Firewall is always turned off on our driver station laptops as we have discovered long ago that was an issue. As for the code I’ll try and separate it because my mentor wanted me to compile it to one big repository so there is code everywhere. I’ll separate it now.
I know I’ve had issues with Windows power saving settings causing lag…I suggest you do a bit more research on the subject of setting up the computer to make sure it’s not the source of the problem.
Robots are complicated systems, you have to go through the whole thing systematically to find the sources of problems.
it could also be the amount of data you are sending via the camera. what resolution and FPS are you using?
1 Like
For the camera, we keep it low at 176x144@30fps
Is the laptop the “driver station” laptop, in other words, does it have anything that is not the Driver Station app on it? Having anything else actively running (LabView, VS Code, whathaveyou) can cause issues. What does the CPU bar look like on the DS (on the first tab to the left of the battery voltage indicator).
I’ve uploaded the code to a new repository. If you’d like to check it over because they may be something wrong as I was never taught properly.
I’ve been using my predator laptop for code, and driver station during testing. In competition we have separate laptops of generally good processing power. CPU bar is usually low and there as well as in task manager usually hangs around 10-15% usage. When driving all that’s open is VSCode, ShuffleBoard and the Driver Station.
Are you sure that is the exact code you have loaded on the robot? It appears that the OI class should not compile without errors. Lines 10 and 14 reference the Joystick class when they should be referencing the stickL and stickR Joystick instances.
Otherwise, the code looks fine at first glance.
Steve
1 Like
What exactly should I be referring to instead of just creating a method that returns the joysticks Y value? From what I’ve learned from Java that is what I should do.
The concept of a method in OI to get the value is fine. The issue is, for example, line 10 is:
return Joystick.getY();
But should be:
return stickL.getY();
There is a similar issue on line 14 of OI.
Steve
I agree, OI shouldn’t compile.
@djp0915 perhaps you’re running old code on the robot, as when you deploy, this code shouldn’t end up on the robot.