So our team is currently using a raspberry pi for multi-camera streaming, and attached to the raspberry pi is the pixy2 camera that we are using. The code works fine if I ssh into the raspberry pi and run it (“sudo python3 ~/uploaded.py”). However, the background service which normally runs your code automatically at boot simply doesn’t work with the pixy libraries. It crashes, but it doesn’t crash when the pixy is initialized; it crashes when anything is accessed on the pixy afterwards (i.e. pixy.change_prog() or pixy.get_all_features()). Even more, it crashes without an error printed. Usually, if it cannot find the pixy or it does not have sudo access, it will give a segmentation fault when pixy.init() is run; this isn’t the case, it just silently crashes.
Does anyone have any experience with using the pixy2’s python usb libraries on the FRC raspberry pi image? I know that conventionally most teams connect the pixy2 to the roborio, but we’d prefer it with our approach to use the raspberry pi. Thanks!
Based on an issue/request, I added the Pixy libraries to the FRCVision image in 2019.3.1, but I don’t have a Pixy2 so haven’t done any testing of it. It sounds like the main thing is it needs root access? If that’s the case, edit /service/camera/run and change line 4 to simply read ./runCamera, this will cause it to not drop root privileges when running the runCamera script.
I followed all of the steps located on Pixy2’s tutorial page with a few exceptions.
3a. I enabled write permissions first.
3b. Because of Pixy’s preference for Python 2 I needed to install python 2 build tools (for the header file). This is simple sudo apt-get install python-dev
3c. I used Nano to create the above rules file and then rebooted.
It works perfectly (even without write permissions) with one exception. When I run the Pan_Tilt demo, it does not get the age of the target without root permissions. That is not a big deal for us right now.
I used Putty to ssh into the Pi.
All and all, an easy setup. Thank you all. Now we need to decide if we are using the pi or just the rio. If we do vision, we will have 3 cameras, so I am thinking we are going to use the pi.
How are people powering theirs? Is it legal to power the pi and a hub through the vrm?
Yup, I got swig to build it using python3 and it worked perfectly. Once I got it working with @Peter_Johnson’s solution it ran automatically every time, and it worked consistently on the field at Palmetto. If you want me to show you how to build it with python3 lmk
Excellent. I am glad it worked for you all.
I would like to know how you got it to build with Python3. We worked on that over the summer and got it to work with the getblocks code, but ran into issues converting the PID algorithm to Python3 as the following line…
Edit setup.py to be compatible with python3 (I believe I just had to fix the print to have parenthesis)
cd into pixy2/scripts/
Edit build_python_demos.sh and change the line that runs “python script.py…” to run python3 instead
At that point, it automatically created pixy libraries that were compatible with python3. I might be missing a step but I think that was all I had to do. Let me know if it doesn’t work, I remember it being surprisingly simple though.
We could not figure out how to run it unless we build it. Do you know the path to the library?
We also do need to change permissions to allow the non-root user (pi) to run it (which was easy). Thank you for the frc pi image, it helps our team (and probably many others) a lot.
Thank you. That did work. Now, I just need to work on how to get the servo pid to function.
I can run the pan_tilt_demo, but it crashes when the servos need to move. here is the error we get.
File "pan_tilt_demo.py", line 114, in <module>
pixy.set_servos (Pan_PID_Controller.Command, Tilt_PID_Controller.Command)
TypeError: in method 'set_servos', argument 1 of type 'int'
I think it’s because Pan_Offset automatically becomes a float. If I’m interpreting the API correctly, the width should be 315 pixels. When you divide it by two it will be 157.5. In python2, it would have just truncated it and been an integer, but python3 changed integer division to return a float. Of course, floats are not supported with bitwise operators. So I’d cast all of the divisions to ints and see if that fixes it.
Thank you. It seems to be working now, albeit with some erratic behavior. I will update after we have some time to check.
As I was troubleshooting, it occurred to me that happened over the summer was that Pixy posted a branch with working LEDs for Python. It can be found here. There is even an example of using the Pixy onboard LEDs. They are not dimmable, but they do help targeting.