RoCKIn2014

RoCKIn Camp 2014

• Project Name:

• Official Web Page

RoCKIn@home 

• Project Codename

Watermelon

• Advisor:

Vicente Matellán Olivera

• Staff:

Technical software: Fernando Casado
Technical software: Víctor Rodríguez 
Technical software: Francisco Lera
Technical hardware: Carlos Rodríguez

• Other Information:
• Academic Year: 2013-2014
• SVN Repositories: soon...
• Tags: Augmented Reality, Elderly people, Remote-Assistance
• Technology: ROS, PCL, c++, svn, OpenCV, cmake, OpenGL, Qt, Aruco,
• State: Development

Project Summary

This challenge focuses on domestic service robots. The project aims to create robots with enhanced networking and cognitive abilities. They should be able to perform useful tasks such as helping the impaired and the elderly (one of the main goals of our group).

In the initial stages of the competition, individual robots will begin by overcoming basic individual tasks, such as navigating through the rooms of a house, manipulating objects or recognizing faces, and then coordinating to handle house-keeping tasks simultaneously, some of them under natural interaction with humans.

Robot

We want to take part in RoCKIn with the platform developed during the last two years in the Catedra Telefónica-ULE.

MYRABot robot.

Robot Hardware

1. iRobot Roomba 520
2. Dinamixel Arm (5x12a)
3. Wooden frame (yes, it is made of wood)
4. Notebook (Atom processor) (the display has been taken apart from the main body)
5. Kinect
6. Arduino Mega

Robot Software

1. ROS (robot control)
2. MYRA (C/C++, ArUCo, Qt, openCV)

Proposal

We want to develop and deploy minimal functional abilities to be part of RoCKIn 2014.

• Navigation
• Mapping
• People recognition
• Person tracking
• Object recognition
• Object manipulation
• Speech recognition
• Gesture recognition
• Cognition

We are going to separate the development in three phases:

1. Phase I: Initial Setup
2. Phase II: Integration and architecture
3. Phase III: Platform test
4. Phase IV: Improvements and complex tasks
   1. Technical Challenge: Furniture-type Object perception
   2. Open Challenge: Exhibit and demonstrate the most important (scientific) achievements

Phase I: Initial Setup

Outline: Tasks developed in this phase

Phase II: Integration and Architecture

1. Multiple kinect cameras in a PC

In this task we tested how to launch two different openni cameras in the same computer. This is an easy task if you know the shortcuts :D

Problems outline:

We have two differents cameras Xtion PRo and kinect.

The typical problem with Xtion pro model:

We launch

$ roslaunch openni_launch openni.launch

we get

[ INFO] [1383245066.923739155]: Number devices connected: 1
[ INFO] [1383245066.923896787]: 1. device on bus 002:05 is a PrimeSense Device (601) from PrimeSense (1d27) with serial id ''
[ INFO] [1383245066.925020672]: Searching for device with index = 1
[ INFO] [1383245067.026459550]: No matching device found.... waiting for devices. Reason: openni_wrapper::OpenNIDevice::OpenNIDevice(xn::Context&, const xn::NodeInfo&, const xn::NodeInfo&, const xn::NodeInfo&, const xn::NodeInfo&) @ /tmp/buildd/ros-fuerte-openni-camera-1.8.6/debian/ros-fuerte-openni-camera/opt/ros/fuerte/stacks/openni_camera/src/openni_device.cpp @ 61 : creating depth generator failed. Reason: USB interface is not supported!

SOLUTION:

We have to modify global parameters of openni:

$ sudo vi /etc/openni/GlobalDefaults.ini

We go to line and uncomment the UsbInterface parameter:

; USB interface to be used. 0 - FW Default, 1 - ISO endpoints, 2 - BULK endpoints. Default: Arm - 2, other platforms - 1
UsbInterface=2

Reason:

Here and here but I think that the real reason is related to USB port management

From my point of view this is the outline (copy paste from USB port management

ENDPOINT -> The most basic form of USB communication is through something called an endpoint. A USB endpoint can carry data in only one direction, either from the host computer to the device (called an OUT endpoint) or from the device to the host computer (called an IN endpoint). Endpoints can be thought of as unidirectional pipes.

1 ISO-> Isochronous endpoints also transfer large amounts of data, but the data is not always guaranteed to make it through. These endpoints are used in devices that can handle loss of data, and rely more on keeping a constant stream of data flowing. Real-time data collections, such as audio and video devices, almost always use these endpoints.

2 BULK-> Bulk endpoints transfer large amounts of data. These endpoints are usually much larger (they can hold more characters at once) than interrupt endpoints. They are common for devices that need to transfer any data that must get through with no data loss. These transfers are not guaranteed by the USB protocol to always make it through in a specific amount of time. If there is not enough room on the bus to send the whole BULK packet, it is split up across multiple transfers to or from the device. These endpoints are common on printers, storage, and network devices.

0 FW [WARNING, I'm not sure]-> USB interfaces are themselves bundled up into configurations. A USB device can have multiple configurations and might switch between them in order to change the state of the device. For example, some devices that allow firmware to be downloaded to them contain multiple configurations to accomplish this. A single configuration can be enabled only at one point in time. Linux does not handle multiple configuration USB devices very well, but, thankfully, they are rare.

Non-Critical (but to-do)

1. Android/iOS Teleoperation
2. Desktop Qt interface
3. Create robot model for Gazebo
4. Create robot model for rviz (the same as Gazebo?)

Wishlist

• Computer with i7 processor, 8GB RAM, Nvidia GPU (1-2 GB)
• ASUS Xtion Pro Live Color RGB Sensor
• Roomba battery
• Arduino Mega (x2)
• Roomba base (520, 560)