vibrotactile system ann - needle steering teleoperation with omni
if integrating ros into XXX libraries also interested in what you have to do to create your own package
wisit - general interest john - general
plugin type structure, take what other people have done, make it a plugin type thing
provisions for other comm schemes start ros core
nodes - topics - published by nodes, nodes spit it out any other node can subscribe to the topic master negotiates tcp connections to pass data back and forth each node doesn't need to know the other system, just topics
set to run across multiple computers
however for realtime stuff, tcp is not good because not deterministic udp might be better, esp for haptics stuff
nodes should be able to get messages at speeds up to badwidth limits.
can timestamp
not sure how real-time ROS is most people don't use it realtime
nodelets if you have lots of data that needs to be moved, don't use TCP
reduce data bandwidth
stacks -> packages -> nodes stack is a collection of packages package may have a hardware node and a gui node
manifest.xml - tells ROS
user friendly, c-code, make files but controlled in the manifest dependencies - other packages it requires type ros make packages
status.msg - from the hand
header - one that's been created time stamp, sequence number can contain all different data types if you put it as an equal it will be compiled, not sent as a message, but still available it gets compiled to a python file with all the functions
if you have hardware - may be packages for omni node will publish a topic with messages containing the important information another piece of hardware can subscribeto thta
other thing is services, where you set some parameter and want to see that it changed separated the service request from the response with the three dots setparams.srv
communication is still over TCP
services vs topics are like polling vs broadcasting.
actionlib - you want to do something and it's going to take a bit of time
- it creates automatically some messages - request to do something - feedback set of data - result when it finishes - like interrupts
c++ or python
if __name__ == main:
try:
rospy.init_node('modbus_rtu')
node = adaptivegrippermodbusrtu()
if node.initialized:
rospy.publisher('name',class) rospy.service('name',class) actionlib.SimpleActionServer
self.hand)pub.publish(self.hand)
rospy.serviceproxy('name',class) rospy.subscriber('name',class,hook) import roslib; roslib.load_manifest('adaptive gripper')
pyside is better than pyqt, more support
param_client(speed, force)
if you listen to a topic that is not published, no problem if you try to set up a service proxy for a service that doesn't exist, fail.
way to set parameters from the command line there is a ros parameter server rospy.get_param('~device','/dev/tty50-') namespacing 'topic/subtopic'
Hand and Sensor specifics
packages fo rthe hand itself and packages for the tactile sensors
Sensor suite
each section has 12 taxels, middle phalanx has 8 there are some on the tips, but they don't work no calibration, sensitivity is different hasn't mattered for barrett as much depending on what's going
to start ros run
roscore
there are naming and structure conventions on the ROS website
when you start a node up there are some parameters to think about
rosrun executible.py ~parameter means private to that node looks for a parameter with nodename.parameter the way you set a private parameter via commandline is _parameter rosrun TactileSensor TactileSensorNode.py _device:=/dev/ttyUSB2 _taxel_map:=[1,2,6,7] taxel map is the four taxels you want to pull out of the device, corresponding to locations to set things use :=
there should be solid green lights on the sensors everywhere except for a slower .5Hz blink - idle 1Hz blink - streaming tx/rx light as well reset buttons on each board when it first starts up, boards will be red. reset finger boards while holding down main board reset
ROS has a lot of built-in diagnostics rostopic list rostopic bw topic - tells you how much bandwidth you're using rostopic hz topic - tells you what your rate is. rostopic echo topic - streams all the data to your screen
TactilePressure.msg
thumb index middle out to in to palm
TactileAccel.msg
pretty much the same
TactileStatus.msg
tells you where stuff broke if some i2c chip isn't responding, this will tell you everything should be zero if everything's working
Salomon J. Trujillo memorial corner
"he kept it warm for us"
you can tare the sensors
using actionlib stuff built on top of messaging structure, request message -> goal -logic -> response
actionlib.simpleactionclient(topic,class)
action client sends goal to actionserver tare.action
goal result feedback hooks come back for every step along the way
gui node
using pyside filtering, averaging, color map,
hand
rosrun adaptivegripper serial rtu.py _device
rostopic list - lists all the topic names
status handstate fingers command is an actiontopic server name, autogenerates internal sequence topics mapped straight out of the data sheet
services - setparams
force speed clear errors
any time you want the hand to do stuf, it's an action, actionserver stuff
because it takes a while
weird things he tried to fix
hand will not close while reconfiguring. if you try and do something it will send an error
if actionserver gets two goals, actionserver is responsible for choosing what to do. Doesn't work exactly right, but the hand works and then you clear the error
gui
must initialize or you get an error.
two service proxies
clear client set params
SendModeCMD
robot
High level overview On adept side
Programs on the adept side that parse serial stuff and then run the commands
Talk via serial
Before you were sending tcp packets Adept is meant for pick and place, move here move here, rounding of corners, acceleration profiles Alter is a facility that goes as fast as the server loop
So if you can send it the stream of commands AT THAT RATE, then you’re able to do realtime update stuff
Barrett doesn’t care about that, uses built in move command in xyz Anything outside has to go through this pc Look through code on adept sicdde
Reading in serial looking for start bytes, reading data through to stop byte, and then parsing data and doing what the packet tells it to do
You give it a command in Cartesian, and it turns it into joint angles, makes sense because it knows it’s transformations to do that Mostly the manual and code Request configuration Messages: Move x,y,z,yaw,pitch Speeds, linear, rotational & acceleration from 0--100 Tool offset 100mmz default Request config()->joints and forward kinematic config Request Status(adept status info)
To run you have to enable power and calibrate, then you can run any programs .en po .cal y .cal
In ros, three topics Rostopic list Config which is work space config xyz,yaw pitch Joint is joint angles Status – at a particular rate, splitting into config and joint
Roservice list /adept Adept/move adept/set_offset adept/set_speeds
Rxgraph shows you nodes, connections, services, topics,
Adetpt lets you do changes at 16msec cycle Run with different priorities ‘realtime’ would require a big change in realtime