Move_basic tutorial / is my map ok?

This images shows the robot going from point A to point B and knowing on the rviz that “he(robot)” is wrong but still ending too much apart from the point of destination B!

Right now im using this to get the current robot position “rostopic echo /fiducial_pose”

and then copy the results to and run this:

rostopic pub /move_base_simple/goal geometry_msgs/PoseStamped “header:
seq: 0
stamp:
secs: 0
nsecs: 0
frame_id: ‘base_link’
pose:
position:
x: 1.0
y: 0.0
z: 0.0
orientation:
x: 0.0
y: 0.0
z: 0.0
w: 1.0”

am i doing it right? please tell me!

Yes continuously sending the point you want the robot to go to is a perfectly OK approach. The robot needs to course correct on its way to the final goal. Normally we suggest setting intermediate waypoints if you have something a long ways away, but resending the same goal is a perfectly good way of doing things.

Couple of things.

  1. The new parameters are not yet avaialable give it a few more hours.

  2. Even with the new parameters you will not get the best results unless you calibrate on your camera. Even with modern mass produced cameras there are small differences in the optics of the camera - normally this doesn’t matter - but when you are trying to localize a robot exactly it pays to do the calibration for your specific camera and you will get better results by doing this.

  3. There is a parameter that describes how accurately the robot needs to hit its end point. We basically say that provided the robot hits its end point to within a certain amount that is acceptable. If the robot doesn’t get to within the distance it continues to try to get closer to the end point. The parameter is there so that it doesn’t try to continuously drive around trying to get exactly to the end point. If this parameter is too loose then the robot will be satisfied with where it has gotten to even if you aren’t. If the robot is not getting close enough to where you want it to be then you should tighten this end point parameter.

Oh ok, so we need to wait more hours and the run again sudo apt-get update/upgrade!

Ill wait then and test again tonight! thanks

Im getting very good results with the “re-sending” goals! But let me know if im using the right “commands” to get the robot position!

Right now im using this to get the current robot position “rostopic echo /fiducial_pose”

and then copy the results to and run this:

rostopic pub /move_base_simple/goal geometry_msgs/PoseStamped “header:
seq: 0
stamp:
secs: 0
nsecs: 0
frame_id: ‘base_link’
pose:
position:
x: 1.0
y: 0.0
z: 0.0
orientation:
x: 0.0
y: 0.0
z: 0.0
w: 1.0”

am i doing it right? please tell me!

i made the calibration (hopefully it’s ok…)

I just another slam. Visually in rviz I hardly notice any difference. :confused:
i collected a bag file.
i did not make any apt update/upgrade.

i’ll make some more tests and data analytics most likely early next week

The apt update I did last week did change any of those packages apt list --installed | egrep "magni|fiduc"

In the end, I made 1 map onthursday afternoon and 2 others on friday morning. + the calibration (i would love to see some feedback whether or not this calibration is as expected)

The resulting output feels much more satisfying on XY coordinates
image

at least visually the XY points seems to be very close on the graph.
Z continues to have significant error but I hopefully it will be no problem for navigation on ground floor.

maybe i’m making progress after all ?

Will try to send navigation goals later. hopefully tomorrow

This looks really good. Yes absolutely Z direction is much less critical on the ground. You can also improve Z direction by tuning the parameters in aruco detect - essentially there is a trade off between how much computer time you use and how good the fit that allows you to figure out the location of the corners of each arucco square and thus how far away the square is, etc. Although it looks like you are getting acceptable results without doing this.

When you say “first map” and “second map” what do you mean? Do you do a single pass each time? Or is the second map the position after having passed back and forward twice?

Remember that by default the map positions are the result of all prior observations so in theory the more you drive around the better the map should be.

the protocol I use is the following

close rviz on the PC.
Position the magni at a known location on the floor inside a red tape rect. Power on/off magni.
rm /home/ubuntu/.ros/slam/map.txt; rosclean purge # delete previous map and purge logs
sudo service magni-base stop ; sudo service magni-base start # restart magni services
#cd /tmp; rosbag record /fiducial_transforms /fiducial_vertices /tf /fiducial_pose /fiducial_map # record in a 3rd ssh window
roslaunch magni_demos simple_navigation.launch # Start the nav demo in 1st ssh window
rosrun teleop_twist_keyboard teleop_twist_keyboard.py # teleop the magni in a 2nd ssh window
rviz # on PC
Use keyboard teleop to move the magni and see what happens in rviz

