The tangobot's discuss from ekumenlabs

Master on shutdown

Check what happens when running master on device and shutting down the app

Quick launch Readme / tutorial

Improve readme to provide instructions to quickly launch the robot without needing to build the whole app.
Create a tutorial in roswiki with similar instructions.

Extrinsics publisher improvement

#63 adds a basic implementation for extrinsics transformations publisher.

It would be better to publish these transformations by reading some YAML files instead of defining them using code.

Note: This is different to the robot state publisher as it uses tf_static to publish the robot frames, and move_base (costmaps in particular) needs the transformations in tf.

Map server - Read from real map

#64 adds a basic implementation for a map server.
This should eventually be replaced with a module that reads an actual image with metadata.

For a first version, reading an image from app resources would do.

Make odometry source configurable

Currently, the code uses the odometry coming from Tango using tango_ros_node.
For testing and comparison purposes, it would be good to be able to choose from Tango odometry and wheel odometry provided by base_controller.

Test TangoRosNode in separate app

Test the application with base_controller only, running along RosApp.

Publish a version of map_nav that can be used with Tangobot

Some applications in rosjava/android are available to visualize the robot in a map and send goal poses. map_nav is a good candidate, but it is outdated, and depends on packages that are outdated too in ROS kinetic.

A detailed description of the problems that the application currently has can be found here.

We should discuss and decide if it is worth the effort to get this application refurbished, or if there is a better solution for the problem.

Investigate Snakeyaml

To load configuration parameters from yaml files, Snakeyaml library seems to be a good candidate.
There are artifacts available on Maven: Snake Yaml Maven.

