No version for distro humble showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro jazzy showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro kilted showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro rolling showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro ardent showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro bouncy showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro crystal showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro eloquent showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro dashing showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro galactic showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro foxy showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro iron showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro lunar showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro jade showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro hydro showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro kinetic showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro melodic showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange

No version for distro noetic showing indigo. Known supported distros are highlighted in the buttons above.
Package symbol

ubiquity_launches package from ubiquity_launches repo

ubiquity_launches

ROS Distro
indigo

Package Summary

Tags No category tags.
Version 0.2.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/UbiquityRobotics/ubiquity_launches.git
VCS Type git
VCS Version 0.2.1
Last Updated 2016-02-19
Dev Status DEVELOPED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Robot Configurations

Additional Links

No additional links.

Maintainers

  • Wayne Gramlich

Authors

  • Wayne Gramlich

ubiquity_launches Launch File Repository

Build Status

Development Overview

All of the Ubiquity robots use ROS (Robot Operating System). ROS breaks a robot application into a multitude of ROS nodes (i.e. processes) running on one or more processors that communicate with one another via internet protocols.

The usual method for teaching people to develop ROS robot applications is to point them at some ROS tutorials and say “go at it”. Unfortunately, this is a little bit dumping buckets of blood into shark infested waters and going for a little swim. At Ubiquity Robotics, we want robot application developers to have a much less traumatic experience. For this reason, we have invested a great deal of effort to make ROS robot application development as easy as possible.

The reality is that setting up a workable software development environment for developing ROS applications is actually pretty involved. One major complication is that the robot typically does not have a display, keyboard, and mouse. Even if it did, it not particularly easy to walk around with the robot as it moves. The more workable solution is to develop software on a stationary platform like a laptop or a desktop, and communicate with the robot via a wireless internet connection. A further complication, is Ubiquity Robotics is using a Raspberry Pi 2 processor with the ARM7 instruction set, whereas most laptops and desktops use the x86 instruction set. We have to make sure that each machine gets the right instruction set.

The Ubiquity Robotics application development environment assumes that there are two processors. The robot processor is attached to the robot and the development processor is associated with either laptop or desktop computer.

Ubiquity Robotics currently uses a Raspberry Pi Foundation Raspberry Pi 2 Model B for the robot processor. Since “Raspberry Pi 2 Model B” is a mouthful of words, we shorten it down to a more manageable “RasPi2”. The RasPi2 is a quad-core ARM Cortex-A7 CPU with 1GB of RAM, with 4 USB Ports, an Ethernet port, a camera interface, and a micro-SD card. We plug a dual-band USB WiFi Dongle into one of the USB port slots to provide wireless connectivity with the development processor through a commercial off-the-shelf WiFi router.

The development processor must be a 64-bit x86 hardware architecture processor. You can either run some flavor of Ubuntu natively on the processor, or you can run a different operating system (e.g. Windows, MacOS, Solaris, etc.) and run VirtualBox to run the Ubuntu operating system. Neither 32-bit processors nor other virtual machines (e.g. VMWare, Parallels, etc.) are supported.

ROS currently only runs under Ubuntu and its variants (e.g. Kubuntu, Xubuntu, Lubuntu, etc.) No other operating system options are currently supported by the ROS community. To be consistent, the VirtualBox image that we recommend that you use has Lubuntu installed on it. We also install Lubuntu on the robot processor, just in case you choose to plug a monitor/keyboard/mouse into the RasPi2. Lubuntu is a very light weight window system that does not over tax the RasPi2 robot processor.

We really encourage people not to cut corners when it comes to setting up your WiFi network. If you have heard the saying that “a chain is only as strong as its weakest link”, our experience is that WiFi is the weak link in robotics. We strongly recommend that people use dual band 802.11ac USB WiFi dongles to provide wireless technology. Similarly, we recommend that you invest in a superior dual-band WiFi router. You can spend an enormous amount of time tracking down and eradicating flaky WiFi issues and it is better to simply avoid the issues by using better hardware and better antennas.

We use a technology called zeroconf to provide human readable names for the various processors on the computer network. Each robot processor and development processor must have a unique host name and MUST run zeroconf. The DNS will present the DNS names as hostname.local where, hostname is the host name of the robot or development processor.