Reason is that I first want to make sure that the map creation is solid, repeatable and reliable prior to go to the next steps (sending navigation goals)

my idea is to create a solid map, then distribute it to all magnis and make it read-only.

The more i think about this, the more i beleive I should put the aruco markers on the floor, at fixed known locations. exactly like we create partition walls in buildings. Then manually create the map.txt. I dont really really need simultaneous mapping and localization. what i need is robustness and i am willing to make tradeoffs

i’l try sending goals today

I had to write my own /move_base_simple/goal publisher and /move_base/status suscriber to feed magni with the next goal when the current one is reached (based on known locations i taped on the floor and noted the corresponding pose with rosrun tf tf_echo map base_link while manually teleop it)

at least in the vicinity of the first makers i seems quite stable.

I even manually pested/forced the magni to manually move it while it was running: it managed to find it way back to the next goal. wow :smiley:

now I need to let it run for hours unattended until the battery collapse, make a timelapse and see if there is any slippage or issue.

i should be posting a video soon

Awesome!

Consider using a bigger battery if you need endurance. The 12350 is the biggest battery that the robot can accept. These are widely available as they are commonly used for wheelchairs.

thanks.

here’s the video.

it’s pretty obvious that i need to tune the parameters to give it maybe less tolerance on goals

@brunolfm

create a catkin pacakge named magni_goal_sender
cd ~/catkin_ws/src ; catkin_create_package magni_goal_sender

then put the files below where they belong and change the coordinates in the yaml file. (x, y, yaw in degrees)

start the thing with roslaunch magni_goal_sender go.launch

To get the coordinates, I put the yellow tape on the floor. then used rosrun tf tf_echo map base_link while teleop the magni to get to the corresponding orientation and built the yaml file accordingly

it’s very crude but it should get you up and running if you struggle to send goals.

ubuntu@magni02:~$ cat ~/catkin_ws/src/magni_goal_sender/param/goals.yaml
# x , y, yaw
# units; x/y => meters  |  yeaw => degrees
# tuse teleop to move magni, then use the following commande to see current pose
# rosrun tf tf_echo map base_link

goals:
 - 1.163, 0.451, 23.525
 - 2.296, 0.570, -38.058
 - 2.457, -0.384, -131.676
 - 1.224, -0.611, -173.067
 - 0.153, 0.158, 143.175
 - -1.035, 0.215, 179.176
 - -1.053, -1.386, -67.361
 - 0.0, 0.0, 0.0

ubuntu@magni02:~$ cat ~/catkin_ws/src/magni_goal_sender/launch/go.launch
<?xml version="1.0" encoding="UTF-8"?>
<launch>
  <!-- send goals -->
  <node name="goal_sender" pkg="magni_goal_sender" type="goal_sender.py" output="screen">
    <param name="param_filename" value="$(find magni_goal_sender)/param/goals.yaml"/>
    <param name="rate" value="25"/>
  </node>
</launch>
ubuntu@magni02:~$ cat ~/catkin_ws/src/magni_goal_sender/scripts/
goal_sender.py  test.py
ubuntu@magni02:~$ cat ~/catkin_ws/src/magni_goal_sender/scripts/goal_sender.py
#!/usr/bin/env python

import rospy
import yaml

#from math import sin, cos, pi
from math import radians # https://docs.python.org/2/library/math.html
from tf import transformations # for euler to

import time

#ubuntu@magni02:~$ rostopic info /move_base_simple/goal
#Type: geometry_msgs/PoseStamped
from geometry_msgs.msg import PoseStamped

#ubuntu@magni02:~$ rostopic info /move_base/status
#Type: actionlib_msgs/GoalStatusArray
#
#Publishers:
# * /move_basic (http://magni02.local:34847/)
from actionlib_msgs.msg import GoalStatusArray



