Programming for TalonSRX without RoboRIO?

[TheHolyHades1]

In a side project, I'm currently attempting to use a couple Talon SRX's with a Beaglebone Black I have lying around, interfacing through a CANbus cape for the Beaglebone Black. In looking at the software reference manual, I see that I need to set the device IDs for the Talons - is it currently possible to do this without a RoboRIO?

Additionally, I'm attempting to find the source for the CANTalon.cpp / other relevant files, since I imagine I'll need to modify it slightly to be able to communicate via the can0 network interface that the cape provides as opposed to via the RoboRIO, but I can't seem to find the .cpp files on the WPIlib website - I'm only able to find the .h files. Could someone please point me to the .cpp files?

EDIT: As a note, I'm using Linux, but I also have a windows box available if necessary to download files.

EDIT 2: After some more poking around on CD, I was able to find this thread (http://www.chiefdelphi.com/forums/showthread.php?t=129615) which links to this page (https://usfirst.collab.net/sf/projects/wpilib/), from where I was able to clone the repo. It seems that the CANTalon implementation has 2 levels - one being a WPIlib implementation (CANTalon), and the other, lower level one being a CTRE item (CanTalonSRX). However, I'm still not sure how to get the correct device IDs without the RoboRIO.

EDIT 3: Further digging reveals that the CAN implementation is dependent on a NI library, which is provided only as a .so. ("./ni-libraries/libFRC_NetworkCommunication.so"). I believe what I'd have to do is rewrite this library using my network interface instead of the one that is used on the RoboRIO. This would be significantly easier if I had the original code to work off of, so I will continue looking around.

EDIT 4: I've narrowed the files down to just a select few that I can start building up from, but I've hit another roadblock. I was hoping to be able to run a very simple program where I just instantiate a single CanTalonSRX, but it seems even that isn't possible at the moment, because the .so that's provided doesn't work on my system architecture. I should've realized this earlier. Since the RoboRIO is an ARM system, I'll try it on my beaglebone and see if I'm able to get it to work there.

EDIT 5: I've realized that the precompiled libraries are going to do me no good, so I've scrapped them entirely - while I got very close to compiling successfully on the beaglebone (note, C++11 is required), I got an error saying the linker wasn't able to find the _start. A quick SO search revealed that this is typically found in some .a file, which I wasn't able to find in wpilib. Additionally, I belive the .so requires libraries on the RoboRIO which I don't have on the Beaglebone. In short, this means that the only real way (as you've probably guessed by now) is to scrap the entire NI code and work with just the CANTalon code. I've begun this by starting to rewrite CANSessionMux.h / cpp, using the same gigantic function names as before. If you're curious, the file list that I'm working with at this point is as follows:

ctre.h
CanSessionMux2.h //I've renamed CanSessionMux.h, the original, by adding a 2
CanSessionMux2.cpp //This was previously in the form of the .so, and this is where my rewrite will likely take place
CtreCanNode.h
CtreCanNode.cpp
CanTalonSRX.h
CanTalonSRX.cpp
testing.cpp // a small program to initialize a CANTalon object. Compiles successfully!

And the command line arguments to compile:

g++ ctre.h CANSessionMux2.h CANSessionMux2.cpp CtreCanNode.h CtreCanNode.cpp CanTalonSRX.h CanTalonSRX.cpp testing.cpp -std=c++0x

[Foster]

Let me say first that I can't help you.

Let me now say that is one of the best single posts I've seen asking for help. You described what you were doing and why. You then (even though it took multiple edits) to go through the steps and hoops that you leaped through. It is a big help to people that can help to know what things have been tried and failed.

So many times people ask questions that can be answered in a single Google session.

All I can suggest is maybe sending an email to CrossTheRoad with all your other info and see what they suggest.

When you get it to work, please post back!!

[Greg McKaskle]

I can give a partial answer, but you will get much more detailed info from CTRE.

