Closed PeterBowman closed 6 years ago
Linux command used to launch the serial port device (defaults):
sudo yarpdev --device serialport --comport /dev/ttyACM0 --baudrate 115200 --paritymode NONE --readtimeoutmsec 3000 --xinenb 0 --xoutenb 0 --databits 8 --stopbits 1
read configuration from .ini file split main output port into separate channels, one per robot part (wrap in
analogServer
YARP plugin?) publish outgoing data to ROS topics
These 3 could be fulfilled by:
analogServer
as in yarp-devices/libraries/BodyYarp/Jr3/Jr3.iniyarp::dev::AnalogWrapper
which can publish a ROS topic by activating the --ROS
parameter as can be seen on its documentation.Additionally:
automate port connection through .xml script file (yarpmanager?)
Yes, yarpmanager could work for this.
filter peak values (issues in data acquisition?) improve current accumulation algorithm
I'd recommend leaving these processes outside the driver (maybe that's why you are looking at port arbitration? not sure how that works with ROS topics...).
PS: A device wrapped in analogServer
can be launched as in:
yarpdev --device Jr3 --period 20 --name /jr3:o
However, in teoBase.xml#L12-L16 we have a longer version, split into channels:
<module>
<name>yarpdev</name>
<parameters>--device Jr3 --period 20 --name /jr3 --ports "(ch0:o ch1:o ch2:o ch3:o)" --channels 24 --ch0:o 0 5 0 5 --ch1:o 6 11 0 5 --ch2:o 12 17 0 5 --ch3:o 18 23 0 5</parameters>
<node>/manipulation</node>
</module>
I might be missing something, but creating a new device wrapped by analogServer
didn't make sense to me due to its periodicity. All I want is to pipe the output of one port to a ROS-capable PortReader, preferrably with channel splitting functionality as AnalogWrapper already provides. However, this driver would fetch incoming data at a fixed rate (indicated through the --period
option). At best, I'd still lose lots of bottles in the process... DevicePipe seems to accomplish what I want, but its implementation is very limited at the moment.
I'd recommend leaving these processes outside the driver (maybe that's why you are looking at port arbitration? not sure how that works with ROS topics...).
In fact, both subtasks refer to the current Lua script implementation, which still needs some polishing.
However, this driver would fetch incoming data at a fixed rate (indicated through the --period option).
I used to be concerned about losing info in scenarios like having a callback with new data (such as in this working example, with semaphores and a static callback function). However, recall that in practice, somewhere, you are going to have a control loop running at a fixed rate (alternatives are relatively uncommon). Publishing faster than that control loop provides no improvement (perhaps nyquist could make you think about streaming data x2, but not faster). Inheriting from IPreciselyTimed can also be done if deemed necessary.
In fact, both subtasks refer to the current Lua script implementation, which still needs some polishing.
Ok, I understand your intentions more clearly now. Not sure how far of a stretch it is to get a mechanism like http://www.yarp.it/type_modification.html to publish a ROS topic (or several ;-))... don't forget what I commented above as a fallback plan, and good luck!
Quick note to self: steps we follow to open serial communications with the Arduino, launch yarpscope and connect ports.
sudo yarpdev --device serialport --comport /dev/ttyACM0 --baudrate 115200 --paritymode NONE --readtimeoutmsec 3000 --xinenb 0 --xoutenb 0 --databits 8 --stopbits 1
yarpscope --index "(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42)" --min 0 --max 1000
yarp connect /serial/out /yarpscope tcp+recv.portmonitor+type.lua+file.amor_sensors_modifier.lua
For ease of debugging, this command show the numeric values corresponding to each sensor:
yarp read ... tcp+recv.portmonitor+type.lua+file.amor_sensors_modifier.lua://serial/out
I'm getting a wierd error upon connecting ports:
[ERROR]/home/bartek/Desktop/amor_sensors_modifier.lua:139: attempt to call a nil value (global 'unpack')
This was not happening a few months ago nor today on a colleague's PC, code has not changed since then. Tested on YARP 2.3.68 and 2.3.68.1.
There is ongoing work on a ProximitySensors
plugin that may cover some of these goals. See yarp-devices/libraries/BodyYarp/ProximitySensors/ (current HEAD).
This issues should be moved to https://github.com/roboticslab-uc3m/amor-configuration-files.
This issues should be moved to https://github.com/roboticslab-uc3m/amor-configuration-files.
Ref: https://github.com/roboticslab-uc3m/amor-configuration-files/issues/1
This issue was moved to roboticslab-uc3m/yarp-devices#177
analogServer
YARP plugin?)