Greetings.
We have close to 100 freshmen engineering students using the XRP robot each year. We’ve swapped out some sensors (and had to I2C daisy-chain a couple), and thus had to make a few changes to XRPLib and create our own library for the new sensors.
All’s well. Until there’s a new version of the XRPLib files (e.g., early this year, during the semester) that inevitably are downloaded, overwriting the custom mappings in defaults.py, and causing mass confusion, and sometimes more than a little panic.
I would love it if we could we prevent xrpcode.wpi.edu from recommending updates until the end of the semester, because some set of students within the various teams inevitably accept the update.
Thoughts?
Thx,
Kevin
Hi Kevin,
Awesome to hear you’ve got so many students using the XRP!
My recommendation would be to avoid modification of XRPLib if possible, and instead put your custom library files in a different folder within the lib directory. Then in your students’ code, add a second import for the custom library. This should avoid problems when XRPLib updates become available. If you need to remove some of the items in XRPLib.defaults, then you could define your own myLib.defaults that is a modified copy and import that instead.
Would that work for you? Do you need any guidance on how to implement that?
Hope this helps!
Thx for the quick response.
The robot is modified for the specific challenges the students program it to address (wall following, color sensing).
We removed the reflectance sensor and the servo, and moved the Rangefinder to another I2C interface so that we could separate the two wall-detecting infrared proximity sensors onto two different I2C buses (because they’re not capable of being assigned different addresses), and we also added a colored-light sensor, which is daisy-chained with one of the proximity sensors.
Thus we also provide an edited XRPLib/defaults.py to specify the correct IOs used when instantiating the Rangefinder object (26,27), rather than the default IOs.
Yes, we have our own library that then instantiates (in another defaults.py) the sensors we added and files that define classes for each, plus various test routines.
At a higher level, there could be unforeseen interactions between new pushed code / libraries, and the custom library we provide to students (or their own code). And we need to avoid the possibility of anything new being pushed, e.g. the day before the final robot competition.
Here’s a video that the university made of the event: Redirecting...
If you can suggest another approach, I’m all ears!
Kevin
Glad you got the video made, it looks great.
The easiest way to accomplish your goal is to look at the version.py file in the XRPLib directory. We create this file on the fly when we update. And it is how we determine if your library is up to date. And in fact the easiest way to force a library update is to delete this file.
For Your purposes, you could, up the version number in the file. I haven’t tested cheating the system in this way, but we do check for if the current loaded library is greater.
That seems like a reasonable workaround.
Thank you.
Kevin