class GoalSender:

    def __init__(self):
        rospy.init_node("goal_sender")
        self.nodename = rospy.get_name()
        rospy.loginfo("%s started" % self.nodename)

        #### parameters #######
        self.param_filename = rospy.get_param('~param_filename','/home/ubuntu/catkin_ws/src/magni_goal_sender/param/goals.yaml')  # where to find the goal list in yaml format
        rospy.loginfo("self.param_filename: %s" % self.param_filename)
        self.rate = rospy.get_param('~rate',20)  # how often do we update in Hz
        rospy.loginfo("self.rate: %s" % str(self.rate))
        self.load_goals()
        self.status = 3 # waiting for a new goal

        #### Publishers ####
        #self.goal_pub = rospy.Publisher("/move_base_simple/goal", geometry_msgs/PoseStamped, queue_size=10)
        self.goal_pub = rospy.Publisher("/move_base_simple/goal", PoseStamped, queue_size=10)
        time.sleep(0.5) # there must be at least  a 0.25sec delay  between publisher creation and message published => for the magni to actually move !?

        #### Subscribers ####
        rospy.Subscriber("/move_base/status", GoalStatusArray, self.status_callback)



    def load_goals(self):
        content = ""
        with open('/home/ubuntu/catkin_ws/src/magni_goal_sender/param/goals.yaml', 'r') as content_file:
            content = content_file.read()
        #print(yaml.dump(yaml.load(content)))
        yml = yaml.load(content)
        self.goals = yml['goals']
        self.index = 0
        rospy.loginfo("done loading goals")

        #for i in range(0,len(self.goals)):
        #    goal = self.goals[i].split(',')
        #    print(self.to_pose_stamped(float(goal[0]), float(goal[1]), float(goal[2])))


    def spin(self):
        r = rospy.Rate(self.rate)
        while not rospy.is_shutdown():
            self.update()
            r.sleep()

    def update(self):
        # known statuses
        #status: 1 | text: "This goal has been accepted by the simple action server"]  | magni is executing the goal command
        #status: 3 | text: ""]  | the magni is waiting for a goal



        if self.status == 3:
            goal = self.goals[self.index].split(',')
            # sending goal using command line
            # ubuntu@magni02:~$ rostopic pub -1 /move_base_simple/goal geometry_msgs/PoseStamped '{header: {stamp: now, frame_id: "map"}, pose: {position: {x: 1.0, y: 0.0, z: 0.0}, orientation: {w: 1.0}}}'
            # publishing and latching message for 3.0 seconds
            # ubuntu@magni02:~$

            pose = self.to_pose_stamped(float(goal[0]), float(goal[1]), float(goal[2]))
            rospy.loginfo("Sending goal pose "+str(self.index)+" to /move_base_simple/goal")
            #rospy.loginfo(str(pose))
            self.goal_pub.publish(pose)
            self.index += 1
            if self.index >= len(self.goals):
                self.index = 0
            time.sleep(0.5) # give time for callback to be called


        elif self.status == 1:
            x = 0 # do nothing since magni is executing the move command
            # status_callback will move the current status back to '3' once the goal is reached
            #rospy.loginfo("waiting for goal to be reached")
        else:
            rospy.logwarn("unknown status: %s" % self.status)



    def to_pose_stamped(self,x,y,theta_in_degrees):
        pose = PoseStamped()
        pose.header.stamp = rospy.Time.now()
        pose.header.frame_id = "map"
        pose.pose.position.x = x
        pose.pose.position.y = y
        pose.pose.position.z = 0.0

        quaternion = transformations.quaternion_from_euler(0.0, 0.0, radians(theta_in_degrees))
        pose.pose.orientation.x = quaternion[0]
        pose.pose.orientation.y = quaternion[1]
        pose.pose.orientation.z = quaternion[2]
        pose.pose.orientation.w = quaternion[3]

        return pose
    # source of inspiration => https://github.com/xaxxontech/oculusprime_ros/blob/master/src/global_path_follower.py
    def status_callback(self, msg):
        #rospy.loginfo(msg)
        #rospy.loginfo(msg.status_list)
        if len(msg.status_list) == 0:
            return

        self.status = msg.status_list[len(msg.status_list)-1].status # get latest status


