Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mode to act as pure pass-through #52

Open
icolwell-as opened this issue Jun 20, 2019 · 0 comments
Open

Mode to act as pure pass-through #52

icolwell-as opened this issue Jun 20, 2019 · 0 comments
Assignees

Comments

@icolwell-as
Copy link
Member

icolwell-as commented Jun 20, 2019

Currently the driver will save all the received command messages from the autonomy side and then only send them out over CAN to the PACMod once a rate loop is triggered at 30 Hz.
While this is good for some use cases, it is also undesirable for others. Here are some of the cons of this design:

  • An actuation command sent to the ROS driver could be delayed by 33 ms (worst-case) since the driver waits until the next loop trigger to send commands.
  • Since commands are saved, the autonomy side could crash or stop sending commands, but the driver will repeatedly send the previous command to the PACMod as if everything was still functioning fine. This means the PACMod is unable to detect any timeouts and will continue operating.
  • The commands sent to PACMod driver and the commands sent down to the PACMod via CAN are not the same and do not happen at the same time. This makes debugging ROS bags quite difficult because the commands being sent into the ROS driver do not necessarily represent the commands actually being fed to the PACMod.

I propose the following:

  • An operating mode that turns the driver into a pure pass-through or message translator that operates on message callbacks to minimize any possible delays.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant