Category: ArloBot

This shouldn’t be rocket science, but up until just this moment I never comprehended the <remap> tag.

However, due to a problem I was having I had the opportunity to track it down, in action, and also to see the result.

First, this is documented, but the documentation never made sense to me: http://wiki.ros.org/roslaunch/XML/remap

or for more confusion: http://wiki.ros.org/Remapping%20Arguments

So here is my explanation to myself:

If you look inside of my ArloBot propellerbot_node.py you will see that it listens to the topic cmd_vel:

rospy.Subscriber("cmd_vel", Twist, self._handle_velocity_command)

However, if you start up my ArloBot:

roslaunch arlobot_bringup minimal.launch --screen

and start driving it around with TeleOp:

roslaunch arlobot_teleop keyboard_teleop.launch

You will see NO cmd_vel topic!

In ROS there is so much going on that it is easy to chalk things up to “magic”, but when you actually write the Python code to listen to cmd_vel, and there is no cmd_vel topic, no amount of “magic” suffices. Obviously something is wrong!

The solution is <remap>, and the lesson is that this tag works on an individual node at the time we run it!

We called propeller_node.py with minimal.launch, and it includes the file mobile_base.launch.xml:

<include file=”$(find arlobot_bringup)/launch/mobile_base.launch.xml” />

and inside of this file is the “magic”:

The exciting line is this one:

<remap from="cmd_vel" to="mobile_base/commands/velocity" />

This says that when the node we are calling (propellerbot_node.py) tries to subscribe to “cmd_vel” give it “mobile_base/commands/velocity” instead!

Mystery solved, because that topic does exist!

Furthermore, if you run or create a node that sends data on the “cmd_vel” topic, nobody is going to listen to it!

I don’t know why these remaps were so confusing to me before. Probably because a lot of them are only used in the TurtleBot code that I borrowed from. Only when I had a clear situation where a third party node was talking on cmd_vel and nothing was happening did I realize that there IS NO cmd_vel topic in my normal setup, and yet it worked.

Question 2:

If I have a launch file that I want to start, and I know the node it starts will broadcast to a topic I don’t listen to, either directly or due to remapping, what can I do about this?

Based on this now less confusing documentation of argument remapping: http://wiki.ros.org/Remapping%20Arguments

You can also use remap when you run a node directly, so that this:

(This is based on a command from the great ROS by Example INDIGO book that you really should buy!)

rosrun rbx1_nav calibrate_linear.py

becomes:

rosrun rbx1_nav calibrate_linear.py cmd_vel:=mobile_base/commands/velocity

Because I know from experience (run the command and then run “rostopic list” to get that same experience) that this node broadcasts on “cmd_vel”, and from my previous discussion based on launch files and the output of “rostopic list” that my robot’s controller node listens on mobile_base/sensors/core

One of the motivations for building my robot was to be able to follow the tutorials and examples made for and written by ROS experts.

One of the best resources for ROS is ROS By Example – Volume 1 by R. Patrick Goebel. I’ve been waiting though for the “Indigo” version to be complete, because working with documents aimed at older versions of ROS is frustrating and time consuming.

Now it is here!
http://www.pirobot.org/wordpress/indigo-revision-of-ros-by-example-volume-1-available/

I plan to purchase this book and work through it with my ArloBot to become more familiar with ROS and learn to add more functionality to my robot.

I just now saw that the debs for ROS Indigo Turtlebot are listed in the install instructions now!

I have updated the ROS Indigo Setup article to describe installation using the Turtlebot Deb packages.

This is an index of the articles you can follow, in order, if you want to build my ArloBot:

1. Please see the Readme at my GitHub repository – https://github.com/chrisl8/ArloBot as it is usually kept more up to date. Then come back here and follow the instructions!
2. Buy lots of stuff – Arlo Robot Parts List
3. Build the Arlo – Arlo Robot Assembly Guide
4. Install Ubuntu – Laptop Setup for ROS Kinetic
5. Install ROS and my code from Github – ROS Kinetic Setup
6. Propeller Code – Propeller Code for Arlobot
7. Have fun!
   • ArloBot Recipes at the end of the Readme
   • Convenience Scripts

