|
Re: CAN Nerf Robot
One way to do it might be to schedule periodic status updates, so that the "get" VIs just get the last data that was acquired by the bridge. You could have an option on every function: request new data or retrieve current data. That way you could avoid the awkwardness of sending a message in one place and retrieving data in another.
It's true that error messages would have to be put somewhere else, but they should be anyways, shouldn't they? The errors are to tell you that something isn't working with that Jaguar, not to slow down your code or prevent things from executing. With the current implementation, the errors show up on your driver station, but all they do in code is keep data from being sent to that controller. Say one of the motor controllers for you drivetrain isn't working. You don't just drive normally like it isn't happening; you try to counteract the issue of your robot skewing to one side. With PWM, unfortunately, the robot controller can't detect that the motor isn't running how it should (other than "hey, that wheel isn't moving"). With CAN, the problem is very apparent, and the robot controller is very capable of dealing with that if you have two motors per side. (make the fully functional side go slower)
More centralized error handling would help this, because you could look up the controller in a registry and see what its current state was, and deal with it accordingly. (This is what my CAN Manager attempted to do, but it had very poor performance due to the current implementation of CAN)
__________________
-- Marshal Horn
|