The turtlebot stack provides all the basic drivers for running and using a TurtleBot.
Home Page: http://www.ros.org/wiki/turtlebot
License: BSD 3-Clause "New" or "Revised" License
The turtlebot stack provides all the basic drivers for running and using a TurtleBot with ROS.
ROS Wiki : (http://www.ros.org/wiki/Robots/TurtleBot)
We suggest a new "linux_robots" stack or whatnot. Put things like this there.
Kobuki/Turtlebot wiki pages that are missing or must be updated. Fill free to include any issues you find in the "todo" list.
Make sure these have fuerte/groovy versioning tags where appropriate.
Keep kobuki_node as its own stack - some users may wish to build non-turtlebot kobukis.
Same case could possibly be made for the irobot'ish turtlebot_node.
Those parameters are Create/Kobuki-specific and are not directly related with Turtlebot. So:
turtlebot / turtlebot_bringup / param / create -> turtlebot_create / param
turtlebot / turtlebot_bringup / param / kobuki -> kobuki/param
Same principle as kobuki_comms->kobuki_msgs change.
Brain mentioned about the new model for tf message which helps to reduce the tf transform computation.
tf2 is a server/client model for tf messages. tf2 may help the tf transform computation in low-power system like android.
Worth to check
we should create a turtlebot_web or move this stuff to turtlebot_apps... turtlebot should have the absolute minimal deps... in fact we want to move pointcloud_to_laserscan someplace eventually..
https://github.com/turtlebot/turtlebot/blob/master/turtlebot_bringup/launch/roboworld.launch
Some thoughts:
Probably need to take care working out how to bring in the appropriate pieces for urdf's and such.
We need to make a safety controller that is compatible for both turtlebot_kobuki and turtlebot_create.
Runs fine, but doesn't connect with android.
The nodelet from openni_camera seems to be crashing alot
nodelet: /usr/include/boost/smart_ptr/shared_ptr.hpp:412: boost::shared_ptr<T>::reference boost::shared_ptr<T>::operator*() const [with T = xn::NodeInfo, boost::shared_ptr<T>::reference = xn::NodeInfo&]: Assertion `px != 0' failed.
[FATAL] [1348746869.679027201]: Service call failed!
[FATAL] [1348746869.679040401]: Service call failed!
[FATAL] [1348746869.679055188]: Service call failed!
[FATAL] [1348746869.679072983]: Service call failed!
[openni_manager-1] process has died [pid 2559, exit code -6, cmd /opt/ros/fuerte/stacks/nodelet_core/nodelet/bin/nodelet manager __name:=openni_manager __log:=/home/snorri/.ros/log/744d67de-0898-11e2-9325-6cf049781259/openni_manager-1.log].
log file: /home/snorri/.ros/log/744d67de-0898-11e2-9325-6cf049781259/openni_manager-1*.log
respawning...
Try the heavier openni_launch?
List of updates to make things groovy-ready.
Param pointing to a user's apps.installed so they can easily start creating their own apps alongside the core ones.
Less kobuki-create specifity.
This includes both the turtlebot_driver and the turtlebot_node python code, both of which should be renamed to create_xxx (or something similar).
Mel brought this up in #28 when talking about moving pointcloud_to_laserscan.
I'd like a generic robot_algorithms (or similar) stack where we can dump simple err 'robot algorithms'. Point cloud to laser scan, random wandering mode, motion patterns, gyro heading calibration/drift estimation etc.
I've got a few that we're making for kobuki (manufacturing programs) that would be perfectly usable by turtlebot and other bases, but I can't put in places like kobuki or turtlebot without wierd or circular dependencies.
Thinking for just 1s more on the topic, 'robot_algorithms' is far too generic. We're talking about simple algorithms for mobile bases here.
Causing us issues for dashboards. Currently kobuki_desktop and turtlebot_create_desktop depend on turtlebot.
Turtlebot should be on top!
Still, we need a better way of loading up the dashboards for different hardware. Consider on the way to hydro.
Previous comments from Marcus about the base_link.
Can we change the REP to define a fixed transform from
base_footprint -> camera_rgb_frame instead using the
more arbitrary base_link?Since we usually put base_link on the axis of the main
wheels for our (centred) differential drives, I added a
base_bottom_link at the bottom surface of the Kobuki.
Now, base_bottom_link 0> camera_rgb_frame aligns with REP115.If we adjust the REP this will be obsolete
such as turtlebot2 stack meshes are now in ../meshes/turtlebot2_stack.
Any objections?
Check to what extend we can unify the kinect & xtion related urdfs for both turtlebot 1 & 2.
If the camera mounting in both robots is different we could create a common kinect/xtion.urdf, which is include by turtlebot_kinect.urdf and turtlebot2_kinect.urdf (same for xtion). The robot-specific would include the mounting plate and poles.
In this process varify the calibration parameters for both cameras and in combination with both robots.
I remember we found some error in those parameters.
Looks like they recently added bump sensors to the navigation - see http://github.com/turtlebot/turtlebot_apps/commit/339f3dbf6726109460e2483906fd730f76a63151
Check it out for kobuki, we probably need to be publishing something here.
It bugs out when ctrl-c'ing.
Not a priority, maybe really not a priority if we want to replace it shortly anyway.
For the openni_camera nodelet, the yaml in turtlebot sets depth registration to true, but points show up on /camera/depth/points instead of /camera/depth_registered/points - why?
No cloud being viewed when running openni.launch
Until you initialise it properly, the initial pose is off the willow map.
Do some args magic so it avoids this for the demo.
If ROS_HOSTNAME is set, minimal.launch does not work.
I think it is the same issue that Marcus and Daniel found... roscpp issue..
It doesn't include a mesh for a mount yet, so when you view the robot model (see turtlebot/turtlebot_descriptions/readme.txt), it looks like it's flying.
Hard coded 'cmd_vel' here:
https://github.com/turtlebot/turtlebot_apps/blob/master/turtlebot_teleop/src/turtlebot_key.cpp
instead of the new '/cmd_vel_mux/input/teleop'.
Took me ages to figure out why my turtlebot2 wasn't spinning :-)
I know this can be fixed by putting it in a launch file and remapping, but teleop is something that users are likely to start and stop at runtime, so still being able to 'rosrun' it is very useful. Perhaps have a 'turtlebot_key' and a 'turtlebot2_key' as a quick and dirty fix?
We added some velocity smoothing, put it in turtlebot.
Might also put our yujin_keyop in kobuki, we still tend to use that over the turtlebot one.
We're hoping to start using the asus more exclusively. This renaming makes sense.
Comply with REP119, 105 for base link expectations (#40).
Applications will be expecting the transform from odom to base link to be relevant to navigation (REP105) AND base link to camera_rgb exactly as spec'd in REP119 for perception. Having base_bottom_link in the middle nullifies that expectation.
It isn't required in 3d sensor. Alot of turtlebot apps make no use of it (only the navigation apps). Subsequently it really should be just launched with the navigation app, otherwise it's overhead.
Currently lurking in turtlebot_bringup, but should be in one of the desktop packages instead.
Most are the same, we have a different chirp.
Not going to worry about doing anything different for turtlebot2 till we have a better gateway model/android pairing setup a few months down the line (us, austin and osrf).
Chirp doesn't automatically stop.
Also 'stop application' from android fails.
On recommendation from someone here, mode of 2 was really slow.
Change it and test it for a while.
Stacks are listed in some sort of relative order.
Done
Todo
We updated the monitoring in parallel to do a scan of the proc BAT# entries - put their parameterised method back in.
Hit yujinrobot/yujin_ocs#1 as soon as possible so we can move a default mux into kobuki core.
Bill has something along these lines. With the current configuration, what I'd like to perhaps have is
i.e. provided a set of arguments (or environment variables), it will automatically select the appropriate components (tags) from the library and create a xacro for you. This script could be called in minimal.launch and it would run as follows:
Get tags for a fuerte rosinstall, just for reference before we launch into groovy.
It's bouncing around in rviz when using openni.launch.
Following on from #25 with relevance to groovy.
...
Depth point clouds work, but registered depth point clouds fail.
ERROR: Unsupported encoding [yuv422]
Need to check that everything turtlebot2 is running on Bill's os install. Use this for the korean launch show.
What's the best way to kill this? At the moment we have at least three things we'd like to configure.
The current plan is to set environment variables:
and pull them into roslaunched args:
<arg name="base" value="$(optenv TURTLEBOT_BASE kobuki)"/>
More preferable ideas?
In groovy on precise
$ rosdep check -a
System dependencies have not been satisified:
apt texlive-latex-base
apt texlive-latex-recommended
apt texlive-latex-extra
apt texlive-fonts-recommended
apt texlive-fonts-extra
apt daemontools
apt ftdi-eeprom
ERROR[turtlebot_web_bringup]: resource not found [rosbridge_launch]
ERROR[kobuki_qtestsuite]: resource not found [qt_gui_py_common]
ERROR[rosbridge_server]: Cannot locate rosdep definition for [rosapi]
rosdep key : rosapi
OS name : ubuntu
OS version : precise
Data: <no data>
ERROR[rosapi]: Cannot locate rosdep definition for [rosbridge_library]
rosdep key : rosbridge_library
OS name : ubuntu
OS version : precise
Data: <no data>
I don't think that we should try to support fuerte with all the changes that have been made.
End result of the discussion:
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.