Mailing List: https://groups.google.com/forum/#!forum/ros-for-arlobot

While a lot of the fun stuff with the robot happens on the Ubuntu laptop with ROS, the motor control and sensor polling is all done on a Parallax Propeller microcontroller.

I like to think of the laptop as the cerebral cortex of the robot’s brain and the Propeller board as the Cerebellum.

The code for the Propeller is all written in C. I have set it up so that it will refuse to run into things even if ROS tells it to, and if it gets much too close to an object it will actually back away. This way it is safe to experiment with ROS without worrying too much about crashing into walls. You can also gently “push” the robot out of your way by just getting close to it and it will move away if it can. (Yes, you can “herd” your robot!) Obviously you still need to be careful, especially if you tell it to drive around extremely fast, because you can drive into a wall faster than the sensors are able to register it.

Here are the steps to get the C code that I use with my Arlobot ROS package onto your robot using the Ubuntu laptop you should have connected to it.

Follow all of these steps from your Ubuntu laptop. Because the laptop must be connected to the Propeller board via USB at all times for ROS to operate, it is natural to install SimpleIDE on the laptop and use it to update the code on the Propeller board when needed.

0. Learn first!
This isn’t a store bought toy, this is a learning project, so if you have never done anything at all with a Propeller board, I highly recommend insist that you go to http://learn.parallax.com/propellerc and follow some of the turtorials to get to know the Propeller chip, the Activity Board, SimpleIDE and Propeller C.
This will give you a good background to understand what is going on.
You can do this with just the Activity Board and your Windows computer, and then come back here later to make it all work with your Ubuntu laptop.
Without doing at least a few of the tutorials you will be following my instructions in the dark. They may get you to your destination, but it will be frustrating.

1. Add your user to the “dialout” group
Otherwise SimpleIDE tells you that you have no access to /dev/ttyUSB0

And then you will have to reboot to make this work.

2. Set up Parallax SimpleIDE for Linux

FYI: Parallax has abandoned support for Linux, as can be seen from this thread:
http://forums.parallax.com/discussion/166656/simpleide-on-linux

I am very sad about this, but it seems we can limp along by using copies of old code releases.

In the example below I show using ‘wget’ to pull the latest version of SimpleIDE from a web archive service (since Parallax has abandoned it) and installing the package on Ubuntu.

3. Test SimpleIDE
If it is not already done, plug your Propeller board into your Ubuntu laptop with the USB cable.

Open a terminal window in the Ubuntu desktop and run:

IF you get errors about missing dependencies, you may need to run:

The first time SimpleIDE runs it will create a folder with required libraries in it.
Please let it use the default location.

SimpleIDE should open with a “Hello World” program called Welcome:

Notice that I am using VNC to do this from the comfort of my desktop machine.

Make sure you see “/dev/ttyUSB” at the top right. It will probably be USB0, but if you have more than one board it could be another one.

Just run it with the terminal by pressing the blue terminal with the “play” arrow in it:

You should get a blue terminal window with the text “Hello!” in it, or whatever the simple test program was set up to send.
This proves that your SimpleIDE is installed and that your Propeller board is properly connected.
You can press “OK” on the Terminal window to close it and close SimpleIDE.

4. Add Arlo Code to SimpleIDE
For HB-25: The extra code from Parallax to work with the Arlo platform is already in my arlobot repository, you just need to copy it into your SimpleIDE folder structure.
If you already ran SimpleIDE once, and if you let SimpleIDE use default locations, this should work for you:

The library from Parallax to work with the Arlo platform is in a separate download on the Parallax site. Run these commands to download and “install” the library:
(NOTE: This copies files to the default folder created when you ran SimpleIDE for the first time.)

