Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[High Priority] CAN Bus Interface #3

Open
SwapnilPande opened this issue Jan 12, 2019 · 5 comments
Open

[High Priority] CAN Bus Interface #3

SwapnilPande opened this issue Jan 12, 2019 · 5 comments
Assignees

Comments

@SwapnilPande
Copy link
Member

Which section of robot code is this for?
CAN Bus Interface

Description of feature

  • Develop a class to interface with the CAN Network on the robot:
    • Connect to network
    • Send commands
    • Receive commands
  • Develop ROS Node for the interface to run on the Raspberry Pi
partlygloudy pushed a commit that referenced this issue Jan 15, 2019
There seemed to be some minor changes between the two, probably not super important but figured it wouldn't hurt to update
partlygloudy pushed a commit that referenced this issue Jan 15, 2019
Now we can import our custom message types that we defined for transmitting the desired motor speeds
partlygloudy pushed a commit that referenced this issue Jan 17, 2019
Trying to see if this could be what was causing compilation errors on raspberry pi
partlygloudy pushed a commit that referenced this issue Jan 17, 2019
@partlygloudy
Copy link

For some reason the latest version of the phoenix libraries doesn't seem to compile on the raspberry pi while the older version (the one Joey had been using) compiles fine. It's possible I'm just doing something wrong but since the two seem more or less the same I guess we'll just stick with the older ones.

@jeholliday
Copy link
Member

Just to make sure, we should be using the software found here https://github.com/CrossTheRoadElec/Phoenix-Linux-SocketCAN-Example. I hadn't see that they had released a newer version. I'll check it out on Thursday. We should definitely switch to it if possible because it includes a note there's no longer a FRC vs nonFRC of the latest version of the firmware.

@partlygloudy
Copy link

Me and Josh tried compiling the code at that repository but weren't able to. The code we're using now is from that location as well, it's just an older version of it (I just copied the libraries over from the 'motor_control' repository you had been working on a little while back). I agree that we should switch if possible. Luckily, the classes and function names are unchanged for the most part so any code developed with the older version should work with the new one without needing to change much.

@partlygloudy
Copy link

[Resolved by Joey, turned out that gcc needed to be updated on the pi - after updating, the library compiled cleanly]

partlygloudy pushed a commit that referenced this issue Feb 5, 2019
All future work on this should be done in this repository rather than the motor_control repository
@partlygloudy
Copy link

I moved the latest version of the code from the motor_control repository into this one.. lets please do all future development of this code in this repository

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants