My answers are based on the assumption that you will be trying to implement these ideas next year (on the new 2015 control system).
Quote:
Originally Posted by gappleto97
1) is there any real advantage to wiring Jags via CAN, and what differences does it make in programming (other than using the CANJaguar class)?
|
It depends on how and where you use them on your robot. There is a real advantage if you plan to use them to run built-in PID loops. Last year our World Champions 610 ran PID loops on Jaguars over Can.
The CAN jag can report current/voltage on the controller output. This was a great feature in the past. However, the new 2015 PD board will allow you to do this now to some extent. You can read current on each channel, and voltage, although I think the voltage returned will be battery voltage all the time, whereas the voltage returned by the Jag is the voltage supplied to the output of the motor controller. However, the huge difference is, in 2015 you can read the current draw across any circuit connected to the Power Distro Panel, whether it be a Jag, a Talon, a Victor, or a custom circuit, so this feature is not just limited to Jags, or CAN.
There are some pitfalls with the current CAN system, which is why my team has exclusively used PWM Talons since 2013. We have learned the hard way, that if a Jag fails and turns off (by blowing a breaker or something) it falls off the CAN bus network, and when the code looks for that ID, it will timeout. This timeout is blocking, and will hault your entire robot for the timeout period which I believe is 5 seconds. There are ways around this by modifying the WPILib implementation, its just something to be aware of.
Jags also have overcurrent and over temp protection, which will shut the controller down to protect it. The link to VexPro talks more about the current protection.
http://www.vexrobotics.com/217-3367.html. I personally don't like that, if I am in a finals match, I would rather my controller catch on fire to make the game winning shot rather than shut down to protect itself. Victors or Talons do not have this overcurrent protection.
In my observation Jags both black and grey tend to be easier to destroy when compared to Talons or Victors.
(NOTE: These are my opinions only based on my own experience. There are many teams that have used Jags in their full capacity almost exclusively without problems. We just have not been one of them.)
Quote:
Originally Posted by gappleto97
2) if we were to wire via CAN, wouldn't this take up Ethernet ports? And since I assume so, does this mean we are permitted an additional router to wire in this way?
|
On the current system you can use can through the cRIO serial interface, or using a 2CAN ethernet module. In the 2015 control system there is a dedicated CAN interface port on the RoboRio and so no ethernet or serial port will be eaten up.
Quote:
Originally Posted by gappleto97
3) this year we used PWMs and a breadboard to communicate variables to the arduino unit, which we used to control our LEDs. I know that we could do this over ethernet, but how do you send the variables? I've never had to deal with network-end programming, although my now-graduated predecessor did.
|
Now you can use i2c or spi, or even TCP to communicate to the Arduino, However, I think it is easier to use Digital IO pins or Relay Pins on the digital sidecar and have them drive Digital input pins on the arduino to transfer information. If you treat the pins as a binary number you can have up to 16 different messages with 4 digital IO pins or 2 relay channels (each relay pin can be used as two bits). Simply set the pin states high or low to drive the arduino.
Note: Relay channels are turned off during Robot disabled mode, so you can only use them once the robot in enabled (in autonomous or teleop). However, Digital IO pins are active during disabled, so you can use them at all times. We personally use DIO pins to drive our arduino so we can convey different things in our lights during disabled mode (light whether the drivers selected a 1 ball or 2 ball autonomous, or if they lined up properly and are seeing a hot goal before the match starts).
Quote:
Originally Posted by gappleto97
4) if either the answer to 2 is no, or the answer to 3 is sufficiently complicated, is there a way to set all outputs to false upon disable? This was the problem we had with our current setup, and if this could be solved, there would be no need to switch over to Ethernet.
|
Use DIO pins. Relay Pins and PWM pins are off during Robot Disabled Mode. Digital and Analog IO are still active and can be used. They are never allowed to control robot actuators so this is still safe and is the reason they are not deactivated. If you want all pins to be false during disabled, add code to the DisabledInit() block to set all pins to low. (Pins are set high by pull up resistors by default).
Quote:
Originally Posted by gappleto97
5) is an extension of three. If we were to use a Raspberry Pi for our vision tracking next year, which I can work on nearly immediately, how do I send the information to the cRIO? I would prefer for there not to be anything on how to do the actual tracking in here, however. I like a challenge.
|
Use a TCP stream. We have done something similar this year. We use a Beaglebone for Vision processing and created a bi-directional TCP stream to send information back and forth between the Robot and the bone. When developing this stream, make sure to use multiple threads on each side of the link. At least one thread to send, and one to receive data on each side. This will prevent any blocking. Also make the Robot the server, and the Pi the client. This way when they start up, and the Pi isn't connected, the robot is not doing any additional processing to find the client, all it does as the server is listen until a client requests a connections. You don't need to do it this way, I just think it is the path of lease headache.
Quote:
Originally Posted by gappleto97
6) how do you wire encoders into the system? It's just that simple. What ports where? Etc.
|
Encoders are Digital sensors. You simply provide it power and ground from the Digital IO pins, and then plug in the signal wire into the sig port on the digital side car. If you have a quadrature encoder, you will need to use two DIO channels, One will provide power ground and the first signal in, the second channel will be used for the second signal in, with the power and ground ports unused.
Quote:
Originally Posted by alexander.h
|
Glad to see this stuff being used.
I hope it helps. We will be coming out with a lot more tutorials in the off season for the 2015 control system since we have the privilege/honor of being a 2015 Alpha Test team.
Hope this helps,
Kevin