|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#181
|
||||
|
||||
|
Re: New Talon Speed Controller
The nonlinearity of the 884 is largely due to the 150Hz output PWM switching frequency.
|
|
#182
|
|||
|
|||
|
Re: New Talon Speed Controller
If there is ever a redesign of the Talon board and case, it would be nice if there was a separate plug in for the fan. Stacking the 2 power connectors is irritating.
Not a big deal but would be nice. As to fans, teams just put one on. If there is a problem with the Talon it will probably be thermally related. The cooler the heat sink the better the heat will flow out of the chips. Veteran teams should have a box of 40 20 mm fans from previous years. Just need 2 screws and 2 terminals. Easy. |
|
#183
|
||||
|
||||
|
Re: New Talon Speed Controller
You're going to need to stand the fan off too. The idea is to keep the air circulating, not necessarily draw the heat straight out
|
|
#184
|
|||||
|
|||||
|
Re: New Talon Speed Controller
Looking forward to getting my hands on some Talons. They are being shipped now.
|
|
#185
|
||||
|
||||
|
Re: New Talon Speed Controller
I'd be wiling to pay $75-100 for a CAN enabled controller but footprint is super important. Something slightly larger than the Victor would be acceptable, the Jag is too big.
|
|
#186
|
|||
|
|||
|
Re: New Talon Speed Controller
Quote:
As one of the few 10% who use CAN and have been using CAN since our championship year in 2010, I would be all for this. However its not the interface in which we are looking a rather it is the data and the bidirectional functionality that makes us use Jags. Even though Jags are 'big and fat' compared to the Talon/Victor, the fact that we can pull a ton of telemetry off the Jag plus do a simple PID (a nice addition.) is what separates it from the Victor/Talon. In 2010 we were using current feedback from the Jag to identify if we had a ball or not. Essentially we got a lot more versatility off the Jag/CAN bus other than just commanding motors. In addition, one interesting thought would be a redundant control path. Since most teams stay away from CAN due to potential reliability problems(only year we had an issue was traced to a 775 case short) What would the prospects be to putting a redundant PWM/CAN interface ie. if CAN messages die, the motor controller can still be controlled via PWM. (disclaimer.. I work in the space industry so redundant paths are usually a must) Bottom line, if you could put a talon with CAN + similar telemetry data in a better form factor, (even with a larger footprint) I would jumping and singing for joy. Oh yeah also make the hole spacing a nice number! |
|
#187
|
||||
|
||||
|
Re: New Talon Speed Controller
Quote:
|
|
#188
|
|||||
|
|||||
|
Re: New Talon Speed Controller
Quote:
|
|
#189
|
||||
|
||||
|
Re: New Talon Speed Controller
Quote:
Some features that I know I'd like to see on the CAN Talon: - Keep the analog & encoder inputs. - Redo the limit switch inputs to make them more intuitive and easier to understand for people that aren't on the electrical team. - Allow controllers to communicate with each other more in-depth; namely, allow sensor input (specifically encoders) to be duplicated (in the CAN) between controllers. This has been a problem whenever teams have Jags on motors that feed into a gearbox that only has one encoder, since the encoder has to be read through the DSC, and then passed to the cRIO and then back to the Jags. - Allow controllers to double as sensor interfaces - the closed-loop feature of the Jags was nice, but it would've been nicer if we could've read the sensors feeding into the Jags in our code. |
|
#190
|
||||
|
||||
|
Re: New Talon Speed Controller
Quote:
However, I agree 100%. The reason we have never switched to CAN is because of the reliability issues some teams have had. We've Beta tested CAN on our robots with no problem, but right or wrong, I see PWM as a more robust option. Is there a quick way to troubleshoot CAN, short of plugging in a computer and polling the devices? I.e. - is there a LabVIEW VI for the dashboard that shows each device and it's communication status? |
|
#191
|
|||
|
|||
|
Re: New Talon Speed Controller
Quote:
You are correct with the rules. I agree though that it would be a tweak in the rules. Just as long as they can show good compliance to the robot safety side. As for the CAN reliability, we have some issues with the CAN bus but not tons. The biggest issues include some of the Jags losing ID's, some 2CAN boot issues. But it is obvious that others have had many more issues. Our Debugging usually consists of rebooting the 2CAN then checking the 2CAN page to verify all the Jags. In my mind CAN is a widely used Bus standard why FIRST cannot make it reliable is beyond me. Quote:
|
|
#192
|
|||||
|
|||||
|
Re: New Talon Speed Controller
Quote:
|
|
#193
|
|||||
|
|||||
|
Re: New Talon Speed Controller
All my opinions on how CAN should be implemented:
-Speed controller should have a pair of connectors which are easier to wire properly than. I'm not a fan of RJ11's. Some positive locking connector would be nice, but the 3-pin header style would work as well. You could choose to connect through the two connectors, or make your own splice inline (this would help with reliability if a single connection comes out, assuming your splices are well done). The bus really doesn't care about 6" splits. -Speed controllers should require enable signal to operate, it should be a different and reserved message ID. This should only affect the status of the output and reset the integrals, nothing else (you should still be able to send commands, read sensors, command gains, etc.) -Software on controller side should be architected to pass CAN messages between the application and the CAN bus, restricting the reserved enable message and sending it itself, but otherwise doing nothing. Also, it seems reasonable for each speed controller to get it's own group of CAN ID's. -The user software on the controller side should never block-wait for anything, ever. -Basically, if there are any errors, or a speed controller is disconnected, then you loose only that controller and go on, and it's no worse than where we are when a PWM cable comes out. The CAN cable coming disconnected from the 2can would be like the DC37 connector coming loose, it's a single point of failure that we already have, but it's just one point and not a point at every speed controller that can kill the entire bus. I really do like CAN, just not the way it's implemented now. I read over the LV implementation and I was really really really really horrified by some of the things they did. It block-waits for an Ack every time it sets a motor speed! For every motor! *gasp* Why should it care if the motor got it if it's going to send the motor something else in 10ms? If it times out at 10ms, and you have two motor controllers off-bus, then you will use up all of the 20ms loop interval waiting for two controllers to Ack when they will never Ack, and when you loose 5, then you've already missed two loops just waiting for controllers to never send you stuff! This is why blocking waits are bad! |
|
#194
|
||||||
|
||||||
|
Re: New Talon Speed Controller
Quote:
|
|
#195
|
|||||
|
|||||
|
Re: New Talon Speed Controller
Block wait.
The Netcomm library (black box compiled code) includes a Read and Read Async function. Read is fed a message ID and timeout, and returns either 8 data bytes or failure after no more than timeout. So, the function is blocking. Read Async is fed a message ID and Occurrence. The VI then does a Wait On Occurrence with timeout specified, if the Occurrence is triggered then it calls another function to retrieve the data. This function is not blocking at a Netcomm level, but is blocking at a system library level (Lower than the exposed CAN message interface is the Netcomm interface which is used by the CAN message interface). Since WPIlib generally pushes teams to put all of their code in Teleop or Timed Tasks, putting a blocking read command in Teleop and having it fail is very bad for deterministic Teleop timing (which is already really jittery because it's timed by Ethernet packets). It gets even worse with multiple jags, or multiple commands per jag (e.g. Set Speed and Get Current would both block-wait, if that jag goes offline then there's 20ms of timeouts just for that one jag to be waited through by the user code). Basically, all of the CAN send-response interactions are all synchronous, which is a huge time penalty over an asynchronous architecture if it ever has to wait for a response and dosen't get it. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|