Robot code not showing up

[nimrod46]

The robot code not showing up randomly after deploying it since updating to 2017 lib.

Error: NT: ERROR: bind() to port 1735 failed: Address already in use (TCPAcceptor.cpp:108)
That error is showing up when this happends.
The only way to fix it is by restarting the roborio.

Right now this problem has been reported to happened in java and c++.
See thread: https://www.chiefdelphi.com/forums/showthread.php?t=153362

[mikearnold514]

Team 514 is having the same problem.

The offending line of code is the one getting the CameraServer instance and starting auto capture - VideoSource usbCamera = CameraServer.getInstance().startAutomaticCapture();

I was wondering if this issue is being assigned and planned for a release. Please let me know the status when you have a chance.

Kind Regards,
Mike

[mikearnold514]

Just following up to see if anyone had a resolution to this problem. My team is still experiencing the issue. Will be in the tech room tomorrow night. Was hoping to discuss this with someone to get some ideas on how best to troubleshoot.
Thanks!
Mike

[AustinShalit]

@mikearnold514 Can you please send me your code?

The issue you are seeing is that your robot code is unable to exit and is still listening on that port.

[mikearnold514]

Hey Austin! Thank you very much for getting back to me and I am sorry to bother you guys. I can just imagine how busy you all are supporting all the teams during the build season! Thanks again for taking the time to look at my issue. I will be going into the tech room tonight and have some ideas about how to troubleshoot this issue. If it is OK with you I will send you the code after the meeting tonight with a description of what we are doing, why and what results we got. Thanks again and wish us luck! Mike

…

On Tue, Jan 31, 2017 at 12:18 AM, Austin Shalit ***@***.***> wrote: @mikearnold514 <https://github.com/mikearnold514> Can you please send me your code? The issue you are seeing is that your robot code is unable to exit. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVaHrdpo7kTwDa5gUDka7FuwAy0fZ7Mzks5rXsQbgaJpZM4Lkgd2> .

-- Mike Arnold mikearnold514@gmail.com 631.662.7418

[AustinShalit]

Sounds good

[nightpool]

Should this be an open issue or can we close this?

[nimrod46]

@nightpool keep it open until it will be fixed so no one else will open a new issue

[mikearnold514]

If I can get this to work tonight I will carefully document it so we can close the issue and refer people to the process that resolved the issue. If I can't get this to work tonight, I will provide you all the details I can so we can take clear actionable next steps. I hope this approach is OK with everyone.

…

On Tue, Jan 31, 2017 at 3:05 PM, nimrod46 ***@***.***> wrote: @nightpool <https://github.com/nightpool> keep it open until it will be fixed so no one else will open a new issue — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVaHrZRF-MxqUvEvr4_1SwNQ3mpbcXSNks5rX5P9gaJpZM4Lkgd2> .

-- Mike Arnold mikearnold514@gmail.com 631.662.7418

[nightpool]

@nimrod46 I'm not sure I understand what the issue is here from WPILib's perspective, sorry. The issue that you're seeing is just a symptom of your robot code isn't exiting—which isn't something WPILib can control.

[mikearnold514]

I totally understand your perspective and position on this. You are focused on working on real issues and resolving them. Although this very well may be an issue with my team's code, I am requesting assistance in resolving this. Perhaps this isn't something that should be handled in GitHub as an issue but rather Chief Delphi or some other forum. I am fine with whatever you want to do as long as the issue we are experiencing (regardless of root cause) is supported thru resolution. I very much appreciate you all responding and your willingness to help. Kind Regards, Mike

…

On Tue, Jan 31, 2017 at 3:31 PM, nightpool ***@***.***> wrote: @nimrod46 <https://github.com/nimrod46> I'm not sure I understand what the issue is here from WPILib's perspective, sorry. The issue that you're seeing is just a symptom of your robot code isn't exiting—which isn't something WPILib can control. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVaHrbg2RnyL0RSIn-6Yn7Cw6IjL1KHlks5rX5oagaJpZM4Lkgd2> .

-- Mike Arnold mikearnold514@gmail.com 631.662.7418

[nimrod46]

@AustinShalit @nightpool
I think this problem should be solved, even if a tcp server is listening on this port you should shut it down.
I mean you can't leave it as it is because this is will be a problem during matches.
This is my opinion

[mikearnold514]