Run SimpleIDE again.
Open up ~/catkin_ws/src/ArloBot/PropellerCodeForArloBot/ROSInterfaceForArloBotWithDHB10.side
Click on the little hammer icon to just Build the code without loading it to the board.
If it says, “Building … done.” in green highlight then everything is good!
If it failed to build start trouble shooting or send me a note.

5. Learn Some More

I suggest working through the instructions here:
http://learn.parallax.com/tutorials/robot/arlo/arlo-activity-board-brain

This will walk you through testing your Arlo connections and basic code to operate the the Arlo platform from the Propeller Board. Even if you are using my code to run it, it will help you to deal with problems if you understand how the basics work.

6. Calibration

DHB-10: Calibration is not required for the DHB-10. There are steps on the site listed above (under Learning) for adjusting parameters, but calibration isn’t required.

HB-25 Controllers: ONLY DO THIS IF YOU HAVE THE OLD HB-25 CONTROLLERS! Otherwise skip to Step 7.
This step is a little complicated, so follow closely.
This is a combination of information from
http://learn.parallax.com/activitybot/calibrate-your-activitybot
and
http://www.parallax.com/news/2013-12-23/run-activitybot-c-code-arlo
but I’ve put it together here in one list of instructions.

The point of this is that you load special code into the board that, when powered on, causes the board to run a series of tests on the motors and then store the data into a special place in EEPROM. Once this is done you should never have to do it again, because no other program ever writes to this memory.

Note that this code is specially written by Parallax so that once it completes it will not run again. If you want to do the calibration again you will have to load the code into EEPROM again.
Otherwise, once it finishes once, resetting the board will not cause it to run again.

1. The instructions say to put your robot in a clear area to do this. I have also just put it up on “blocks” or a sturdy box so that the wheels can run freely without moving the robot. I’m not sure which, if either, is better.
2. Run SimpleIDE if it isn’t already running.
3. Open up the program ~/Documents/SimpleIDE/Learn/Examples/ActivityBot/Arlo Calibrate.c
4. Turn OFF the Motor switch.
5. Set the Activity Board switch to position 1.
6. Click the “Load EEPROM & Run button”
7. When the program is finished loading, the P26 and P27 lights will turn on. When they come on, slide Activity Board switch to 0.
Disconnect the USB cable from the Activity Board
8. Turn all power off. (Both Main and Motors switches OFF.)
9. Set the power switch on the Activity Board to 2. (It won’t come on yet because the power is off.)
10. Turn system power on but leave motor power off.
11. Press and release Activity Board’s reset button.
12. Wait a couple seconds.
13. Turn on motor power and wait for it to try to do something.
14. Press and release Activity Board’s reset again after the HB25s are convinced they are getting servo signals.
(This last step is required only during calibration because it’s crucial to capture all encoder measurements, from the very start of the program.)
15. Move back to give it room to spin in place and slowly roam while it gathers wheel speed data.
Both wheels should turn at some point. First it will spin in one direction, then the other. If one of the motors never comes on, you need to start over, because something went wrong.
(Or for the wheels to just spin if you have it up on “blocks”.)
16. Leave it alone until the P26 and P27 lights turn off (about 2 minutes). After that, calibration is complete and you can turn the power off again.

You can read more calibration trouble shooting tips here:
http://learn.parallax.com/activitybot/troubleshooting
although obviously some things, like the server adjustments, do not apply.

7. Edit the Propeller C Code for Arlobot to fit your setup.
In SimpleIDE Open up ~/catkin_ws/src/ArloBot/PropellerCodeForArloBot/ROSInterfaceForArloBotWithDHB10.side
Now at the top there is an entire section of “#define” statements.
You need to comment out some for items you don’t have, and you need to adjust the numbers after others to indicate things like how many PING sensors you have and where they are located.
By doing this, the code will be compiled to only include the parts you need and with setting specific to your robot.

