You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
I propose the following:
The text was updated successfully, but these errors were encountered: