First version of iterativerobotpy.py #161
Conversation
Signed-off-by: Mike Stitt <[email protected]>
| kTest = 4 | ||
|
|
||
|
|
||
| class IterativeRobotPy(wpilib.RobotBase): |
There was a problem hiding this comment.
I know this is a draft, but adding docstrings can be annoying. Recommend either using the sphinxify webserver (https://github.com/robotpy/devtools/blob/main/sphinxify_server.py) to convert javadocs, or just grab the docstrings from the .pyi file that ships in our existing wheels on pypi.
Obviously, before we can merge this, all public methods need docstrings.
| def testExit(self): | ||
| pass | ||
|
|
||
| # todo @Deprecated(forRemoval=true, since="2025") |
There was a problem hiding this comment.
When we deprecate things, we typically only do it in the docstring.
| wpilib.DriverStation.refreshData() | ||
| self._m_watchdog.reset() | ||
|
|
||
| self._m_word.refresh() # todo from Java implementation |
There was a problem hiding this comment.
C++ doesn't have this, I filed a bug to fix that (wpilibsuite/allwpilib#7889).
For now, just do self._word = DSControlWord() and it should have the same effect. Leave a TODO note to switch to refresh when it gets implemented.
There was a problem hiding this comment.
Actually, robotBase has a GetControlState method which returns (enabled, autonomous, test)... which I think would be better to use here.
There was a problem hiding this comment.
@auscompgeek AI tells me that "The eyes emoji (👀) generally indicates a sense of observation, attention, or interest, often with a subtle hint of intrigue or admiration. It can also be used to suggest that someone is being watched or is deliberately drawing attention to something."
What are you thinking here?
| # private void printLoopOverrunMessage() { | ||
| # DriverStation.reportWarning("Loop time of " + m_period + "s overrun\n", false); | ||
| # } | ||
| wpilib._impl.report_error.reportWarning( |
There was a problem hiding this comment.
Yes, this is correct.
I would do at the top of this file from wpilib import reportWarning. Every time there's a . in python it's another dictionary lookup, and the rio is really slow.
| self.driverStationConnected() | ||
|
|
||
| # If mode changed, call mode exit and entry functions | ||
| if self._m_lastMode != mode: |
There was a problem hiding this comment.
nit: Python enums are singletons, so prefer using is like the recommendation in the Python docs for enum
|
Top level questions: Is the filename right? Is the file in the right spot in the tree? Is the class name right? What are the appropriate tests? What happens if someone deletes the watchdog? Is the there a higher level watchdog that will stop the motors? Can somebody figure out how to call the shuffleboard? |
|
I'm not sure about the filename/classname yet. I think you're approaching it as an alternative, but I sorta want a replacement? But, I guess we could go either way. TBH, before deciding on alternative/replacement, probably need someone to do some testing on a real robot to see if it makes loop overrun issues more/less/same.
... yeah, the only real way to test this is likely going to be by testing examples, which is something I'd like to do but haven't taken the time to do (see #154). Java has tests for TimedRobot, but they basically do the same thing that the pyfrc test framework does (maybe that's an argument for moving some of that into here...).
If someone deletes the watchdog, that's their problem -- but also, the motor watchdog is actually a separate thing? This one just tracks loop overruns and tells the user about it.
|
Signed-off-by: Mike Stitt <[email protected]>
Signed-off-by: Mike Stitt <[email protected]>
|
This version simulates a TimedRobot, advances time, logs to AdvantageScope in a reasonable way, but does not move the robot in simulation. It feels like some sort of enable interlock on the simulator is missing. Generally all status results from hal.xxx calls seem to result in a strange value, but the calls seem to work.
do not seem to make the pure python files editable in place. Could use some detailed advice on how to get the python files to be editable in place. |
|
This is the code I'm using to simulate: https://github.com/spiresfrc9106/spiresRobot2025/blob/exp-timedrobotpy/robot.py#L46 |
|
For |
|
It's hard to tell which libraries need to be uninstalled for mostrobotpy and which need to stay for robotpy: t2.txt: |
|
The error you're getting has to do with a quirk of how macOS support is implemented. What it comes down to is that you need to have all robotpy wrapper dependencies installed the same way (either via develop or installed normally). If you mix it then you sometimes get weird errors like that. Typically, I use virtualenv (and specifically, virtualenvwrapper) to manage my various python development environments. I don't recommend that normal RobotPy users use virtualenvs unless they're comfortable with them, but they're really useful for python development -- and because they're effectively disposable, you can do a lot of weird changes in one environment without worrying too much about how much you're breaking. Specifically, I have different environments set up for installation from pypi, development, and various branches that I might be working on. If you were using a virtualenv, I would just say delete your virtualenv and start installing packages from scratch. If you're not using a virtualenv, then just uninstall all robotpy-* packages and wpilib and pyntcore, and then run develop again. |
|
I normally use When I re-ran that in an empty My conclusion is the More basic though is that https://github.com/robotpy/mostrobotpy/blob/main/README.md should define the relationship (what they do and where they are and how to find instructions to build/install them) between pc Also more basic is that https://github.com/robotpy/mostrobotpy/blob/main/README.md should define when to run:
and and and the command to then the installation instructions should take one all the way to a |
Yes and no. As mentioned above:
What this means is that if you are installing the base robotpy packages in develop mode, you must also install robotpy-rev, ctre, etc in develop mode. To install robotpy-rev, you would need to There might be a way out of the macOS problem by messing with the library name, but I haven't had time to look deeper into it. I agree there should be more documentation. I also agree the installer scripts should be better to make this easier. |
Signed-off-by: Mike Stitt <[email protected]>
…t timer math. Signed-off-by: Mike Stitt <[email protected]>
|
I have been trying lots of different paths to build mostrobotpy editable on OSX, Debian, and Windows, on a full production robot code base in simulation. Goal is to be able to run on real robot code. (I'm typing not cut and pasting so there may be some typo's here) I end up with two copies of many of the repos needed in the system: I can uninstall those with But then I need to install a specific version of photonlibpy: which will then also uninstalls the editable development parts of robotpy Note that I have been automating these steps here: https://github.com/MikeStitt/pythonExperiments/tree/main/tryRobotPyBuildEditable But as I search online for ways to tell This seems to be the same on debian, and osx, (I haven't got my windows build to complete yet). Thoughts on a valid development/debugging/testing installation process? -Mike |
|
The multiple package problem is likely caused by pip. I note that you have 23.1 installed, try upgrading. The version numbers for your editable installs are photonlibpy has a pinned dependency on Telling pip to ignore dependencies (via |
|
One last note, because I don't trust setuptools to do the right thing, I run We will not be using setuptools next year, so hopefully some of that will go away. |
|
My windows builds using x64 Native Tools Command Prompt fail this way: |
|
That error seems really familiar, I think we ran into it last year? I don't use Windows at all these days. I think you need to upgrade Visual Studio... according to this CD post you need 17.9 or later? |
|
This feels like a silly question, really bad planning on my part. But in debian bookworm I get: Debian bookworm doesn't support robotpy sim? |
|
WPILib does not support simulation on linux/aarch64 |
|
Actually, that doesn't seem to be true anymore, https://frcmaven.wpi.edu/ui/native/release/edu/wpi/first/halsim/halsim_gui/2025.3.2/ shows aarch64 packages. We would need to update mostrobotpy to build them and update the robotpy-meta constraints. |
|
I thought we do build it, it's just that by default robotpy-meta doesn't install the sim stuff on Linux aarch64? |
|
I have found a route to simulate a full robot with mostrobotpy editable on a OSX M3 Mac: First install Then: Python click module does most of the heavy lifting: Which runs these commands: Then: Things that were not obvious were:
|
Simulation should work fine on Linux aarch64. I've run the simulation for the examples on my Raspberry Pi 400. |
I created this issue to document where we are currently at: robotpy/robotpy-meta#33 |
Signed-off-by: Mike Stitt <[email protected]>
Signed-off-by: Mike Stitt <[email protected]>
Signed-off-by: Mike Stitt <[email protected]>
A draft to get progress going.