8. Load Propeller C Code for Arlobot on to Propeller board.
The way the Propeller controller works is that if you load a program into “EEPROM” it will stay there and start any time the board is reset or power cycled. This means once the code is there you don’t have to mess with it again unless you want to change something.
If you get any of the “#define” settings wrong the first time, this could be one reason to reload it.

Plug the USB cable back into the Activity Board and Ubuntu Laptop.
Click the “Load EEPROM & Run button”

The board should load the code and reset.

Close SimpleIDE.
(NOTE: If SimpleIDE is running when you try to use ROS it will mess up the communication with the Propeller Board, so be sure to close SimpleIDE before testing anything.)

9. Testing.
A good way to test your Propeller code is to run:

It will reset the Prop board and then start spitting out:

Please see the file direct2PropSerialTestLines.txt for more information about how to test the Propeller code directly. There is also some information in README.md, but direct2PropSerialTestLines.txt  is kept most up to date.

Test all output, and attempt sending twist commands directly.
Until this works, do not expect ROS to work.

All done!

Remember, this is open source, so feel free to fix mistakes and make changes to the code and tell me about them! Better yet, fork the code and send me pull requests!
Next read over README.md, or try scripts from ~/catkin_ws/src/ArloBot/scripts/ and anything else from ROS that you want to try!
You can go to the ROS Turtlebot page and read about various functions it has and attempt to make them work with your robot.

P.S. Prevent Propeller Board from running on USB Power 
You may want to do this if you ONLY want the the Propeller Board to run from DC power and not the USB device.

I had a few spare hours over the holiday season so far to do some cleanup and add a few goodies I picked up from Parallax during their sales.

I’ll write more about my additions soon.

Along with my Arlobot ROS packages, I have also been working on a “Metatron” package that I use for some “personalization” of my robot, and a web interface called Arloweb.

I now have Metatron and Arloweb on my GitHub repository, so technically everything I use on my robot is on GitHub now.
In theory, if you follow my build to build the same robot I did, you can install everything from my GitHub repo and have a robot identical to mine.
Certainly more documentation is due, but at least it is all there and being updated as I modify the code.

If there is something in particular you want to do, let me know and I’ll try to document that ASAP.
As it stands now I kind of drift back and forth between documenting things I did months ago and things I’m working on now.

We have an xBox 360, so just like I was able to “borrow” the Kinect from it for initial testing, I am going to “borrow” one of the kid’s xBox controllers for testing! They rarely use all 4 anyway.

To use an xBox controller with a PC (Windows or Linux) you need a receiver, which are fortunately easily obtained.
I purchased this “Wireless PC USB Gaming Receiver for Xbox 360” from Amazon for under $10.

Note: I’m not sure if there is any way to “disassociate” an xBox controller from your xBox. You just connect it to a new device. I found that if I turned on the controller in another room it was far enough away that the xBox did not power on. If the xBox keeps turning on and grabbing your controller just unplug it from the wall so it has no power. Once your associate the controller with the PC adapter it shouldn’t turn on the xBox anymore.
Reconnecting it to the xBox should be as easy, just remember if you want to go back and forth you’ll have to keep doing this.

ROS already has a page about Configuring and Using a Linux-Supported Joystick with ROS. I will just be adding my findings specific for the xBox 360 and my ArloBot.

Before I plug in the adaptor my Ubuntu machine already shows one “js” device:

This appears to be some sort of accelerometer, possible built into the HP Elitebook laptop?!

That is not what I am after now, but it sure seems like I should look into it in the future! Maybe your laptop has one too?!

When I plug the USB adapter for the xBox joystick into my laptop I get four new “js” devices.

I guess since the xBox standard is to support 4 controllers, the USB PC adapter provides 4 devices right up front.

Press the button on the USB adapter and it starts flashing.
Press and hold the small round button on the back of the xBox controller that looks like “O)))” until the lights on top of the controller start to “spin”.