The ROS community extensively uses Secure Shell to communicate between computers. The secure shell protocols provide a secure and encrypted link between computers. We require that password keys be properly set up between the development processor and the robot processor such that a secure link can be established without prompting the user for

File truncated at 100 lines see the full file

CHANGELOG

Changelog for package ubiquity_launches

0.2.1 (2016-02-18)

  • Restore motor_node which was deleted
  • Contributors: Rohan Agrawal

0.2.0 (2016-02-18)

  • Update Cmakelists
  • Restored n_move_base which I accidentally removed.
  • Added travis build status to README
  • use bash || for testing both ssh commands
  • Hack in automatic user detection in roslauncher
  • Replace all the old loki_camera stuff with raspicam and raspicam_view
  • Got raspicam_view to work with new machine tag args
  • Got m_raspicam_raw to work with new machine infasrtuture
  • Replaced loki_base and magni_base with unified robot_base script
  • Update m_move_base to reflect move of cmd_vel_mux
  • Add all required things to sim
  • Change default machine for n_relay to robot
  • Machine tag in n_relay
  • Moved machine def to the top of m_sim_base
  • Move turtlebot_model to m_sim_base
  • Using robot_base instead of stage_ros directly
  • Support sim in robot_base
  • Use not shutdown loop instead of infinite loop
  • launching cmd_vel_mux with include
  • Made cmd_vel_mux launcher (uses nodelets)
  • Passing machine_name from m_move_base
  • Machine name argumentizeation for rsp
  • removed unnessary machine definition
  • Further adding of machine_name args
  • Added viewer args to more stuff
  • Argument-zied machine name with reasonable defaults
  • Pass robot host/user to amcl and map_server instead of viewer
  • n_amcl and n_map_server now use machine_host and user
  • Passing viewer/robot on keyboard_nav and move_base_view
  • Have m_move_base require all nessacary args
  • Removed old refrences to keyboard_drive
  • n_rviz run through ssh
  • Launch keyboard_naviagte though ssh to viewer
  • Merged branch master into master
  • Using ssh to localhost to run teleop
  • Use generic machine args for loki_base nodes
  • Add teleop_twist_keyboard with any machine format
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Banged together bin/yaml2launch.py
  • Using move_base_view as the starter
  • Luanch -> Launch
  • Move viz to move_base_view
  • Launching cmd_vel_mux on remote
  • Fixed Typo, moved back to whoami
  • New line for clarity of nodelet stuff
  • More renaming to keyboard_navigate
  • Output screen on teleop to make sure that we can see the output
  • fix missing end bracket
  • Switch robot_name to correct robot_host
  • Robot_base launch is not xml
  • fixed bug of mb vs rb
  • Remo.ved an. exce.ess. period. in. fil.na.me
  • Using ubuntu as user instead of whoami
  • Change keyboard_drive to launch.xml
  • Added keyboard_drive to unified-ily teleop
  • Removed buggy space
  • Rename folder for keyboard drive as well
  • rename keyboard_drive to keyboard_navigate
  • We ha`d an acc`ess of ac`cent ma`rks, it has been rectified
  • Fixed always on roscore documentation
  • Update Cmakelists to not fail on build
  • Make sure robot_platform is being sent to loki_base correctly
  • Using robot_base to auto switch between loki and magni
  • Consolidate loki and magni base into robot base
  • Get rid of loki_serial_master
  • More tweaking of m_move_base.launch.xml
  • More conversion of move_base.
  • Starting to de-turtlebot m_move_base.
  • Fixed raspicam_view
  • Convert robot_base to robot_platform
  • More launch file work.
  • Fixed some typos
  • Added recipe to configure Ubiquity Robotics development environment.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Remove old ros_launcher.py program
  • Added n_sleep_forever to bring up roscore using robot_upstart package.
  • More unified launch file development
  • More work on unified launch files.
  • Renamved platform_probe.py to platform_probe.
  • Merge branch 'master' of https://github.com/UbiquityRobotics/ubiquity_launches
  • Changed platform to robot_base
  • Some more work on unified launch files.
  • Updated test.launch and urtest.sh
  • Fixed a typo.
  • Tweaked up bin/test.launch and bin/urtest.sh to work with one another.

File truncated at 100 lines see the full file

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

Deps Name
catkin

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ubiquity_launches at Robotics Stack Exchange