The CAN devices allowed on FRC robots are running a firmware that relies on safety tokens on the roboRIO to provide an extra level of safety. If the robot is Estopped or disabled, the CAN devices need to go into safe mode, even when they have been told to do closed loop operations like position control. So you will not only want to set the CAN IDs, but you will want to install different offseason firmware to get rid of the dependency on the NI FRC_Comms library that provides the safety tokens.

It may in fact be the easiest to use the roboRIO to connect to the talons for imaging and ID setting, but other CAN bridges could be used. This is where they could list more alternatives than I can.

Have fun with your project.
Greg McKaskle

[Foster]

The CAN devices allowed on FRC robots are running a firmware that relies on safety tokens on the roboRIO to provide an extra level of safety. If the robot is Estopped or disabled, the CAN devices need to go into safe mode, even when they have been told to do closed loop operations like position control.

This is a really interesting idea. Can you explain some more on how this works? I'm assuming the roboRIO sends a token to each device going "keep on working" and that the device stops after it hasn't seen a token in some time. Is this correct?

[Greg McKaskle]

Yes, the CAN devices used for FRC outputs require a heartbeat in order to keep their outputs active. If they don't receive a heartbeat token within 100ms, they shutdown.

Greg McKaskle

[TheHolyHades1]

Let me say first that I can't help you.

Let me now say that is one of the best single posts I've seen asking for help. You described what you were doing and why. You then (even though it took multiple edits) to go through the steps and hoops that you leaped through. It is a big help to people that can help to know what things have been tried and failed.

So many times people ask questions that can be answered in a single Google session.

All I can suggest is maybe sending an email to CrossTheRoad with all your other info and see what they suggest.

When you get it to work, please post back!!

Thank you for the compliment. I was updating that post in realtime as I went along, with probably about 3 hours between the first post and the final edit, at which point I decided it was time to call it a night. Before that I had done a little Googling but wasn't able to find anything.

I'm currently in the process of emailing CTRE, I'll update this post if / when I get a response.

[TheHolyHades1]

Yes, the CAN devices used for FRC outputs require a heartbeat in order to keep their outputs active. If they don't receive a heartbeat token within 100ms, they shutdown.

Greg McKaskle

This is very good to know. I was ultimately unable to discern anything useful from the .so files, which are made even more complex since none of the functions return anything and instead just update some pointers with who knows what kind of data (per the headers, at least). This starts to give some insight into what I'd need to do to rewrite them.

I have absolutely no idea where to begin if I'd need to rewrite the firmware for the Talon, however. Hopefully CTRE is able to help.

[Greg McKaskle]

You will not need to write the source code for the talon, you will need to download a different firmware image that is for non-FRC use. I suspect CTRE will have some other libraries or specs on the CAN messages that will lead you to where you want to go.

Greg McKaskle

[Ben Wolsieffer]

I think you are not going to ever be able to get the source for the NI libraries. I wanted to get access to understand the driver station protocol, and it seems that NI wants to keep it to themselves.

If you can't get information through CTRE, you could try using a logic analyzer to sniff the CAN bus and reverse engineer the protocol and heartbeat packets while the Talon is connected to a roboRIO. If you could figure enough of the protocol, it shouldn't be that hard to write your own driver for the Beaglebone.

[Greg McKaskle]

I think you are not going to ever be able to get the source for the NI libraries. I wanted to get access to understand the driver station protocol, and it seems that NI wants to keep it to themselves.

If you can't get information through CTRE, you could try using a logic analyzer to sniff the CAN bus and reverse engineer the protocol and heartbeat packets while the Talon is connected to a roboRIO. If you could figure enough of the protocol, it shouldn't be that hard to write your own driver for the Beaglebone.

NI writes the code, but it is FIRST's call as to whether something is released or not. If it doesn't affect safety, it is generally fair game -- like the implementations of WPILib and NetworkTables. If a modification to a library, to the FPGA, or to the DS, causes a team to lose control of a robot, that could be a pretty bad thing. So, some libraries are considered a part of the safety system and are kept closed.

