Joystick driver does not kill motors kill switch released.

[kegilbert]

Joystick controller uses button 5 for a dead man's switch. When released though it retains the latest motor values (if you were going full speed forward and let go of the controller, it will continue going forward). Line 38/39 in the node resets to zero if not right state, but that line is only reached through the preceding if-statement that checks right_state. At least that's what I seemed to notice through my limited usage of it and cursory glance of the node, let me know if there is no actual problem and I can't science.

[robz]

Yeah, that's about what I experienced when driving it around at ExploreUT.

That if-statement that checks the right_state also guards against publishing messages. The logic is a little difficult to interpret because I don't know what each byte in a packet means, but I believe the node will not publish anything unless 5 is held down. When nothing is published to /vel_cmd, no commands should be sent to the ucontroller. With granny, the PSoC had a timeout to stop the motors if it stopped receiving data from the computer. Does the launchpad or launchpad driver have similar behavior?

[robz]

By the way, we might want to look into using a ROS driver for the joystick instead of our own: https://github.com/turtlebot/turtlebot_apps/blob/hydro/turtlebot_teleop/launch/logitech.launch

[weng-frank]

Immediate recommended fixes:

1. in output()
   rate = rospy.Rate(rospy.get_param('~ouput_rate',10.0))
   while...:
   ....
   rate.sleep()
   (Instead of time.sleep)
2. In init()
   t.daemon = True
   (Before t.start(). This is to help the program die properly.)
3. Alternatively to 1+2, use a rospy.Timer http://wiki.ros.org/rospy/Overview/Time
4. Use python struct to interpret the incoming data http://docs.python.org/2/library/struct.html

[weng-frank]

That package will be quite a bit more bulky, but also complete and easier to interface to.

[weng-frank]

As for other fixes, a watchdog on the embedded is fairly crucial. This drive itself can also have something like: on the event of key5 release- publish a 0 velocity message. Also, rather than having some arbitrary math function to deal with acceleration, have a simple acceleration scheme like: Joystick input controls the velocity setpoint; use a fixed max_acceleration; each control loop, move the output velocity towards the velocity setpoint at max_acceleration or setpoint-output, whichever is less.

By the way, I'm not making these changes myself, since I'd have no way of testing.

[kegilbert]

That's cool, thanks for the pointers! I can add a watchdog, and will look into the acceleration.

[robz]

so for a while, this issue was fixed by adding a watchdog to the lm4f. now it is back. the lm4f requires something to be sent to it before it sends anything back to the computer, so the lm4f node is always sending to the lm4f the last cmd_vel message received in order to get encoder info out of it. i'd recommend doing what frank said about constantly sending 0 velocity on key5 release.