How would I talk to the robot with no API? I can connect to the robot but, I do not know what data to send to the robot or what format.
RobotPy uses the WPILib API. It accesses the official FRC Hal (CPP I think).
The way the workflow normally goes for us is…
On the Host Conputer…
Install the FRC Suite
Update the Rio to the new season’s image
Push a basic robot.py program (tethered through Ethernet)… …this installs robotpy on the Rio
Update the radio
Once that works, we begin our development and install 3rd Party libraries (NavX, CTRE, and Rev). Each is installed as Java/CPP, and then has a seperate pip install.
I am on my phone so have no links, but can supply them later if you would like.
Edit, once you have installed robotPy on the Rio, you can remote in and run commands (Motor Safety is still a thing).
I’m not sure I understand the question, but uh…
The FRC networking stack is just standard TCP/IP. You could choose whatever protocol you want to speak, so long as it uses TCP or UDP and you only use the ports allowed on the field network.
I wouldn’t recommend writing your own protocol though… and you still need the FRC Driver Station software to enable motor (and other actuator) outputs anyway.
The question is definitely a bit under-specified, I’m not 100% clear what the end goal is - it would be helpful to first establish an understanding as to why a non-standard approach (I think) is being taken.
Python has lots of built in libraries to access the ethernet port - UDP is one option . If you’re not yet familiar with the OSI Model yet, it would be worth looking into. It’s a bit abstract… But, for this conversation, the point is there’s a lot of “layers” to deal with when you’re doing communication between devices.
Depending on what layer you pick to inject and read data in your software, you get different advantages and disadvantages - primarily because you have to implement the layers that are above the libraries you use.
I wonder too, is it more economical (time-wise) to use a beaglebone, pyboard or even An ESP32 instead of the Rio? There would be the initial hardware cost, and they are significantly more limited in scope and power, but you do not need the DS software. We have used all three before, they all allow direct Python interfacing with IO.
I just wanted to try to control the robot without importing the 3rd party librarys, without Robot.py, and without the FRC Suite. I know some 3rd party librarys are necessary.
Other people will know better than me, but I think the Rio’s own io requires the Frc Suite. RobotPy is all you will need for PWM motor control. No other 3rd party libraries are necessary.
The beagglebone will require a Python install (it is like a raspberry pi) and the use of libraries. However, the beaglebone blue can run off of 12 volts. I do not know what the logic level of the motor contorller ports are so keep that in mind if you want to use FRC legal motors and controllers.
Both the pyboard (which may not have WiFi) and the ESP32 (which does) support direct PWM from Python. However, they are lower voltage devices and not able to be plugged directly into the pdp without potential damage. Also, I do not think any of these devices have over-voltage or polarity protection (but I could be wrong).
Edit: though they run PWM, you will need to manually set duty cycle. So it will not be a motor.set(1).
The other option is a raspberry pi with a motor Hat.
I think you will need 3rd Party libraries to run CAN on any device.
Well first part you might want to consider is programming the FPGA using LabVIEW.
FWIW we effectively did this in college. It was on a “sbRIO”, similar architecture to the roboRIO. It wasn’t exactly easy, took a whole summer just to get the platform up and going. We were donated the hardware and had the time, so we thought it would be a fun project. It might be for OP too if they’ve got similar constraints and motivations.
Here’s the ancient and probably-not-really-very-applicable codebase if you’re curious.
But, in general, yea, I’d echo others to say other boards would have an easier learning curve to do stuff “from-scratch”.