Hi! To get introductions out of the way, I’m the head programmer (Java) of Marquette’s team 3617 Cold Logic. Next year will be the first that we’ve had more than one dedicated programmer (with the ones that helped me this year focusing significantly more on electrical, and only one actually manipulating code, on our arduino). All of these questions are for things that I would like to tackle for next year, while leaving the simpler work to my newly found sub-team.
My questions are as follows:
is there any real advantage to wiring Jags via CAN, and what differences does it make in programming (other than using the CANJaguar class)?
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?
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.
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.
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.
how do you wire encoders into the system? It’s just that simple. What ports where? Etc.
Thank you in advance for the help. I really appreciate it.
And don’t feel like you need to hold back on jargon, or complicated ideas. Programming is both my forte, and my major, as I’m dual-enrolling at the local university.
Encoders are not that hard. Let’s say you want to put them onto the drivetrain motor gearboxes, all you need to do this is place an encoder onto the gearbox shaft and connect the cable to one of the Digital I/O ports on the Digital Sidecar. This works with the present DSC. As you probably know, the DSC and the cRIO will be both incorporated into the roboRIO as of the 2015 season (https://decibel.ni.com/content/docs/DOC-30419). So more details will probably come out in Fall as to how we would use the new Digital I/O ports on the roboRIO. For more details on encoders at the present time, go to http://files.andymark.com/E4P_datasheet.pdf.
Wiring with Can is much easier, it doesn’t take up ay ports on the Radio, as it is Daisy chained to the a Can to serial Adaptor that is connected to the serial port on the cRio. The neat bit is that you can also use the BDC-COMM software and control the motors using a computer, and test various functions such as PID and Encoder values, without having to write program. The VEXPro resources for Jaguars goes into a lot of detail about that, and all the wiring of CAN.
depending on which Robotbase you use you can either set all the outputs to false in DisabledInit() or in Disable().
I have seen people do it with the digital outputs from the Raspberry Pi or you could use Serial or I2C to communicate. This could also be done for the Arduino instead of using ethernet.
The main advantage is that can set outputs with more than just % vbus.ie you can actually set outputs in terms of absolute voltage and current. You can also set speed/position commands, and assuming the encoders/pots are wired to the jaguar correctly and the PID is tuned correctly, the Jag will handle the control loop for it’s motor automatically (and probably w/ a lower dt than the cRio)
No, it won’t.
Probably by sending data over a UDP port. (not 100% sure since my team hasn’t attempted this, also not sure about implementation semantics).
Either UDP, or have the raspPi output PWM using it’s GPIO (or an actual analog signal using the audio port) and treat it like any other digital/analog signal. (You can also try I2C or SPI)
For anything related to jaguars, you should probably first read the documentation on it for more detailed answers.
I actually tried to do this, but for some reason I couldn’t modify the methods needed. I don’t remember the particular error it gave me, but I know it didn’t like the @override
Something to remember is that next year we are moving to the new RoboRIO control system. It has a built in CAN bus that doesn’t take up an ethernet port or a serial port, and there should be a new speed controller that is able to use the new connections. So questions 1 and 2 will be unknown until they release more information.
3: Over ethernet, you could send packets using UDP or TCP, and read those packets using the arduino.
4: The digital IO and PWM outputs all should get disabled upon the robots getting disabled. We just use a few digital outputs from the sidecar, and they work just fine in controlling an arduino.
5: You can use the same methods as 3. Also, if using python, you can use pynetworktables to communicate using the SmartDashboard libraries.
6: Wire power and ground, and then send the outputs from the encoders to any 2 digital inputs on the sidecar. The built in libraries will accept any 2 pins, and then you just have to set the parameters correctly to make sure it gives the right outputs.
Quadrature encoders(they know if you’re going forwards or backwards) have 4 wires. One is power, one is common(black), and 2 are signal. Colors depend on the encoder you use. Power and common get wired into one PWM cable as well as one of the signals. The other signal goes into the white of another PWM cable. Both these cables get plugged into the sidecar in the Digital IO (or next year, the robo-rio digital IO, should be similar, if what bomb-squad showed at midwest is accurate).
If you aren’t using quadrature, you won’t use an Encoder object but a Counter, and you will only have 3 wires, power, common, and signal.
My answers are based on the assumption that you will be trying to implement these ideas next year (on the new 2015 control system).
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.)
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.
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).
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).
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.
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.
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.
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.