if __name__ == '__main__':
    """ main """
    goal_sender = GoalSender()
    goal_sender.spin()



ubuntu@magni02:~$

Looks good! Also you could consider adjusting your acceleration and Jerk limits, as well as potentially sending new goals before you reached your old one. Right now your robot starts slowing down as it reaches its goal.

You could consider using this package for managing waypoints:

http://wiki.ros.org/follow_waypoints

Further if you like this approach we can package it as standard on our distribution - this will make it a lot easier for you to support. We can also use ROS hub to do fleet wide web based dispatch.

i would rather use the community packages as long as they are popular, reliable and properly maintained. I wrote this because my first goal – no pun intented :smiley: – is to evaluate as soon as possible whether or not I can use magni for real.

I’ll look into follow_waypoints. Indeed it’s annoying to see the magni stopping entirely before moving on to the new goal. How do I adjust accelerations and jerk limits?

i tried sudo apt-get install ros-kinetic-follow-waypoints as suggested by its documentation
it does install something.

I tried to start it but there is an error message. and indeed the ‘launch’ directory isn’t there. In fact it’s basically empty.

ubuntu@magni02:~$ roslaunch follow_waypoints follow_waypoints.launch
[follow_waypoints.launch] is neither a launch file in package [follow_waypoints]                                                      nor is [follow_waypoints] a launch file name
The traceback for the exception was written to the log file
ubuntu@magni02:~$ roscd follow_waypoints
ubuntu@magni02:/opt/ros/kinetic/share/follow_waypoints$ ll
total 24
drwxr-xr-x   3 root root  4096 Oct  4 15:00 ./
drwxr-xr-x 256 root root 12288 Oct  4 15:00 ../
drwxr-xr-x   2 root root  4096 Oct  4 15:00 cmake/
-rw-r--r--   1 root root  1112 Jul 15  2017 package.xml

I tried to create a new catkin package that depends on follow_waypoints and then catkin_make it in the hope to fix things… to no avail.

ubuntu@magni02:~/catkin_ws/src$ catkin_create_pkg deleteme rospy follow_waypoint                                                     s
Created file deleteme/CMakeLists.txt
Created file deleteme/package.xml
Created folder deleteme/src
Successfully created files in /home/ubuntu/catkin_ws/src/deleteme. Please adjust                                                      the values in package.xml.
ubuntu@magni02:~/catkin_ws/src$ cd ..
ubuntu@magni02:~/catkin_ws$ catkin_make
[...]
-- ==> add_subdirectory(deleteme)
CMake Error at /opt/ros/kinetic/share/follow_waypoints/cmake/follow_waypointsCon                                                     fig.cmake:148 (message):
  Project 'deleteme' tried to find library 'follow_waypoints'.  The library
  is neither a target nor built/installed properly.  Did you compile project
  'follow_waypoints'? Did you find_package() it before the subdirectory
  containing its code is included?
Call Stack (most recent call first):
  /opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
  deleteme/CMakeLists.txt:10 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/ubuntu/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/ubuntu/catkin_ws/build/CMakeFiles/CMakeError.log".
Invoking "cmake" failed
ubuntu@magni02:~/catkin_ws$ 

Also, even if it had worked, it seems follow_waypoints send goal messages to /move_base instead of /move_base_simple and it didn’t spot in the documentation how we should glue things together here.

I’m confused.

how am i supposed to use follow_waypoints then?

Looks like follow_waypoints is pretty broken when installed from apt. Sorry about that, we had not done any of our own evaluation before recommending it.

i would rather use the community packages as long as they are popular, reliable and properly maintained

Agreed, and looks like follow_waypoints doesn’t really fit this criteria at the moment. For now I would continue building out your basic solution.

As for acceleration and jerk limiting, this is adjustable, but will not stop the annoying move_basic behavior as it will still do its own smoothing to reach its target goal.

If you want to play around with acceleration/jerk limits you can edit /opt/ros/kinetic/share/magni_bringup/param/base.yaml.
For jerk limits you will have to add the following below the acceleration limit lines.

has_jerk_limits: true
max_jerk: 4.0

Rohan

ok. what is jerk anyway ?
EDIT: and how can i tweak precision/tolerance params again?

Jerk is the rate of change of acceleration, a high jerk results in the hard stop feeling you get when you slam on the brakes.

You can edit those parameters in /opt/ros/kinetic/share/magni_nav/launch/move_basic.launch

http://wiki.ros.org/move_basic#Parameters

Rohan

in order to determine if the lack of precision comes from mave_basic of the localization system or both. I will focus on measuring the localization thing first by using a recap of david’s suggested procedure i’ll recap here:

  1. prepare a given circuit that makes the magni see from various locations and orientations all fiducials/aruco markers. zig zag around this path and make it at least 10 times.

  2. use sharp pencils at fixed locations on either sides of magni to be able to write on the floot where magni goes when required. move magni to a given waypoint and mark the floor where the pencil tip shows.

  3. Move the robot to another fixed waypoint at some other location (say waypoint 2) with a similar procedure again measure the location that the fiducial localization says it is in.

  4. Move to say a 3rd or even 4th location repeat the measurements of position

  5. Move back to the first location repeat the measurements, then 2nd, 3rd 4th and so forth. Repeat this process say 8-10 times. We have 10 measurements per waypoint

  6. we can calculate the variance of the positions obtained from the fiducial localization system

I used the following “circuit”, zigzag around it to introduce as much locations/orientations as possible. It ook about 1h30 (between 15h and 16h30 with mixed articial and natural lighting conditions

after about 1h30 i got ~45000 observations [~2000 observations per fiducial on average) and ended up with the following map

[ INFO] [1539180446.755647396]: Got image 44745
^C[fiducial_slam-4] killing on exit
[ INFO] [1539180446.863695534]: Saving map with 23 fiducials to file /home/ubuntu/.ros/slam/map.txt
[...]
ubuntu@magni02:~$ cat /home/ubuntu/.ros/slam/map.txt
250 2.958617 -0.426157 2.828279 176.598483 -5.309616 -84.441487 0.010109 3546 251 252 253 254 257 258 259 260 262
251 1.620598 -0.455189 2.809530 -178.006563 4.082281 88.271863 0.010077 4514 250 252 253 254 255 256 257 258 259 262 264
252 2.997544 1.090013 2.717102 -177.834646 4.196037 90.338021 0.010208 782 250 251 253 257 258 259
253 1.375898 0.862551 2.738117 -179.012535 2.701081 92.061152 0.010047 10436 250 251 252 254 255 256 257 258 262
254 -0.494602 0.859393 2.808684 -178.365571 4.235831 94.227170 0.010103 9478 250 251 253 255 256 257 264
255 -0.954411 -0.513291 2.908981 -176.604959 3.918727 92.242582 0.000000 9 251 253 254 256 257 262 263 264
256 -0.514375 -1.272313 2.462669 176.638848 -6.013929 -89.872924 0.010161 1236 251 253 254 255 257 262 263 264
257 1.400984 -1.250831 2.507234 176.933133 -5.318964 -90.546631 0.010107 580 250 251 252 253 254 255 256 258 259 262 264
258 3.188275 -1.248039 2.455588 179.191554 -5.098046 -89.981270 0.010287 1218 250 251 252 253 257 259 260 262
259 3.155876 -2.257357 3.158109 -178.418654 7.128254 86.311893 0.010124 1708 250 251 252 257 258 260 261 262 266 267 268
260 3.152600 -3.342859 3.282641 -179.675750 6.978581 83.847761 0.010093 2398 250 258 259 261 262 266 267 268 269
261 1.615699 -3.441204 3.414343 -176.470577 5.694859 95.045220 0.010232 2934 259 260 262 263 264 265 266 267 268 271
262 1.504001 -2.287420 3.090392 177.215793 -3.984730 -85.654877 0.010446 916 250 251 253 255 256 257 258 259 260 261 263 264 265 266 267 268 271
263 -0.792357 -3.694619 3.408216 176.104403 -5.730900 -87.902450 0.010141 2182 255 256 261 262 264 265 266 271 272
264 -0.970773 -2.224056 3.027526 -177.345021 3.846482 94.142175 0.010174 1202 251 254 255 256 257 261 262 263 265 271
265 -0.030388 -4.413217 3.115232 -177.761065 7.488781 89.341076 0.010148 1888 261 262 263 264 266 270 271 272
266 1.606099 -4.397638 3.005675 -179.740728 6.828347 89.358747 0.010124 1336 259 260 261 262 263 265 267 268 271
267 3.169947 -4.388653 2.966473 -178.423491 7.128782 89.836841 0.010114 1480 259 260 261 262 266 268 269
268 3.229343 -5.399702 3.631839 -178.369688 9.383552 86.431052 0.010074 1402 259 260 261 262 266 267 269 270
269 3.165287 -6.601775 3.837521 -176.435532 9.278814 89.805632 0.010258 774 260 267 268 270
270 1.392048 -6.684173 4.063386 -175.802269 9.756063 90.657479 0.010139 760 265 268 269 271 272
271 -0.181288 -5.200901 3.650972 -175.539315 7.104435 92.342895 0.010125 1336 261 262 263 264 265 266 270 272
272 -0.286242 -6.401931 3.768549 -178.766750 7.627164 89.105297 0.010153 692 263 265 270 271
ubuntu@magni02:~$

and this is the pencils I attached to “precisely” mark magni’s location on the floor (yes I need to sharpen then indeed)

I’ll continue later

Looks good. Store that data set of observations as you’ll likely have and opportunity for a high quality global optimization with it that may improve localization accuracy.

You’ll also have the opportunity to use the read only mode.

Both of these are at various stages of development. I think its safe to say that the read only mode will be released in a few days. Global optimization is under development.

1 Like

I did some more experiment today.

First of all, I did an apt update ; apt upgrade -y
I understand that some new functionality is available, but i have not changed my scripts to try to make use of it.

First of all, just going from one way_point, stay there, and try to get the reported localizaton.
To my surprise, it seems to fluctuate a lot already.

`rosrun tf tf_echo map base_link | egrep ‘Translation|degree’
Ànd then plot the reported data.

Each point seems to fits in a 10 x 10 cm window on XY and about 0.3 degrees on theta

I was expecting something in the 1 x 1 cm window on XY. for Theta I guess it’s ok?

Is this the expected behavior?

I did locate the position on the floor using a thin marker with the two pointing pencils in order to drive back there later. But i would rather that we align on expectations first.

image

below what got upgraded prior to measuring

root@magni02:~# apt list --upgradable
Listing... Done
firefox/xenial-updates,xenial-security 62.0.3+build1-0ubuntu0.16.04.2 armhf [upgradable from: 52.0.2+build1-0ubuntu0.16.04.1]
initramfs-tools/xenial-updates 0.122ubuntu8.13 all [upgradable from: 0.122ubuntu8.12]
initramfs-tools-bin/xenial-updates 0.122ubuntu8.13 armhf [upgradable from: 0.122ubuntu8.12]
initramfs-tools-core/xenial-updates 0.122ubuntu8.13 all [upgradable from: 0.122ubuntu8.12]
libsmbclient/xenial-updates 2:4.3.11+dfsg-0ubuntu0.16.04.17 armhf [upgradable from: 2:4.3.11+dfsg-0ubuntu0.16.04.16]
libwbclient0/xenial-updates 2:4.3.11+dfsg-0ubuntu0.16.04.17 armhf [upgradable from: 2:4.3.11+dfsg-0ubuntu0.16.04.16]
openssh-client/xenial-updates 1:7.2p2-4ubuntu2.5 armhf [upgradable from: 1:7.2p2-4ubuntu2.4]
openssh-server/xenial-updates 1:7.2p2-4ubuntu2.5 armhf [upgradable from: 1:7.2p2-4ubuntu2.4]
openssh-sftp-server/xenial-updates 1:7.2p2-4ubuntu2.5 armhf [upgradable from: 1:7.2p2-4ubuntu2.4]
python-catkin-pkg/xenial 0.4.9-100 all [upgradable from: 0.4.8-100]
python-catkin-pkg-modules/xenial 0.4.9-1 all [upgradable from: 0.4.8-1]
python3-update-manager/xenial-updates 1:16.04.14 all [upgradable from: 1:16.04.13]
ros-kinetic-aruco-detect/xenial 0.10.0-0xenial~tbpo1 armhf [upgradable from: 0.9.0-0xenial~tbpo1]
ros-kinetic-base-local-planner/xenial 1.14.4-0xenial-20181007-131314-0800 armhf [upgradable from: 1.14.4-0xenial-20180826-200605-0800]
ros-kinetic-bond/xenial 1.8.3-0xenial-20181006-210515-0800 armhf [upgradable from: 1.8.1-0xenial-20180826-005719-0800]
ros-kinetic-bond-core/xenial 1.8.3-0xenial-20181007-032324-0800 armhf [upgradable from: 1.8.1-0xenial-20180826-040221-0800]
ros-kinetic-bondcpp/xenial 1.8.3-0xenial-20181007-030253-0800 armhf [upgradable from: 1.8.1-0xenial-20180826-022740-0800]
ros-kinetic-bondpy/xenial 1.8.3-0xenial-20181007-030539-0800 armhf [upgradable from: 1.8.1-0xenial-20180826-034611-0800]
ros-kinetic-clear-costmap-recovery/xenial 1.14.4-0xenial-20181007-131422-0800 armhf [upgradable from: 1.14.4-0xenial-20180826-201303-0800]
ros-kinetic-common-tutorials/xenial 0.1.10-0xenial-20181007-111640-0800 armhf [upgradable from: 0.1.10-0xenial-20180826-164631-0800]
ros-kinetic-compressed-image-transport/xenial 1.9.5-0xenial-20181007-052525-0800 armhf [upgradable from: 1.9.5-0xenial-20180826-181518-0800]
ros-kinetic-costmap-2d/xenial 1.14.4-0xenial-20181007-092441-0800 armhf [upgradable from: 1.14.4-0xenial-20180826-170043-0800]
ros-kinetic-desktop/xenial 1.3.2-0xenial-20181007-124520-0800 armhf [upgradable from: 1.3.2-0xenial-20180830-150735-0800]
ros-kinetic-diagnostic-aggregator/xenial 1.9.3-0xenial-20181007-054349-0800 armhf [upgradable from: 1.9.3-0xenial-20180826-043101-0800]
ros-kinetic-diagnostics/xenial 1.9.3-0xenial-20181007-090858-0800 armhf [upgradable from: 1.9.3-0xenial-20180826-174900-0800]
ros-kinetic-diff-drive-controller/xenial 0.13.4-0xenial-20181007-044612-0800 armhf [upgradable from: 0.13.4-0xenial-20180826-135727-0800]
ros-kinetic-dnn-detect/xenial 0.0.3-0xenial-20181007-045908-0800 armhf [upgradable from: 0.0.3-0xenial-20180828-192206-0800]
ros-kinetic-dynamic-reconfigure/xenial 1.5.50-0xenial-20181006-210933-0800 armhf [upgradable from: 1.5.49-0xenial-20180826-100037-0800]
ros-kinetic-fiducial-msgs/xenial 0.10.0-0xenial~tbpo1 armhf [upgradable from: 0.9.0-0xenial~tbpo1]
ros-kinetic-fiducial-slam/xenial 0.10.0-0xenial~tbpo1 armhf [upgradable from: 0.9.0-0xenial~tbpo1]
ros-kinetic-loki-demos/xenial 0.0.2-0xenial-20181007-135607-0800 armhf [upgradable from: 0.0.2-0xenial-20180828-195544-0800]
ros-kinetic-loki-nav/xenial 0.0.2-0xenial-20181007-135111-0800 armhf [upgradable from: 0.0.2-0xenial-20180828-195122-0800]
ros-kinetic-loki-robot/xenial 0.0.2-0xenial-20181007-140141-0800 armhf [upgradable from: 0.0.2-0xenial-20180828-195915-0800]
ros-kinetic-move-base/xenial 1.14.4-0xenial-20181007-142859-0800 armhf [upgradable from: 1.14.4-0xenial-20180826-213108-0800]
ros-kinetic-move-basic/xenial 0.3.2-0xenial-20181007-131916-0800 armhf [upgradable from: 0.3.2-0xenial-20180826-200752-0800]
ros-kinetic-nav-core/xenial 1.14.4-0xenial-20181007-124438-0800 armhf [upgradable from: 1.14.4-0xenial-20180826-193734-0800]
ros-kinetic-navfn/xenial 1.14.4-0xenial-20181007-131424-0800 armhf [upgradable from: 1.14.4-0xenial-20180826-200610-0800]
ros-kinetic-nodelet/xenial 1.9.14-0xenial-20181007-054434-0800 armhf [upgradable from: 1.9.14-0xenial-20180826-024809-0800]
ros-kinetic-nodelet-core/xenial 1.9.14-0xenial-20181007-085708-0800 armhf [upgradable from: 1.9.14-0xenial-20180826-110150-0800]
ros-kinetic-nodelet-topic-tools/xenial 1.9.14-0xenial-20181007-062732-0800 armhf [upgradable from: 1.9.14-0xenial-20180826-103104-0800]
ros-kinetic-nodelet-tutorial-math/xenial 0.1.10-0xenial-20181007-090106-0800 armhf [upgradable from: 0.1.10-0xenial-20180826-034308-0800]
ros-kinetic-pcl-ros/xenial 1.4.4-0xenial-20181007-064405-0800 armhf [upgradable from: 1.4.4-0xenial-20180826-142101-0800]
ros-kinetic-raspicam-node/xenial 0.3.0-0xenial armhf [upgradable from: 0.2.2-0xenial]
ros-kinetic-robot/xenial 1.3.2-0xenial-20181007-111031-0800 armhf [upgradable from: 1.3.2-0xenial-20180826-175337-0800]
ros-kinetic-ros-base/xenial 1.3.2-0xenial-20181007-090143-0800 armhf [upgradable from: 1.3.2-0xenial-20180826-131814-0800]
ros-kinetic-rotate-recovery/xenial 1.14.4-0xenial-20181007-135645-0800 armhf [upgradable from: 1.14.4-0xenial-20180826-205312-0800]
ros-kinetic-rqt-common-plugins/xenial 0.4.8-0xenial-20181007-114131-0800 armhf [upgradable from: 0.4.8-0xenial-20180830-145757-0800]
ros-kinetic-rqt-gui-cpp/xenial 0.5.0-0xenial-20181007-083744-0800 armhf [upgradable from: 0.5.0-0xenial-20180830-140636-0800]
ros-kinetic-rqt-image-view/xenial 0.4.13-0xenial-20181007-111111-0800 armhf [upgradable from: 0.4.13-0xenial-20180830-142934-0800]
ros-kinetic-rqt-reconfigure/xenial 0.4.10-0xenial-20181007-045603-0800 armhf [upgradable from: 0.4.10-0xenial-20180830-142717-0800]
ros-kinetic-rqt-robot-plugins/xenial 0.5.7-0xenial-20181007-123343-0800 armhf [upgradable from: 0.5.7-0xenial-20180830-145340-0800]
ros-kinetic-rqt-rviz/xenial 0.5.10-0xenial-20181007-111109-0800 armhf [upgradable from: 0.5.10-0xenial-20180830-142839-0800]
ros-kinetic-sick-tim/xenial 0.0.13-0xenial-20181007-050322-0800 armhf [upgradable from: 0.0.13-0xenial-20180826-163438-0800]
ros-kinetic-smclib/xenial 1.8.3-0xenial-20181006-210825-0800 armhf [upgradable from: 1.8.1-0xenial-20180810-203332-0800]
ros-kinetic-viz/xenial 1.3.2-0xenial-20181007-124023-0800 armhf [upgradable from: 1.3.2-0xenial-20180830-150305-0800]
samba-libs/xenial-updates 2:4.3.11+dfsg-0ubuntu0.16.04.17 armhf [upgradable from: 2:4.3.11+dfsg-0ubuntu0.16.04.16]
update-manager/xenial-updates 1:16.04.14 all [upgradable from: 1:16.04.13]
update-manager-core/xenial-updates 1:16.04.14 all [upgradable from: 1:16.04.13]
root@magni02:~#