I am trying to create a PigeonIMU object in python code:
self.pigeon = PigeonIMU(self.PIGEON_IMU_CAN_ID)
When I run this in the pyfrc simulator I get an error:
File “robot.py”, line 117, in robotInit
self.pigeon = PigeonIMU(self.PIGEON_IMU_CAN_ID)
TypeError: init() takes 1 positional argument but 2 were given
I understand some parts of ctre api are not functional in the simulator. My question is whether this line of code will function correctly on the robot or not?
Yes, the documentation for how to implement the pigeon is a bit light. I think you are correct that the that this is not yet supported in the simulator.
We have not actually run this code yet, but I think you are putting the wrong identifier in.
Here is what we have (but we are using the gadgeteer cable in a Talon).
frontLeftDrive = WPI_TalonSRX(1) self.pigeon = PigeonIMU(frontLeftDrive) This did build for the simulator without error.
If you want to run CAN, that line self.PIGEON_IMU_CAN_ID should be an integer. So, you could set it as a variable as I did above, or just define the CAN id of your Pigeon (do not forget to set it with the CTRE lifeboat software).
Either way, your code would look something like this.
self.pigeon = PigeonIMU(5)We have a build day tomorrow, and I will try to get testing this on the agenda. We are working on this, but have other pieces to focus on first.
Good luck, and let me know if you get this working first. We are just figuring it out ourselves.
~Mr. R^2
[Edit] Once we figure this out for certain, does anyone know how we can update the documentation? Do we just do a pull request on the git? Or do we do something else? You all are doing such an excellent job with keeping robotpy updated, relevant, and running smooth. My team cannot help with too much of the development, but if it would be helpful, we may be able to help update the documentation as we test out new systems, and learn how to program our robot in Python. [/Edit]
We have the pigeon wired directly into the CAN bus, not via talon/ribbon cable.
I will also be testing tomorrow on actual hardware. We have a test program here, robot.py, that we will be using. I tried to heavily comment it. I’ll try to report back tomorrow evening how it worked out and will commit the updated code if we do get it working well.
It it mostly based on this code from Team 1923 from 2018. https://github.com/Team1923/Power_Up_2018
The PigeonIMU constructor is definitely implemented and takes arguments. Where are you importing this PigeonIMU class from?
Well I just tried it again so that I could try to answer your question @auscompgeek and it seems to be working fine now. This is after significant code changes. Code changes only though… I didn’t do any pip updates or anything like that. I did make a few changes to the import statements to go from “from ctre import*” to more specific imports.
I still have a couple strange import/api related questions I could use some help with.
from ctre._impl import StatusFrame at the top of the file. The _impl part makes me feel like I am doing something wrong.self.leftTalonMaster.setStatusFramePeriod(StatusFrame.Status_2_Feedback0, 10, self.CAN_BUS_TIMEOUT_MS)
self.leftTalonSlave.configSensorTerm(0, FeedbackDevice.RemoteSensor0, self.CAN_BUS_TIMEOUT_MS) #SensorTerm.Sum0 is not defined??
Full source code is at the “robot.py” link I posted previously.
The StatusFrame enum is exposed on BaseMotorController and its subclasses (e.g. ctre.TalonSRX). The SensorTerm enum should be as well… but apparently not.
Yes, making pull requests to the appropriate repository is the best way to do it.
It works! Working code is here. Commit # is 03e4a09ad99c8654145c5755b33e3afc16e47939, maybe that will be useful if someone is reading this in the future.
This version of the code is driving the left and right side of the drive train completely independently. This worked better than closing the position loop on the sensor sum, but I think the sensor sum approach is really intended to be used with MotionProfileArc mode.
Our original intent was to use the MotionProfileArc mode but we ran into some issues with that, see details on that here. We are going to try to get that working still and I will update that effort on that thread.
The code for using the Pigeon and doing the “Sensor Sum” is not actually used. That was for the MotionProfileArc mode and just hasn’t been removed from this revision.
Here is a quick video clip (if it works to upload). It is surprisingly accurate… with essentially zero tuning.