asrob-uc3m / yarp-devices Goto Github PK

Inspiration: https://github.com/roboticslab-uc3m/asibot-main/tree/d640e9962ef62765f7354612cfcb88ed5cb3ca25/bindings

Some devices are broken (software-wise) as a result of #4.

LaserTowerOfDeath and Co. will be resurrected (no pun originally intended) once API stabilizes.

Note: EcroWheelController or EcroPwmController have been set to DeprecatedDeviceDriver at 66f12c5.

Same as roboticslab-uc3m/kinematics-dynamics#189 here:

YARP 3.4 is out and introduces an important change: Python 2 is no longer supported. Consequently, it makes no sense to generate Python 2 bindings for the asrob_yarp_devices module and later combine it with the Python 3 YARP module in the same Python script. Therefore, I suggest to update (at last) the dated CMake script we use for generating SWIG bindings (ref), mirroring whatever YARP folks have implemented on their side (ref).

FYI see roboticslab-uc3m/installation-guides@7a9134f.

@imontesino found out that the LTOD device crashes upon the initial connection check, namely while we try to read the welcome message arriving from the Arduino board:

The only change wrt previous successful executions: we replaced the Arduino Duemilanove with a Freaduino board (asrob-uc3m/laser-tower-of-death#1 (comment)). It was observed that a convenient one-second delay placed right before said lines fixes this issue. Is this a valid approach?

Import devices from robotDevastation-robots

From @jgvictores on December 2, 2017 14:33

Example compilation error:

robotDevastation-robots/libraries/YarpPlugins/LaserTowerOfDeathController/LaserTowerOfDeathController.hpp:14:26: fatal error: SerialStream.h: No such file or directory

Will happen due to:

• YarpPlugins/LaserTowerOfDeathController/LaserTowerOfDeathController.hpp:#include <SerialStream.h>
• YarpPlugins/EcroWheelController/EcroWheelController.hpp:#include <SerialStream.h>
• YarpPlugins/EcroPwmController/EcroPwmController.hpp:#include <SerialStream.h>

Copied from original issue: asrob-uc3m/robotDevastation-robots#41

Edit: see https://github.com/asrob-uc3m/robotDevastation-user-manual/blob/aa35659774f3fb7943918f04167f59a719ed4d0f/en/install-robot-devastation/robots-ubuntu.md

I've managed to command the Parrot's Jumping Sumo drone via our robot command interface, that is, I created another device that implements IRobotManager for such purpose. The code is hosted on a separate branch, just one commit so far: 455de61. I did not succeed to receive frames from the onboard camera, and this device could be further expanded to connect to more Parrot products, e.g. flying drones. Other than that, it works and has been tested on the real drone and a RD client instance, which means that we were able to command the robot via keystroke events.

• https://developer.parrot.com/docs/reference/all/index.html
• https://developer.parrot.com/docs/SDK3
• sample code from open-source Parrot developers
• some points on YARP, ports and webcams: robotology/yarp#254

From bottom of https://ubuntuforums.org/archive/index.php/t-896869.html (mujambee):

Under Unix, a serial port is a virtual file, names start at /dev/ttys0 and count up. Under Windows is the same, but names start at COM1, so to open a serial port you should use to fopen( "/dev/tty0", "r" ) under ux and fopen( "COM1", "r" ) under win. Unfortunately fopen cant open COM ports in recent versions of Windows.

Not sure how it works with streams, so you may be able to use C++ streams, you just need to conditionaly compile device names; something like:


#include <iostream>
#include <fstream>

#ifdef WINDOWS
const char pnames[][12]={ "COM1", "COM2", "COM3", "COM4" };
#else
const char pnames[][12]={ "/dev/ttys0", "/dev/ttys1", "/dev/ttys2", "/dev/ttys3" };
#endif
...
...
...

std::ifstream ifs( pnames[port_number] );


Anyway, if you are just learning C, it could be a good exercise to create wrapper functions and conditionaly include calls to fopen, fread, fclose in your unix version and OpenFile, ReadFile and CloseHandle in your Windows version.

When trying to move LaserTowerOfDeath the function tiltDown is receiving a value which is not using at all. Instead of that, it constantly moves 10 degrees down, and it is not possible to tilt up.
I think the function tiltDown should use the input value to modify tiltJointValue.

Current function:

It may be due to this commit:

ad83d1b

[IRobotManager.hpp] Think about more than mobile robots.

Note that current interface was inspired on shooter WASD + mouse-like movements.

But perhaps we want a more generic interface, such as the long-term proposal of roboticslab-uc3m/kinematics-dynamics#148.

From @jgvictores on December 2, 2017 13:52

Add travis continuous integration

Copied from original issue: asrob-uc3m/robotDevastation-robots#40

usb

In order to allow a non-sudoer to read data from the sensors connected via USB port, you need to add a rule for udev system.

Similar to the advice from debian udev documentation, create /etc/udev/rules.d/80-persistent-local-usb.rules with the following contents:

KERNEL == "ttyUSB0", MODE = "0777"

Another popular solution:

sudo usermod -a -G dialout $USER # Effect after reboot

gpio

http://wiringpi.com/wiringpi-update-to-2-29/ as commented at asrob-uc3m/hexakiller#6

note

Could be generated and installed

From @jgvictores on June 22, 2018 19:13

From @jgvictores on April 20, 2016 9:52

[cmake] Set up cross compiling for raspi

help: https://blog.kitware.com/cross-compiling-for-raspberry-pi/

Copied from original issue: asrob-uc3m/robotDevastation-robots#11

Copied from original issue: roboticslab-uc3m/yarp-devices#186

Add info on compiling bindings.

[IRobotManager.hpp] Remove unused methods

[RobotServer/FakeMotorController] dummy option always found, current develop (ec5f5a4), replicable via:

yarpdev --device FakeMotorController --verbose

Gets:

[info] DeviceDriverImpl.cpp:17 open(): Subdevice FakeMotorController
[debug] DeviceDriverImpl.cpp:12 open(): Got options: (device FakeMotorController) (dummy 123) (single_threaded 1) (subdevice FakeMotorController) (verbose)
[success] DeviceDriverImpl.cpp:16 open(): Got dummy option.
[INFO]created device <FakeMotorController>. See C++ class asrob::FakeMotorController for documentation.
yarp: Port /RobotServer/rpc:s active at tcp://163.117.150.234:10002/
[INFO]created wrapper <RobotServer>. See C++ class asrob::RobotServer for documentation.
===============================================================
== Options checked by device:
== 
device=FakeMotorController
RobotServer.subdevice=FakeMotorController
FakeMotorController.device=FakeMotorController
FakeMotorController.dummy
    check dummy option
RobotServer.name
==
===============================================================
yarp: Port /FakeMotorController/quit active at tcp://163.117.150.234:10003/
[INFO]device active in background...

Maybe related to roboticslab-uc3m/yarp-devices#175 ? (possibly not)

Been getting lots of rpio-pwm: Page 0 not present with RaspiOnePwmMotorController.

Some help:

• https://raspberrypi.stackexchange.com/questions/55421/rpio-not-working-on-pi-zero-pi2-or-pi3
• https://solenerotech1.wordpress.com/2013/09/09/tutorialhow-to-control-a-brushless-motor-with-raspberry-pi/

Seems like it's like that since Raspi v2, but had no issue because that was on https://github.com/asrob-uc3m/rd-ambassador that uses RaspiTwoPwmMotorController rather than RaspiOnePwmMotorController.

Research about wiringPi debian package

• https://archive.raspberrypi.org/debian/pool/main/w/wiringpi/
• https://github.com/hamishcunningham/wiringpi/tree/master/debian

From @jgvictores on December 2, 2017 13:41

Should create AUTHORS.md and place copyright notices at the top of source files

• Similar done here: asrob-uc3m/robotDevastation#117

Copied from original issue: asrob-uc3m/robotDevastation-robots#39

From @jgvictores on February 10, 2016 15:54

To avoid version conflict between Server/Clients Robot/Network

Copied from original issue: asrob-uc3m/robotDevastation#29

From @jgvictores on December 13, 2017 22:5

Merge IRobotManager moveForward()/moveBackwards() and similar pairs?

Move, turn, pan, tilt all get (signed) ints as signature. Could be merged to reduce the functions.

PS: I'd go for double rather than int, and document units (e.g. attempt m/s rather than undocumented notion of percentage).

Copied from original issue: asrob-uc3m/robotDevastation-robots#42

Affects:

• https://github.com/asrob-uc3m/robotDevastation
• https://github.com/roboticslab-uc3m/openrave-yarp-plugins ( libraries/YarpPlugins/YarpOpenraveRobotManager )
• https://github.com/jgvictores/2018-ptmr ( examples )