Talking to RoboRIO and Enabling Teleop over Ethernet from a Jetson TX1

Technical Programming
#1

Hello Everyone!

I hope you’re all having a great season. I think I should just explain what I’m trying to do and maybe you guys can point me in the right direction. I am using a RoboRIO with LabVIEW on it and an Nvidia Jetson TX1. What I want to be able to do is allow the Jetson TX1 to send to the RoboRIO information (like a string or something) over the Ethernet connection. That’s problem number one, if I’m using LabVIEW how do I get the Jetson to send something to the RoboRIO.

The second problem is, for testing purposes, I want the Jetson TX1 to be able to enable teleop mode on the RoboRIO, is there anyway to “mock” the Driver station “enable teleop” signal or “enable autonomous signal” over this ethernet connection. Please help! I’m very new to this!

Take Care,
Adi

#2

For your first question, you will want to use NetworkTables. That said I am not sure how to set them up for LabView, hopefully another community member can help there or the documentation has more details on that.

For your second question, no you can’t do that. Why do you want to do that? If you are looking to simulate a match you can use the practice mode in the drive station to have a delayed auto start and then have it switch to teleop at the right time.

#3

Well the reason we wanted to have the Jetson TX1 send the enable signal to the rio was for bench testing NOT for the competition. We wanted to make a test bot where we could do all the HMI through the Jetson board itself instead of relying on the FRC Driver Station - it really isn’t possible to enable the robot in any way other than FRC DS?

Ok on the network tables I will check them out, hopefully someone else can help me with the LabVIEW!

#4

While it’s technically possible, please consider different ways to do the testing you want to do. For example, simulating your robot code on the desktop instead of on a real Rio. The DS provides safety controls and it’s not a good idea to bypass them.

#5

Technically you can use Qdriverstation, an open source third party driverstation clone, and run it on the jetson. You can use Qdriverstations internal libraries in your own code on the jetson and enable it that way. However, i strongly recommend against it, not only for safety, but also because this is not something i think a team using labview should be doing. If you have the skills to write this code for the jetson, i strongly reccomend you switch to java or c++ next year (not mid-season obviously)

#6

Programming your robot in LabVIEW and then using one of the languages that works on the Jetson (not LabVIEW, so far as I know), will work well. Use networktables for your communication.

If you’re programming your robot in LabVIEW, you have a computer sitting there that can easily run the driver station.

#7

Stop this.

#8

Sorry if I came off as offensive, I just mean that messing with low level apis while ur still very dependent on using high level apis can be risky. I don’t mean they shouldn’t use the jetson, just maybe not enable the robot with it

#9

You can use the NetworkTable VIs that are included with the FRC Framework. You can find them in the functions palette under WPI Robotics Library > Dashboard

image

If you require lower level APIs, you can also explore the functions in Data Communication > Protocols.

If you were to develop a script or text-based functions, you can also call them from LabVIEW using the functions in Connectivity > Libraries & Executables.

#10

I’ve seen people talk about sim on the desktop for a while yet I haven’t come across any resources to talk about it, do you have a link to a guide?

#11

https://docs.wpilib.org/en/latest/docs/software/wpilib-tools/robot-simulation/introduction.html

1 Like
#12

I’m guessing the following was more the intent of the initial comment:

Which is a defensible technical opinion (though there are those would would certainly disagree).

As @oscarfonloz pointed out, Network Tables and multiple “lower level” protocols are exposed on the user-side of Labview. All of these could be options.

If the software requirements push beyond the boundaries of what’s exposed (as was possibly indicated above), then you’re looking at something more customized. Whether that’s asking NI to add functionality to Labview, extending Labview’s functionality yourself, or writing an external program which gets called from a Labview environment, any could work… it’s more a question of what the team’s expertise and timelines allow for.

Granted, with what OP’s provided, I can’t see why network tables wouldn’t work for the first problem.

To the second problem:

OP - consider the following: Can you have a development computer which remote-connects (GUI+desktop/ssh/ftp/etc.) to the Jetson and simultaneously has a driver station up? This would help ensure your test environment accurately represents the “production” robot environment.

As a side note - in Java/C++/Python, there is a disabledPeriodic() function that gets called every 20ms during disabled. I’m assuming a similar structure is mirrored for the Labview side? If so, this may be an option to have the roboRIO receive data and prove some functionality without being enabled.

#13

The disabled structure is mirrored in LabVIEW.

1 Like
#14

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.