The light on the USB adapter will stop flashing almost immediatly and the lights on the controller will stop spinning and start flashing all together.
This part is confusing, because when the controller is connected to the xBox you get one quadrant lit up to show which controller it is. Instead on the PC I just get all 4 lights flashing at me, which is kind of annoying.

However, if you run sudo jstest /dev/input/js1 you will indeed see that Ubuntu sees the controller and it is the first one!

If your screen scrolls instead of updating the line of input in place try resizing your terminal window.

Clearly we have a LOT of input options here and a lot of cool buttons for doing all sorts of stuff!

It is kind of fun to play with and learn about how the controller works this way! 🙂

So now we carry on with the ROS instructions:

Make sure the js1 device is read/writeable by everyone:

You will need to have ROS running at this point, so if you don’t, start it.
If you don’t know what I mean, just open another terminal window and run roscore so it can be running over there while you carry on over here.

Now make sure your xBox controller is still on and run:

Now start another terminal (yeah, ROS is big on having dozens of terminals open to test things) and run:

It should be quiet as long as you do nothing, and then it should spit out lines like this if you push any button or move any stick:

A button push will give one entry for each up and down.
Moving an analog stick or button will send a lot of them as a stream of the analog output!

Now we know that ROS can see the input from your xBox controller!!!

One nice thing is that the ROS joy node can deal with the controller shutting down. With just jstest it would quit if the controller shut off or went out of range, but the joy node will keep attempting to reconnect, which you can even see in the output:

NEXT: Use the xBox controller and joy node to control ArloBot!

So now how do we make use of this in ArloBot?
Certainly we could write custom code and/or modify code to make use of the amazing arrow of inputs, but ROS already has code for this. Later I may augment this to make use of more of the buttons, but for now I’m going to try to just use what is included in ROS with as little modification as possible.

Don’t follow on with the ROS page we were at before, that was just to make sure we could see the controller in Linux and show us how to debug.
Now we want to find a node that we can use with ArloBot with the least fuss.

The easiest way to do this is to just launch ArloBot’s minimal bringup package and then launch turtlebot’s teleop:

The way this works is that it ONLY sends commands to the robot while the left “shoulder” button is held down. It is labeled “LB”. Hold that down and move the left stick and the robot should respond!
If things get out of hand just let go of the “LB” button and all zeroes will be sent again to make it stop.

And that’s it! It should work.

I will probably do some tweaking and customizing of my own joystick teleop code and include it in the ArloBot github repository soon. Until then though, the TurtleBot code is working fine.

In the last article I explained how to set up an Ubuntu laptop for use by ROS. Here I’m posting my notes about how to get ROS Kinetic up and running on that laptop.

There is now a script to install everything.
Just run:

and you are done!

To update your code just run the same script again and it will pull down and compile anything new without erasing custom settings.

NEXT!
Next we’ll want set up Propeller Code for Arlobot

Part of the ArloBot setup is to have a laptop riding on board the robot to run ROS. This article is a quick set of instructions for setting up that Laptop.

My Laptop:
I bought a well used HP EliteBook 2760p on Ebay.
It is great for the robot because it has a reversible touch screen!
It also has two batteries so it can go a long time on a charge.
It has a 64 bit quad core i5 2520M CPU, which should be snappy for ROS.
The TurtleBot comes with an ASUS “Netbook” with an Atom N525 dual-core 1.8GHz CPU. While this works, I think it should be considered the absolute minimum for a usable laptop for ArloBot.

Lubuntu 16.04 Desktop 64 bit:
ROS Kinetic is built for Ubuntu LTS 16.04 Desktop. It is the “Long Term Support” (LTS) version, so you can download and use it for several years without having to upgrade to the next version. This gives the ROS development community some stability in their target OS.

I am using the Lubuntu variation of Ubuntu in order to reduce the RAM usage of the operating system on the laptop in the hopes of leaving more system resources available for ROS. Here is a review someone did on the system resource utilization of each “buntu” distribution: Ubuntu 14.10 vs Kubuntu 14.10 vs Xubuntu 14.10 vs Lubuntu 14.10 vs Ubuntu GNOME 14.10: A Comparison