While reverse engineering is a great skill to work on and can be fun and productive, I would not suggest it for the CAN motor controllers used in FRC. My suggestion is still to get in touch with CTRE, get their firmware package that is already written for nonFRC applications, and use that for offseason projects that do not use a roboRIO. If you then want to use the motor controllers for FRC again, reimage them.

What part of the DS protocol or source were you interested in? I don't remember this coming up.

Greg McKaskle

[TheHolyHades1]

NI writes the code, but it is FIRST's call as to whether something is released or not. If it doesn't affect safety, it is generally fair game -- like the implementations of WPILib and NetworkTables. If a modification to a library, to the FPGA, or to the DS, causes a team to lose control of a robot, that could be a pretty bad thing. So, some libraries are considered a part of the safety system and are kept closed.

While reverse engineering is a great skill to work on and can be fun and productive, I would not suggest it for the CAN motor controllers used in FRC. My suggestion is still to get in touch with CTRE, get their firmware package that is already written for nonFRC applications, and use that for offseason projects that do not use a roboRIO. If you then want to use the motor controllers for FRC again, reimage them.

What part of the DS protocol or source were you interested in? I don't remember this coming up.

Greg McKaskle

I emailed CTRE on Friday, and got a response very quickly after that. I have since gotten a copy of their non-FRC firmware, which I will be flashing to the Talons soon, as well as a good bit of information on the protocol. Overall, CTRE (Omar specifically) has been very helpful. Seems like an awesome company.

[riftware]

NI writes the code, but it is FIRST's call as to whether something is released or not. If it doesn't affect safety, it is generally fair game -- like the implementations of WPILib and NetworkTables. If a modification to a library, to the FPGA, or to the DS, causes a team to lose control of a robot, that could be a pretty bad thing. So, some libraries are considered a part of the safety system and are kept closed.

While reverse engineering is a great skill to work on and can be fun and productive, I would not suggest it for the CAN motor controllers used in FRC. My suggestion is still to get in touch with CTRE, get their firmware package that is already written for nonFRC applications, and use that for offseason projects that do not use a roboRIO. If you then want to use the motor controllers for FRC again, reimage them.

What part of the DS protocol or source were you interested in? I don't remember this coming up.

Greg McKaskle
I know there was a very serious off-season project that was trying to make an off-season driverstation that could run on linux or Mac and there was even an android port. They had it working mostly until 2015 changed the protocol. If there is even a possibility of the protocol being release (after competition season) I can dig the project back up and get the right people talking to the right people. I'm interested because I do all my development and testing under linux and I'd love to test without having to fire up windows.

[TheHolyHades1]

I realize it's been a while, but an update.

I've written a python module that works very similarly to the CanTalonSRX libraries in WPIlib. While I haven't gotten around to publishing documentation or usage yet, it should be feature complete as far as I know. If there's interest in me providing some documentation and thoroughly commenting the code, I can do that. That said, a bit of usage:

from PyCanTalonSRX import *
import can

bus = can.interface.Bus()

talon = CanTalonSRX(20) # dev id for talon
talon.set_mode(Mode.DutyCycle) # set mode

while True:

# see if any messages need to be sent to the talon, and send them
if not talon.txQueue.empty():
msg = talon.txQueue.get_nowait()
msg.timestamp = time.time()
bus.send(msg)

# see if we need to receive a message from the talon
recv = bus.recv(0.0)
if recv != None:
talon.update(recv)

# Other logic to run continuously


https://github.com/VasuAgrawal/PyCanTalonSRX

I can add additional functionality as desired, but in my application this has been enough. I've successfully used this package to control a couple Talons with ROS. Please PM me with any questions.

EDIT: Note, you'll also need a custom firmware, which I was able to get from Omar at CTRE.

[Schnabel]

Just a note, CTRE released the non-FRC firmware on their site. http://www.ctr-electronics.com/talon-srx.html#product_tabs_technical_resources