|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
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: 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)? 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? 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. 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. 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. 6) 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. |
|
#2
|
||||
|
||||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
Quote:
|
|
#3
|
||||
|
||||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
Any of your questions about using Jaguars via CAN can be answered at 2168's website : http://team2168.org/index.php/resour...10-can-jaguars.
|
|
#4
|
||||
|
||||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
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.
|
|
#5
|
||||
|
||||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
4) depending on which Robotbase you use you can either set all the outputs to false in DisabledInit() or in Disable().
5) 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. |
|
#6
|
|||
|
|||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
1) 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)
2) No, it won't. 3) Probably by sending data over a UDP port. (not 100% sure since my team hasn't attempted this, also not sure about implementation semantics). 5) 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. |
|
#7
|
|||
|
|||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
Quote:
|
|
#8
|
||||
|
||||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
Quote:
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. |
|
#9
|
|||
|
|||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
6. 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. |
|
#10
|
|||||||
|
|||||||
|
Re: Looking at trying new things for next year. Fits into electrical and programming
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:
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:
Quote:
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:
Quote:
Quote:
Quote:
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 Last edited by NotInControl : 15-04-2014 at 14:03. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|