The bottom line is that any of them will work exactly the same for ROS. The “light weight” Lubuntu and/or Xubuntu will allocate less RAM and a few less CPU cycles to the Desktop GUI, allowing ROS a little more room to work. Don’t expect miracles, but every little bit counts.

Just remember that it must be an Ubuntu Desktop variant of version 16.04 LTS (the .01, .02, .03 on the end is fine). Other Linux distributions will not work, nor will newer versions of Ubuntu. We can hope that ROS becomes more compatible in the future, but for now at least this requirement makes for relatively easy installation of ROS.

These instructions should be the same for Ubuntu, Lubuntu or Xubuntu.
Note that some of these instructions are from my last install that did use “ordinary” Ubuntu, so some of the screenshots and text will reflect “Ubuntu” instead of “Lubuntu”.

NOTE 8/216/2017: These instructions were originally written for an older version of ROS and Ubuntu. If you see mistakes referencing that old version, please let me know.

Download lubuntu Desktop 16.04 LTS 64bit ISO (lubuntu-16.04-desktop-amd64.iso) from https://help.ubuntu.com/community/Lubuntu/GetLubuntu/LTS
My laptop has no DVD drive, so I have to use a USB stick or something else.

Use the instructions here to create a bootable USB stick if you need to:
http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-windows

NOTE: I have UEFI Boot Mode disabled in the BIOS! I found no benefit from it.

NOTE: Remember to turn off “Fast Boot” in the BIOS, and enable USB boot if it isn’t already to get it to show up in the boot options.

I recommend that you do NOT plug into Ethernet! This way the Ubuntu setup will ask you to configure WiFi during setup, proving it works and getting it pre-configured during install!

Boot from the USB stick or DVD you created with the Lubuntu (or Ubuntu, Xbuntu, etc.) ISO.

Install Lubuntu (or Ubuntu, Xbuntu, etc.)

Connect to WiFi

CHECK: Download updates while installing

CHECK: Install this third-party software

Continue

Pick your Installation Type
Really, anything here will work. You can dual boot with Windows or another Ubuntu version, or erase the disk.
I recommend not using encryption,
and you do not need LVM either.

Continue

Your Name: Chris L8(replace with the name you want)

Your computer’s name: ArloBot(Or pick something else)

Pick a username: chrisl8(Replace with the user ID you want for Ubuntu)

CHECK: Log in automatically – I prefer this, but you don’t have to.

UNcheck: Encrypt my home folder

Continue

On first boot let the Software Updater install all updates and reboot if asked to.

If you are using Ubuntu:

Once Ubuntu starts click on the “Search Desktop” button, type “terminal” and run Terminal:

Right click on the icon on the Launcher and “Lock” it to the Launcher:

You can also drag it up higher on the Launcher after you lock it,

and you can right click it and run a “New Terminal” when you need another one.

If you are using Lubuntu:

Click on the menu button at the bottom left,
Click on Accessories,
Right click on LXTerminal and select “Add to Desktop” if you want it easy to access from the desktop.

Install the SSH server:

Now you can use ssh from Linux or PuTTY where you can cut/paste.
If you are not familiar with how to use SSH to connect to Linux machines, search the Internet for “ssh putty tutorial”. I thought this one looked pretty good: SSH Tutorial for Windows

Enable Remote Control of GUI Desktop:
The entire idea of a robot is to be remote, so it will help a lot to be able to control it from your desktop.
VNC works well. If your normal computer is running Windows use TightVNC.
If you are on Ubuntu you can use Remmina. Click on the “Search Desktop” button, type “remmina”.

VNC Setup on Lubuntu:
https://wiki.ubuntu.com/Lubuntu/RemoteDesktop
Install vino by running:

Configure VNC by running this from LXTerminal:

CHECK: Allow other users to view your desktop
CHECK: Allow other users to control your desktop
UNcheck: You must confirm each access to this machine
CHECK: Require the user to enter this password:
and put in a password.
Close

Click on the menu -> Preferences -> Default applications for LXSession, and set up Remote Desktop to start when GUI starts,
by selecting the “Autostart” tab,
and CHECK: Desktop Sharing

NOTE: I also UNcheck “Update Notifiier” and “Screen Locker”, but that is personal preference.

From LXTerminal run:
gsettings set org.gnome.Vino require-encryption false
Otherwise TightVNC cannot connect due to silly encryption policies that it cannot understand!

Reboot to startup VNC and test it.

VNC Setup on Ubuntu:
Search: “remote”
Run “Desktop Sharing”
CHECK: Allow other users to view your desktop
CHECK: Allow other users to control your desktop
UNcheck: You must confirm each access to this machine
CHECK: Require the user to enter this password:
and put in a password.

From the terminal run:
gsettings set org.gnome.Vino require-encryption false
Otherwise TightVNC cannot connect due to silly encryption policies that it cannot understand!

Customize Ubuntu Desktop:
These are all a matter of personal preference, but I find this to be the best way to set things up.

Lubuntu:
Preferneces -> Light Locker Settings:
Turn “Enable light-locker” OFF
-> Power Manager:
On AC: When laptop lid is closed: Nothing
On Battery:
– When battery power is critical: Shutdown
– When Laptop Lid is closed: Nothing
You can also adjust the screen off times and when it dims.
I like to set it to dim after some time and to shut off eventually.

Ubuntu:
Settings->Brightness & Lock:
CHECK: Dim screen to save power
Turn screen off when inactive for: 5 minutes (or set as you like)
Lock: Off
UNCHECK: Require my password when waking from suspend
Appearance-Look:
Change “Wallpapers” to “Colors & Gradients”
Pick the sold box on the left
Change the color box to black
Power
Suspend when inactive for: Don’t Suspend     Don’t suspend
When power is critically low: Power off
When the lid is closed: Do Nothing     Do nothing

Byobu: (I use tmux myself, but if you are new to Linux, this is a good option)
When you run ROS nodes on the laptop via SSH they will be in your session. If your session disconnects it will stop ROS.

To allow your session to continue in the case of an accidental or even purposeful disconnect you can use a program called tmux (or screen) that lets you leave running “sessions” open. byobu is a front end to tmux that makes it pretty and easier to use.

byobu-enable This will cause byobu to automaticlaly start when you connect via SSH.

Log off and back on,
The first time you press ctrl-a it will ask if you want this to go to work with Emacs or Screen, pick Screen.
F1, Toggle Status, add/remove what you want. I like to add the battery level.

Disable lid close detection:
If you want to run your laptop on the robot with the lid closed, you may need to do this, because when you reboot or try to shut down while the lid is closed and the laptop is on battery power, as soon as XWindows shuts down the computer goes to sleep before it even shuts down!
This leaves the laptop in a limbo where it sleeps until the battery dies with no hope of connecting to it until you open the lid and let it finish shutting down!
I found two solutions. I am using the first option, which works for me, but if Option 1 doesn’t work try Option 2.
Option 1. Set “IgnoreLid=true” in /etc/UPower/UPower.conf
sudo vi /etc/UPower/UPower.conf
CHANGE:
IgnoreLid=false
TO:
IgnoreLid=true

Option 2. Set LidSwitchIgnoreInhibited=no and HandleLidSwitch=ignore in /etc/systemd/logind.conf:
sudo vi /etc/systemd/logind.conf
CHANGE:
#LidSwitchIgnoreInhibited=yes
TO:
LidSwitchIgnoreInhibited=no
AND CHANGE:
#HandleLidSwitch=suspend
TO:
HandleLidSwitch=ignore
Reboot to make these changes take affect.

NEXT!
Next you will want to do the ROS Kinetic Setup