Can I plug the Pigeon directly into one of the Gadgeteer ports on the HERO similar to how the manual shows plugging it into a Talon SRX port (for power and CAN)? If so which port supports this? I have read through the literature on both, but do not see this explicitly stated anywhere. I’m more of a mechanical person just doing some tinkering and I really don’t want to fry one or both of these by hooking them in the wrong ports.
Any help would be appreciated.
The Pidgeon has UART communication through the data port. If you plug it into a HERO into a UART port, it should support UART communications. Did you check the CTRE Github for HERO+Pidgeon examples?
Email the CTRE support folks. I promise, they will answer questions promptly.
Edit:
This is from the pigeon page: It can be connected to the Gadgeteer Port on the Talon SRX or HERO for power (<50mA) and communication via UART
From there, the ports labeled with U as a letter are Uart ports:
And here is example code for the HERO and a Pigeon but you’ll probably want to modify it:
Thanks for the guidance. I think I’m still missing something.
If I connect it to a port on a Talon I can see the Pigeon as a CAN device found in Lifeboat, but when I attach it directly to the HERO in port 1 which has a U [AUSX] the lights are different and I do not see a Pigeon device in Lifeboat.
I’ll reach out to CTRE in the morning to see if they can show me where I am going wrong.
Lifeboat shows devices on the CAN bus. When you connect a Pigeon to a Talon, all the Talon does is read data from UART and then put that on the CAN bus. Thus, the Pigeon shows up in Lifeboat as a CAN device.
A Pigeon, or anything connected to a HERO via a Gadgeteer port, will never show up on Lifeboat. Try running a Pigeon-HERO example from Github first.
I was still having issues trying to used the examples on github so I reached out and contacted CTRE. As Marshall stated, they very were quick to respond and help. I am very impressed with their customer service.
So if anyone runs through this same issue I figured I would post the responses here. They updated the example code library for where the Pigeon will now work from a HERO Gadgeteer Port, but they recommend using using CAN either directly or though a Talon SRX for the time being.
The example you’re using was written for the old 4.X Toolsuite, which is why you’re getting errors.
I just updated the example and added it to our current repository - you can find the new example here:
Phoenix5-Examples/HERO C#/HERO PigeonUartGadgeteer Example at master · CrossTheRoadElec/Phoenix5-Examples · GitHub
Keep in mind that the GitHub example above will allow Pigeon <===ribbon===> HERO but it uses a slow 115.2kbps bitrate, and only gets Yaw/Pitch/Roll values. I’m not certain what the effective update rate is but it’s not the 10ms you would see in the better-supported Talon and CANbus use case.
I would say if you just want to grab the YPR values and don’t particularly care at what speed, the UART example is great since the ribbon cable connection is very convenient (no soldering).
But for a robot I highly recommend either CAN connection, or ribbon-cable to a Talon already on the bus.
Let me know if you have any other questions.
Regards,
Jacob Caporuscio
Software/Hardware Engineer
CTR Electronics
Adding to Jacob’s response…
The full serial comm stack is more complex than what’s implemented in SerialClient
That’s why the C# HERO-ribbon-cable example is just an example and not something that we support/integrate in Phoenix-netmf.
That’s also why it falls to 115.2 Kbps instead what the Talon uses for Pigeon (2Mbps if I remember, roboRIO self-test tells you the exact bitrate)
It was meant as more of a test to prove out what would eventually become the serial-uart protocol between Talon and Pigeon.
Long-term we might bring the full stack into hero firmware, and provide an class type that works identical to the Phoenix PigeonIMU class. But it’s not currently our focus.
The example only provides YPR, and doesn’t even have a way to tell if the pigeon has finished boot-cal (4 second boot while still) or if the YPR is stale.
So if you use this, you must ensure the Pigeon settles on boot manually (LEDs) since there is no API-method to determine when the IMU is ready (a requirement of all inertial sensors).
Omar Zrien
Chief Engineer - Software/Co-owner
Cross the Road Electronics, LLC