2 Likes
Not a sammich.
1 Like
Some sort of CAN diagnostic tool?
CAN bus to SPI converter (looking at pinout Chip Select, Slave Out, Slave In, Serial Clock, Interrupt) connected to a raspi. Raspi has a DSI display. My guess is a CAN-connected debug display or something with ROS.
Edit: just noticed it’s a raspberry pi 3. Don’t think that really changes anything
That remains to be seen.
Looks like a Microchip standalone CAN controller, MCP2510 or MCP2515. Either CAN diagnostic tool with a touchscreen, or something funkier…
Active computer vision fiducials?
Aid for setting autonomous/vision tracking parameters directly on the robot?
Really overcomplicated way to select auto mode before the match?
Looks like a CAN connection for a HMI display.
Possibly to set auto modes when positioning the robot on the field?
While Marshall is rather committed to his/900’s vision for How To Run A Robot, I have to think it’s going to be something they can’t get from CTRE. You can get a display for the Gadgeteer port, which at worst hooks to a HERO board (no examples are given for a connection to the Talon SRX, anyway) and gives you the CAN connection natively.
Two suspicions:
-
It’s a device to assign CAN device IDs without a computer. A HERO can do this while connected to a PC, but I can see the value in being able to do it anywhere for quick replacements. This is one of the few places where PWM has an objective advantage over CAN motor controllers–you can plug whatever into the PWM port, and it’ll almost certainly work (if maybe with some limits or very slight misbehavior if you switched controller models)
-
Trying to be the vision processing equivalent of a Pigeon IMU by putting some of that information over CAN. The choice to skip a CANifier (which is natively designed for CTRE’s CAN ecosystem without additional legwork) could either kick dirt on this idea, or maybe they just had this hardware on the shelf already, or maybe Marshall is being contrary. I rule out nothing.
Nope. I’m not stealing that thunder from my awesome students. They’ll have something very very soon. Very.
It is CAN based. It doesn’t have anything to do with programming a robot and in no way will it ever be connected to a robot.
I will also add that The Zebracorns will be sharing a lot of data if this project pans out.
More to come.
Does this have something to do with the load of motors you collected?
I’m guessing a CAN controlled dyno? As in the RPi controls an SRX or SPX for testing a motor through the SPI to CAN interface, maybe? Although if I were going to do that, I’d use either a Kauai Labs VMX-pi or an old LM3S2965 board and modify the CAN Console app for the CTRE changes to the CAN message protocol used in FRC.
Mobile screen with emulator?
OH OH I KNOW… but only because I am designing/building the front end for it…
Next year is gonna be fun.
Also transitively it will be connected to a robot?
Doesn’t look like anything to me.
I see what appears to be an SRX data cable in the lower right corner, perhaps this is a way to configure SRXs without the Roborio?
Without any software, it’s just a bunch of wires plugged into printed circuit boards that serve no purpose.
Post some clips of your software to give us a hint 
Have to get the hardware layer functioning first.
Rookie mistake. Everyone knows you write the software first, and then build the hardware that does what the software wants. At least, that’s how many teams seem to operate!
<systems-engineering-soapbox>
As long as the architecture and interfaces are well defined, hardware and software development should be able to be done in parallel.
</systems-engineering-soapbox>
It’s parallel-ish… this particular project has only a few folks involved. We can only do so much software work without hardware to test it on.