2011-10ROSNotes

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

Page last modified on October 21, 2011, at 05:08 PM