We’ve decided to use a raspberry pi for some side processing on our robot this year. We’ve got all the code in python on the Raspberry Pi done now all we have to do is get it to the roboRIO somehow. We’ve been playing with the I2C bus port off of the roboRIO’s mxp port and running i2cdetect on the Pi comes up with an address of 32 for the roboRIO. Awesome. That’s the address we can send data to, from the Pi. Receiving the data on the end of the roboRIO is the difficult part. The I2C library for Java requires a device address in the parameters of the constructor. For the life of me, and my team, we can’t find the address of raspberry pi’s I2C port. Could someone help us out or devise a way to find the address?
The issue that you are running into is that both the RoboRIO and the Pi are I2C masters. I’m pretty sure that the RoboRIO can’t be run in slave mode, and doing a bit of research it looks like the Pi has trouble being a slave. It looks like the Pi 2 has the pins to be a slave, but I couldn’t find any instructions on how to set it up. You might be able to with more research time however.
I thought about something similar. If you used ethernet on the pi, you could run a web service on the Pi that the Rio could call to get information. If you wanted more of a Push going on, try long polling.
It’s possible to run NetworkTables on a Raspberry Pi, and currently pynetworktables should work for that and be able to connect to your robot. https://github.com/robotpy/pynetworktables
Using NetworkTables from another language on a Raspberry Pi is harder, as it now uses a native library, however its not too difficult to compile it.
As of right now we are looking into using the serial over the RS-232 port on the roboRIO. All I’ve got to do is pick up some bi-directional logic level converters. Sparkfun looks like they make some good ones. I’m interested on how I’d set up the communication with pi network tables though. I assume there wouldn’t be any interference between basic robot control and the transmission of data. Also, are we allowed to put an ethernet splitter on the new routers? I’m using one port obviously to connect to the roboRIO and the other for the ethernet based axis camera (just to get a field view for orientation when I’m driving). This doesn’t exactly leave me any ports for the pi to connect to the router. Any ideas?
If you want to run Ethernet between the roboRIO and the rPi, it’s straightfoward. Our code to do that from last year is posted. It’s for a roboRIO running Java. We didn’t post the rPi code (Python), but UDP and JSON from Python are very straightforward…
Is there any particular reason that you encoded your information to JSON before sending it to the roboRIO over UDP? This looks like a good option to try too. I have zero experience in socket programming as it stands right now though, so I’ve got some reading to do. Any links on it would be helpful.
Hi,
A few days ago I released code that handles communication between roboRio and RaspberryPi / Odroid over TCP. It’s based on the zeromq library, for which a python binding exists I believe. The code itself (C++, for vision tasks) may not be useful but it could give some ideas. And I also provide libmzq.a builds for RaspberryPi, odroid, roborio…
Here’s what we have so far in terms of UDP programming.
UDP transmission does work on the PI end of the programming. We had it sending data over Ethernet to a laptop and the laptop was receiving it with some basic python script. For some reason we can’t get the receiving end of the code to work in Java on the robrio. We’ve got a basic UDP class that should receive data when the getData method is called. Based on just a simple 1 or 0, we should be running our drive chassis forward or backwards in teleop. When we deploy and run the code a couple of weird things happen. First of all, there’s no response from the talon srx. It just stays yellow, indicating that it’s receiving a value of 0 for drive. Also, any data that we normally write out to the smart dashboard in our teleop section of the Robot.java class ceases to update. Since the runDriver method is called before the SmartDashboard writes out it’s value, I wonder if it’s getting hung up on the UDP receiving part of the program. We don’t get the tell tale error of “Robots don’t stop” though, so I’m not inclined to believe that that’s the case. Can anyone help us out?