Hey guys, good news bad news story which I guess is to be expected. So we got past the error, that is the good news. The bad news is we are not getting any meaningful values from our vision pipeline. More on that later. So the short answer is that I 'think' we can close this issue. What we did wrong was to have the CameraServer.getInstance.startAutomaticCapture(); instruction in our VisionUtil subsystem class constructor. We normally do this for other things like motors and sensors in a subsystem. But for this singleton I guess it is a problem. So in the RobotInit() method we now call Robot.visionUtil.startVisionProcessing() and it is in this method that we execute everything to get the CameraServer capture working, instantiate the VIsionPipeline and start the VisionThread. All good! Our intention is to adhere to the CommandBasedRobot framework and have Vision as a subsystem and then use Commands to call the methods we expose in the subsystem to get data on the image, the objects in the image and drive the motors accordingly. You will see this in the project I attached. It is just vision, no motors or anything added. We are just trying to process the data from the Pipeline to see what we get and how best we can use it to our goals and objectives. So my ask is if you can take a look at this and let me know where we are going wrong with our coding syntax or coding approach. We are no experts and will welcome any advice you can give! Finally, I would agree that this issue can be closed. However, I do ask that we keep this discussion going until we can get valid data from our pipeline. If you want to do that in email (gmail) or in Chief Delphi or some other way I am fine but would appreciate greatly a little more support as we go along here. Thanks again and sorry about the tome! Kind Regards. Mike

…

On Tue, Jan 31, 2017 at 4:22 PM, nimrod46 ***@***.***> wrote: @AustinShalit <https://github.com/AustinShalit> @nightpool <https://github.com/nightpool> I think this problem should be solved, even if a tcp server is listening on this port you should shut it down. I mean you can't leave it as it is because this is will be a problem during matches. This is my opinion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVaHrTG0l1bTh8gkWyLrz_tLdRp5Qf43ks5rX6YOgaJpZM4Lkgd2> .

-- Mike Arnold mikearnold514@gmail.com 631.662.7418

[mikearnold514]

Seems the source code did not upload when I attached it to the email. Here it is for your review. Thank you!
FRC2017Test.zip

[mikearnold514]

I will leave it up to the person who opened this issue but from what I can tell, this issue can be closed.

Austin, if you have had a chance to look at the code I sent you, I would welcome your feedback.

Kind Regards,
Mike Arnold, Team 514

[AustinShalit]

I just took a look. You will not notice any SmartDashboard updates while the DriverStation is not connected. disabledPeriodic only runs when the robot has a connection to the DriverStation.

Vision is not something that works well right now in the command based format. I would recommend removing the ProcessImages command. The VisionThread (line 57 of VisionUtil) will automatically call copyPipelineOutputs every time it has finished running the pipeline. You can take a look at how that works here.

It looks like you are not using the visionLock right now. I would read this article by Oracle. It explains what the synchronized block does and how to use it. Let me know if you have trouble.

[mikearnold514]

Hey Austin - I will read up and make the changes you recommend when I am with the students in the tech room tonight at our meeting. I will update you as to our progress if that is OK with you. Thanks again for the help! Really appreciate it! Kind Regards, Mike

…

On Thu, Feb 2, 2017 at 11:45 AM, Austin Shalit ***@***.***> wrote: I just took a look. You will not notice any SmartDashboard updates while the DriverStation is not connected. disabledPeriodic only runs when the robot has a connection to the DriverStation. Vision is not something that works well right now in the command based format. I would recommend removing the ProcessImages command. The VisionThread (line 57 of VisionUtil), will automatically call copyPipelineOutputs every time it has finished running the pipeline. You can take a look at how that works here <https://github.com/wpilibsuite/allwpilib/blob/master/wpilibj/src/athena/java/edu/wpi/first/wpilibj/vision/VisionRunner.java> . It looks like you are not using the visionLock right now. I would read this article <http://docs.oracle.com/javase/tutorial/essential/concurrency/> by Oracle. It explains what the synchronized block does and how to use it. Let me know if you have trouble. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVaHrXl87ynXB7AipM29OshEb7N5ueMJks5rYghFgaJpZM4Lkgd2> .

-- Mike Arnold mikearnold514@gmail.com 631.662.7418

[mikearnold514]