If the library fits the application, the problem of configuring the nodes can be considered as solved (see discussion in #10).

Test with running the ROS master on the device

Navigation stack libraries version

The roscpp_android environment uses a fixed version for move_base and its related libraries (costmaps and planners), which are detailed in its rosinstall file.

These libraries are not the ones used in the current Kinetic release, which are the ones used for the standard turtlebot setup. They should be updated to the current versions.

Navigate on Linux with Tango data

To test the navigation stack on Linux, the starting point will be an operational navigation stack running with data coming from a simulator (such as Stage or Gazebo). Then, the simulation shall be removed, and the data inputs shall be replaced progressively with real data coming from a Tango device.
These are the steps to follow:

Run a fully operational Nav Stack on Linux using simulated data (Stage) - Step 0.
Remove the simulator, and use wheel odometry as input to move_base and the visualizer (RVIZ). Use a clean map. - Step 1
Use Tango odometry instead of wheel odometry. See #15 . - Step 2.
Use Wheel and Tango odometry in an effective manner (perhaps correcting wheel odometry with Tango odometry. Only if necessary).
Add Tango Point Cloud for obstacle avoidance.
Add a Map
Solve localization problem. See #13 .

Use latest or released version of usb_serial library

The current version of the usb_serial library is a copy from an older version of the library.

Get the current version (or a released, numbered version) and adapt the application so that it works with it.

USB Serial Library to Maven

Upload USB Serial Library to Maven (contact owner).
The USB Serial Lib code shall be removed from this project, and the proper Maven dependency shall be added to build scripts.

Executing Launchfiles with ROS Master running on device

From #8:
When a launchfile is executed from the computer, the following error appears:

load_parameters: unable to set parameters (last param was [None]):  <Fault 0: 'No such handler: system.multicall'>

This happens even with simple launchfiles like map_to_odom from navigation_setup.

This requires further investigation as it doesn't make running the demos possible.

Cross compile move_base

This package is the main component of the navigation stack, so it requires special attention.
It consists of many plugins, which have to be cross compiled:

Implement 'auxiliary' nodes of move_base in Android

The navigation stack also uses some nodes which are smaller than move_base; some of them are required, others are optional.

Required:

TF extrinsics publisher
Map Server
Base Controller

Desirable:

Velocity multiplexer
Velocity smoother
Safety controller

Optional:

Diagnostic aggregator (monitoring)
Joint state publisher (probably not required, research pending)

Not required:

Robot state publisher (transformations between frames taken from robot description). This one is required by the RVIZ, so it can be considered as part of the Linux visualizer.

Tango status light stays green when core crashes

Check if there is a way of catching this error and upstreaming it to the GUI in the released version of tango ros node.

USB permission confirmation dialog always displayed

Check if the checkbox of "don't show this again" can be fixed so that the USB permission doesn't need to be granted every time the app starts.

Remove dynamic reconfigure from helper scripts

To run the demo completely on Android, the parameter server should be configured without the help of scripts from Linux.

Add Tango Node as new library to project

From Intermodalics App.

Publish TangoRosNode to Maven.
Remove local code.
Correct remaining details (we are using a slightly old version) and add new dependency.

Share maps across Android devices

This is a feature that the Android client application shall have.

App design - Parameter configuration

Some parameters should be configurable from within the application. Some of them are:

Odometry source (Tango / wheels)
Nodes to execute
Custom Master Chooser (it would be nice to skip the default one and use something that saves the configuration and applies it automatically like in Tango Ros Streamer)

Static tf publisher to Rosjava

#63 adds a node that is capable of publishing given transformations to tf, just as the native version for static tf publisher.

This could be an interesting contribution to rosjava; it would be nice if it could read what to transform from the parameter server or Yaml files.

Navigation stack behavior for baseline configuration

The standard turtlebot running on Linux with and empty map and wheel odometry behaves different than the tangobot running the navigation stack on Android with the same configuration (Navfn & DWA local planner, standard launchfiles).

In particular, it takes more time to reach a given goal (slower movements), and it may get stuck when a goal is given behind the robot, oscillating to both sides until it aborts all plans.

These differences require further investigation.

#44 describes one of the possible causes for these differences.
#46 describes a way of analyzing the differences.

Robot Localization

The standard Nav Stack uses AMCL to localize within a map using a laser scan.
The Tango Point cloud can be transformed to a laser scan, but perhaps there is some other way of using Tango features to solve the problem of localizing the robot relative to a fixed frame in a map more efficiently, given that the Tango device can be localized accurately with respect to the start_of_service frame.

Upstream ParameterLoaderNode latching mechanism

#41 implements a simple latching mechanism to prevent other nodes from starting and consuming parameters that were not yet loaded.

The definite mechanism to prevent this should be discussed and implemented before upstreaming the changes to rosjava.
Another candidate to archive the same goal would be a callback after all the parameters are loaded.

Node configuration

Many nodes of the Nav Stack (mainly move_base, but also others like robot state publishers with its descriptions) require to have access to several configuration parameters.
In Linux, this problem is addressed using launchfiles, which are not available in Android environments. Then, some other way of configuring nodes has to be implemented in Android to solve this problem.

One possible option is to create a node that reads configuration files and updates the parameter server, emulating launchfiles.
Another option is to configure the nodes by using code directly (perhaps faster to implement, but less flexible).

Add "local" flag when running master on device

Currently, the UI shows the device's IP when running the master on device.
Add a text indicating that it is actually running on device next to the IP.

Roadmap

This issue is to keep track of high level tasks required to accomplish the final goal: a robot that navigates with an application running completely on an Android device.

Base Controller to Maven

Upload Base Controller package to Maven, and add as a dependency in application package and remove code from repository.

Depends on #1 . It is desirable to solve #16 before uploading the package too.

Topic remapper

The current demo running the navigation stack on the computer uses a helper script to remap topics, which runs a node that subscribes to the source topic and publishes the same information to a target topic. This is required because the move_base launchfile belongs to a turtlebot package, which remaps cmd_vel by default.

It would be good to remap the cmd_vel in a more efficient way. One way of doing so is using a proper mux, like in the std_turtlebot example.

Robot model flickers in RVIZ

Check if this is a problem when sending goals / if it can be fixed.
It may be related to robot joint state publisher (which publishes the TFs for the wheels, and is a standard turtlebot component that publishes at a lower rate).

ParameterLoader to RosJava

Contribute ParameterLoaderNode to android_extras or some other public repository (to be defined).

Licence

Apache Licence can be inserted at the beginning of each of the source files (the same used for Tango Ros Streamer.
@adamantivm is that licence ok?

Clean-up and upstream RosJava NativeNodeMain interface

Currently the class extending NativeNodeMain reports an error through a custom means.

Find a more generic way to expose an error message and upstream to rosjava. Candidate: implement onError

Test: Navigation with Tango odometry instead of wheel odometry

To perform this test, some frame transformations have to be published into tf topic to correct the frames used by the Tango device and the required ones by move_base.

In particular, the Tango devices uses "start_of_service" and "device" as frames of reference, which need to be mapped to "odom" and to the robot frame.

#18 addresses this problem with some helper scripts, which take in the data published by the Tango Node, and republishes the required information.

The test result is successful: move_base can drive the robot properly using Tango odometry. The result can be visualized in RVIZ.

Create tutorials

Create detailed tutorials in roswiki to get a tangobot setup running (detailed as Turtlebot tutorial).

Easy setup tutorial (blind / empty map) - See #56
-- Check rosdep installation
-- Source workspace
Advanced tutorial
-- Map and sensor reqs TBD

Improve base_controller

A general review of the code should be performed. The module has some details that can be improved without an excessive effort.

The basic code publishes the odometry at 10 Hz using standard thread functions. This can be improved using higher rates and ROS Rate functions. The rate could be configurable too.
Some of the transformations being published are not necessary (e.g. laser_link).
The basic code publishes odometry using base_link as its target frame. The name could be configurable somehow (for example, publishing base_footprint proved to be useful in tests).
General cleanup of "To Do"s.

Investigate possible performance problem on Android when using Tango node

When using Tango odometry, a message saying that the controller couldn't reach the desired frequency appears in rosout (even if that frequency is as low as 5 Hz).

Check if this is a problem in the navigation stack behavior.

Snackbar for settings on first run

Add a snackbar to go to the Main activity on first run (currently, the "back" button has to be pressed and its confusing for a user).

Test differences between Linux and Android versions of move_base

A rosbag can be recorded using Linux stack, and then feed the input streams to a move_base node running on Android. The differences in the results shall be analyzed.

Support for Lenovo Phab2 Pro

Test if it works as is or if there are modifications to be done.
To be able to use this device, a mount support needs to be built (e.g. 3D printed), and the extrinsics need to be corrected in the app (and configurable to use Tango Tablet as well).

Test and file any bugs found
Design and 3D print a mount
Create extrinsics configuration for Phab2 Pro sensors with provided mount
Update wiki with hardware instructions alternatives for the Phab2 Pro

Racing condition for Parameter Loader

ParameterLoader runs in a thread separate to the main one, and while it's loading the parameters, move_base node may start and attempt to look for the required configuration.

Some mechanism needs to be implemented to ensure that the parameters are loaded before the nodes that consume them are launched.

Remove local base controller

The base controller module's source code is publicly available, so all the modifications for this project shall be properly contributed to base controller's repo.
The source of the module shall be removed from this project so as not to replicate existing code.

Upstream Master Chooser settings activity to Rosjava

The MasterChooser integrated with the settings activity could be a good candidate to upstream to RosJava.
The layout xml file has to be modified so that in can be included anywhere for that purpose.

Supported ABIs

When I tried to add arm64-v8a, I got an error from Gradle saying that it is not supported.
Apparently, compileSdkVersion has to be upgraded to 21 to make it work. When I upgraded it, I got a compilation error coming from roscpp_android_ndk (some header file that was not found). I probably will need to recompile the ROS packages adding the new architecture to make it work.

I also read that for Coconut devices, armeabi-v7a seems to be fine (see here).

We should decide at some point if it is worth upgrading the sdk version and solving that compilation error to add arm64-v8a to abiFilters in gradle configuration.

ekumenlabs / tangobot Goto Github PK

tangobot's Issues

Recommend Projects

Recommend Topics

Recommend Org