Hey Austin - If I am reading and understanding things correctly, I do have the copyPipelineOutputs method in the VisionUtil() class synchronized on an object called visionLock. However, based on what I read, I think the subsequent getter methods in the VisionUtil() class would each also have to be synchronized on the same visionLock object. Let me know if you think I am tracking correctly and I will try this out tonight. Thanks again! On Thu, Feb 2, 2017 at 12:13 PM, Mike Arnold <mikearnold514@gmail.com> wrote:

…

Hey Austin - I will read up and make the changes you recommend when I am with the students in the tech room tonight at our meeting. I will update you as to our progress if that is OK with you. Thanks again for the help! Really appreciate it! Kind Regards, Mike On Thu, Feb 2, 2017 at 11:45 AM, Austin Shalit ***@***.***> wrote: > I just took a look. You will not notice any SmartDashboard updates while > the DriverStation is not connected. disabledPeriodic only runs when the > robot has a connection to the DriverStation. > > Vision is not something that works well right now in the command based > format. I would recommend removing the ProcessImages command. The > VisionThread (line 57 of VisionUtil), will automatically call > copyPipelineOutputs every time it has finished running the pipeline. You > can take a look at how that works here > <https://github.com/wpilibsuite/allwpilib/blob/master/wpilibj/src/athena/java/edu/wpi/first/wpilibj/vision/VisionRunner.java> > . > > It looks like you are not using the visionLock right now. I would read this > article <http://docs.oracle.com/javase/tutorial/essential/concurrency/> > by Oracle. It explains what the synchronized block does and how to use it. > Let me know if you have trouble. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#465 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AVaHrXl87ynXB7AipM29OshEb7N5ueMJks5rYghFgaJpZM4Lkgd2> > . > -- Mike Arnold ***@***.*** 631.662.7418 <(631)%20662-7418>

-- Mike Arnold mikearnold514@gmail.com 631.662.7418

[SamCarlberg]

copyPipelineOutputs method in the VisionUtil() class synchronized on an
object called visionLock. However, based on what I read, I think the
subsequent getter methods in the VisionUtil() class would each also have to
be synchronized on the same visionLock object.

It's a bit more involved than that. All reads should be in a single synchronized block, and all writes should be in another. If not, one thread can read a variable, then the vision thread would update all of them, and the first thread would then have data from multiple runs of the pipeline, making the data useless.

[mikearnold514]

Hey Sam - I have to agree with you based on our testing last night. I am thinking that, to keep it simple and not waste too much time, we would just use Iterative Robot this year and abandon the CommandBasedRobot. I am pretty sure we can get done what we have to with this pragmatic step. What do you think? Drop back and punt or keep fighting CommandBased? Thanks again for all your support! I can't thank you all enough! Mike Arnold, Team 514

…

On Thu, Feb 2, 2017 at 7:59 PM, Sam Carlberg ***@***.***> wrote: copyPipelineOutputs method in the VisionUtil() class synchronized on an object called visionLock. However, based on what I read, I think the subsequent getter methods in the VisionUtil() class would each also have to be synchronized on the same visionLock object. It's a bit more involved than that. *All* reads should be in a single synchronized block, and *all* writes should be in another. If not, one thread can read a variable, then the vision thread would update all of them, and the first thread would then have data from multiple runs of the pipeline, making the data useless. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVaHrT25kjExJ97p4ffngQt9g3NdR6C3ks5rYnvtgaJpZM4Lkgd2> .

-- Mike Arnold mikearnold514@gmail.com 631.662.7418

[SamCarlberg]

You could store all the extracted data in a single value object and expose that synchronously.

public final class VisionData {
  private final double angleToGearPeg;
  ...
}

and then in VisionUtil, you'd have something like

@Override
public void copyPipelineOutputs(VisionProcessingPipeline pipeline) {
  synchronized (visionLock) {
    this.visionData = new VisionData(pipeline.calcAngleToGearPeg(), ...);
  }
}

public VisionData getVisionData() {
  synchronized (visionLock) {
    return visionData;
  }
}

[AustinShalit]

I would continue to use CommandBasedRobot for everything except vision.

[mikearnold514]

Hey Sam/Austin -
So you have given some great guidance and now I have a number of things to try out! Good thing our Saturday meeting is all day long! hehe...

I will update you on our testing. I am feeling confident that we can get something going from among the options you guys have mapped out for us! Can't thank you enough!
Kind Regards,
Mike