Marcin Kaszyński

Empathy for the Maintainer

Sun, 15 Sep 2019 00:00:00 +0200

I’ve been thinking a lot about communication and code quality over the past couple of years. It’s nothing new of course, I’m not the only one, but I believe that most of ways we address it start with a wrong perspective, and a wrong focal point.

(this is a heavily edited and expanded text version of my lightning talk at PyCon PL 2019)

Disclaimer: I don’t claim to know how to write good code. I’m drawing from my ~30 years of experience writing bad one.

There is plenty of advice on how to write good code. The Zen of Python, the DRY/Once and Only Once, a whole bunch of software metrics, random advice like particular naming schemes and attempts at consistency. Most of those are very procedural. Which is understandable, they are mostly created by techies for techies, procedures is what we do for a living and what we tend to expect.

But these are bad rules. Because, really, they are not rules at all. They are guidelines. Tools.

Writing code is a lot like writing prose. You have one extra restriction (it has to be executable, and perform some task as it runs), but other than that you get a similar level of flexibility, complexity, and the same problem: how to convey your goals, ideas, and reasoning to other people. Yes, people.

If you focus on tools instead of communication, just like with prose you will get a result that is correct, to some definition of correct. So, congrats! But it might not be the definition you really want.

We need to start from a different direction, with a different focus, and that focus should be empathy.

To be more specific: empathy for the maintainer.

Who, with high probability, might also be you.

After a long break from the project.

On a tight deadline.

Because you have a fire on production and everyone else on the team is also involved with some aspect of that fire, so you go into the code and what happens is:

If you already know this exact scenario: good, it’s a blessing in disguise. It’s a rare chance to see your own code with completely fresh eyes; it’s some of the best, most humbling feedback you can get.

(and if you don’t, don’t worry! it’s all ahead of you)

Let’s approach the problem from a different direction. Here is the situation:

you

the maintainer

There are you now, and there is the maintainer in the future. Who, again, might be an older you, but not necessarily.

The two you communicate via the source code:

you
↓
[your code]
↓
the maintainer

Assume this is the only means of communication. It’s uni-directional: you will not get immediate feedback on whether what you sent along the wire is sufficient to understand you. So put yourself in the position of the person who will receive that communication and ask some questions:

How understandable is it? Are there any unnecessarily tricky parts? What can you simplify? Again, assume a fresh look by someone who does not know the full history of the project.
How much of other code do they have to read? If your file or function a cohesive part of the larger whole, readable on its own? Is the control flow visible and readable? How much of the surrounding package, library, or project do they have to read to make sense of it?
What can you assume they already know? The language, the framework[s], the libraries you used, and the project this file is part of, all create their own conventions and vocabulary; the deeper in this hierarchy, the less you can rely on it.
Most importantly: how can you help them understand it? If you have any experience working as a developer, you already know how it feels to stare at someone else’s code, trying to make sense of it. What do you remember from situations like that? What would have helped you? (you might want to answer “documentation” or “comments”; neither is a good main resource for understanding code, so focus on the code itself)

And then, with those questions in mind, take a look at the tools at your disposal:

conventions: not all conventions are of equal value; look for the ones that are widely shared, for example: if your code does something similar to things that are in standard library, use a similar interface, so that people can recognise it,
vocabulary: variables are nouns, functions and methods are verbs, use them to explain what’s going on,
control flow: if the reader can analyse code from top to bottom, following the control flow and choosing parts to read more closely, it will be easier for them than if they have to jump between multiple unrelated files to piece together the top-level behavior,

and all the other tools mentioned at the beginning of this text. Use them as a catalogue of ideas to address the questions. Things to try out and use where you notice they help.

Don’t stop when your code starts doing what you want it to do. Make it work first, but then keep editing it to make it readable. Take a break, return to the code after a while and see if you can edit it some more.

You may think you have no time for it, and are in the hurry to deliver functionality; in most cases that is not true. If you work on a real-life project, in a team larger than a single person, you have no time not to do it. Whatever you save here you and your team will repay in the future, with interest, when trying to maintain the code.

Empathise with the maintainer. It will make you a better programmer.

How auth works in EKS with IAM Users

Thu, 12 Jul 2018 00:00:00 +0200

This was not trivial to find: how exactly does authentication and authorization work in EKS if you want to use IAM Users or Roles to authenticate?

As an example, what happens when you run kubectl auth can-i get pods?

Prerequisites

You will need to install aws command line tools, kubectl, and heptio-authenticator-aws; make sure they are on PATH. I also use jq, shyaml, and httpie in examples.

Client-side configuration: AWS

In case of EKS there are two parts to configure: AWS command line tools (AWS CLI) and kubectl. I need to access multiple clusters using multiple credentials, so I’ll cover that more generic case here.

The usual way to configure AWS is to run aws configure --profile <profile-name>, but you can just as well just edit ~/.aws/config and ~/.aws/credentials:

[@trurl ~] cat .aws/config
 [default]
 region = us-west-2
 [profile some-other-profile]
 region = us-west-2
 [profile profile-that-uses-iam-role]
 region = us-west-2

[@trurl ~] cat .aws/credentials
 [default]
 aws_access_key_id = [REDACTED]
 aws_secret_access_key = [REDACTED]
 [some-other-profile]
 aws_access_key_id = [REDACTED]
 aws_secret_access_key = [REDACTED]
 [profile-that-uses-iam-role]
 role_arn = <ARN of the role to assume>
 source_profile = <name of profile used for auth before assuming this role>

IAM has two kinds of identity entities: users and roles. An IAM User is what you’d expect: it has an username and credentials, belongs to some groups, has permissions attached to it. An IAM Role is similar, but it’s an identity that a user or a process may assume temporarily for the purpose of performing some actions. IAM Users are usually used for human interaction with AWS; IAM Roles are usually used for automated access, for example: when EKS server wants to tell AWS it needs to start a new node, it can manage that part of your AWS account only because it authenticates into a role that has sufficient permissions in the account.

AWS CLI always starts with credentials of an IAM user (or the account owner, although you should use that identity only to create an IAM user to interact with your account); you can also assume a role, like in the last profile, but I won’t use that here.

If your configuration is correct, you can do this:

# You may omit the AWS_PROFILE=..., aws will use the default
[@trurl ~] export AWS_PROFILE=<profile-name>
[@trurl ~] aws sts get-caller-identity
 {
     "Account": "[REDACTED]",
     "UserId": "[REDACTED]",
     "Arn": "arn:aws:iam::[REDACTED]:user/<username>"
 }

If you created a cluster, you can now ask AWS for information necessary to access it:

[@trurl ~] aws eks list-clusters
 {
     "clusters": [
         "my-cluster",
         [...]
     ]
 }
[@trurl ~] aws eks describe-cluster --name=my-cluster
 {
     "cluster": {
         "status": "ACTIVE",
         "endpoint": "https://[REDACTED].[REDACTED].us-west-2.eks.amazonaws.com",
         "name": "my-cluster",
         "certificateAuthority": {
             "data": "[REDACTED]"
         },
         [...]
     }
 }

Client-side configuration: kubectl

Now that you have AWS CLI running, create configuration file for kubectl. You can have a single file for multiple clusters, but it’s cleaner to have a separate file for every cluster. The location does not matter, I use ~/.kube/config.d/<cluster-name>.

Example file:

[@trurl ~] cat ~/.kube/config.d/my-cluster
 apiVersion: v1
 clusters:
 - cluster:
     certificate-authority-data: <certificateAuthority.data from describe-cluster>
     server: <endpoint from describe-cluster>
   name: <cluster-name>
 contexts:
 - context:
     cluster: <cluster-name>
     user: aws
   name: aws
 current-context: aws
 kind: Config
 preferences: {}
 users:
 - name: aws
   user:
     exec:
       apiVersion: client.authentication.k8s.io/v1alpha1
       args:
       - token
       - -i
       - <cluster-name>
       command: heptio-authenticator-aws
       env:
       - name: AWS_PROFILE
         value: <profile-name>

This file tells kubectl:

the base URL for the cluster’s API server (cluster.server),
the certificate authority data to use for TLS verification (certificate-authority-data),
that for authentication it should use bearer tokens generated by heptio-authenticator-aws.

heptio-authenticator-aws does not execute any remote calls; it just creates a signed token based on cluster name and credentials from your AWS_PROFILE:

[@trurl ~] heptio-authenticator-aws token -i my-cluster
 {
   "kind": "ExecCredential",
   "apiVersion": "client.authentication.k8s.io/v1alpha1",
   "spec": {},
   "status": {
     "token": "[REDACTED]"
   }
 }

If your configuration is correct AND you have permissions set right, this should work:

[@trurl ~] export KUBECONFIG=~/.kube/config.d/my-cluster
[@trurl ~] kubectl auth can-i get pods
yes

You might also see one of these:

[@trurl ~] kubectl auth can-i get pods
 error: You must be logged in to the server (Unauthorized)

meaning there’s something wrong with authentication, or:

[@trurl ~] kubectl auth can-i get pods
 no

meaning that authentication went well, but authorization did not. I’ll address both below.

Authentication

Kubernetes has two kinds of users:

Service accounts: they are just what you would expect from user accounts; they are first class entities in Kubernetes, available through its API. you can use them with EKS, but there is nothing EKS-specific here as they sidestep all the IAM machinery; and there already exist better guides about this branch, so I’ll skip them here.

Normal users: managed completely outside Kubernetes; the API server trusts some external software to provide it with the username and groups for every request it receives. This is what EKS uses when you authenticate using IAM identities, and this is what I’ll cover here.

When you execute a kubectl command it does a REST call to Kubernetes’s API server and sends the token generated by heptio-authenticator-aws in the Authentication header. When you kubectl auth can-i get pods, the client does more or less this:

# Store the CA data in a file for TLS verification; you can skip it if
# you're fine with the insecure `--verify=no` in http call below.
[@trurl ~] cat ~/.kube/config.d/my-cluster \
    | shyaml get-value 'clusters.0.cluster.certificate-authority-data' \
    | base64 -D > ~/.kube/config.d/my-cluster-ca-data

# Generate the authentication token
[@trurl ~] TOKEN=`heptio-authenticator-aws token -i my-cluster | jq -r .status.token`

[@trurl ~] REQUEST='{"kind": "SelfSubjectAccessReview", "apiVersion": "authorization.k8s.io/v1", "spec":{"resourceAttributes":{"name":"pod","verb":"get"}}}'

[@trurl ~] echo "$REQUEST" \
    | http --verify=~/.kube/config.d/my-cluster-ca-data \
      post https://[REDACTED].[REDACTED].us-west-2.eks.amazonaws.com/apis/authorization.k8s.io/v1/selfsubjectaccessreviews \
      Authorization:"Bearer $TOKEN"
 HTTP/1.1 201 Created
 Content-Length: 196
 Content-Type: application/json
 Date: Wed, 11 Jul 2018 01:21:27 GMT
 
 {
     [...]
     "status": {
         "allowed": true
     }
 }

On the server side Kubernetes passes the token to a webhook to the aws-iam-authenticator process running on EKS host; if all goes well the authenticator returns a “normal user” identity consisting of username (a string) and groups (a list of strings containing group names). If that works, that is when authentication ends.

If it fails then it means that you attempted to execute the request using an IAM User or Role that the aws-iam-authenticator running on your cluster does not know how to map to a “normal user” in Kubernetes space.

There are essentially two cases here:

The IAM User or Role that was used to create the cluster is hardwired in aws-iam-authenticator configuration to map to a “normal user” who belongs to the system:masters group. This part is not visible anywhere in data you can reach via kubectl and aws commands, but that also means you can’t modify it.

For other IAM Users or Roles you must configure aws-iam-authenticator by setting the aws-auth configmap. If you went far along with the cluster to actually add some nodes it means you must have created that configmap already, since it’s the same thing that lets the cluster authenticate its nodes. If not, you might want to look into Getting Started with Amazon EKS.

To authenticate another IAM User or Role, you have to add user or role mappings:

[@trurl ~] cat /tmp/aws-auth-cm
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: aws-auth
   namespace: kube-system
 data:
   mapRoles: |
     - rolearn: <ARN of instance role (not instance profile)>
       username: system:node:{{EC2PrivateDNSName}}
       groups:
         - system:bootstrappers
         - system:nodes
     - rolearn: <ARN of some-other-role>
       username: some-other-role
       groups:
         - system:masters
   mapUsers: |
     - userarn: <ARN of other-user>
       username: other-user
       groups:
         - system:masters
[@trurl ~] KUBECONFIG=~/.kube/config.d/my-cluster kubectl apply -f /tmp/aws-auth-cm
configmap "aws-auth" configured

I added some-other-role and other-user to the configuration, and for simplicity added them both to system:masters.

Authorization

There is nothing EKS-specific in authorization process; in particular, any permissions or policies attached to IAM Users don’t mean anything, you’re talking directly to Kubernetes API server, and it uses IAM only for authentication.

EKS clusters run in RBAC mode, meaning you grant permissions by binding roles to identities. In above examples I did not have to do that because I depended on aws-iam-authenticator to return the system:masters group for all identities I used, and that is a built-in group that has full permissions to the cluster. That’s the simplest thing and most likely what you want to do for manual interaction with the cluster anyway. For cases where that’s not enough and you would prefer to grant less permissions to an account, there are much better guides, in particular Using RBAC Authorization in Kubernetes docs.

My main code quality guideline

Fri, 21 Apr 2017 00:00:00 +0200

…is not succintness, removing duplication, reducing the number of nested loops, any particular naming scheme or a style guide. It is, instead, asking myself the question how tricky will the code be to understand if I have to fix it after switching to something else for half a year?

Or to put it another way: assuming I forget this code completely and have to return to fix a bug in some function, how much of the surrounding module|library|app do I have to get in my head to see what is going on?

[W]e want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

Abelson & Sussman, Structure and Interpretation of Computer Programs

I know for a fact that most of the code I write will at some point be modified, fixed, and extended by someone who does not know it. In many cases that someone will be me after switching to something else for long enough to forget the code completely. It makes perfect sense to optimise for that by attempting to minimise the cost of understanding it.

It sounds blurry, but that’s only because it is. From this angle and with a bit of a squint coding starts to look like creating prose with the additional requirement of the result being executable, and suddenly we get all the blurriness and difficulty of writing English¹. There are no strict rules that guarantee readability, just general guidelines, rules of thumb, and the hope that I can tap into some context I share with future maintainers.

Assumptions

In the case of prose you can assume the reader understands the language and has certain level of common knowledge. In the case of code, I assume that they know the language fairly well; not just the syntax, but also conventions used by its standard library.

These assumptions are not always met, but that’s okay; in that case if I manage to make my code conform to conventions it will help the reader build the right intuition for the community; otherwise I would be one of people responsible for the deterioration of quality within it, and would actively get in someone’s way to improve their skills.

Conventions

Conventions are good. Conventions are decisions for free. Conventions are lower cognitive load when reading code and when writing it. Conventions are patterns and people are great at recognising those. Use them. Don’t clash with them.

If something looks similar to what people already know and understand, they will naturally assume it behaves similar. Use that whenever possible, treat it as a way to avoid having to explain things.

You have multiple levels of conventions at your disposal: language (idioms and patterns established by the standard library), framework (Django introduced some good conventions early on), project, module. The higher level you manage to use, the easier it will be for random programmer to understand the reference.

Vocabulary

You create it whether you want it or not, you might as well use that to your advantage. Function and variable names are roughly verbs and nouns, when someone tries to understand your code that’s how they are going to read it.

Good names make it easier to reason about the code. Bad names require the reader to go read some other piece of code to understand what’s going on. Very bad names are actively misleading.

Inheritance

It’s a big one. Many class hierarchies obscure the flow of code and make discovery more difficult.

And sure, it’s just as easy to come up with examples of bad function composition, but the common approach of “here’s a class that implements the top-level code flow, override pieces in subclasses to tweak or configure it” requires the reader to have a fairly good understanding of the superclass, and makes it trickier to follow the code.

It’s sometimes worth it (the entire unittest family is a particularly good example: test cases allow customization by overriding a very limited set of methods, and those are mostly consistent across a large number of languages), more often it is not (most modules are not unittest), and the key point is to recognize that the reversal of flow comes with high cognitive cost you need to consider when using it.

Example: wrapping a well-known function

Let’s say you find yourself writing the same piece of code around some standard library function often and want to refactor that out. For example, my app does a lot of work on a set of data files in a particular location and encoding, some reads and some writes, something that might start as multiple calls to open like this one:

    with open(os.path.join(DATA_DIR, filename), 'w', encoding='utf-8') as f:
        do_something(f)

The first thing to go would probably be that repeated call to os.path.join:

    with open(path_to(filename), 'w', encoding='utf-8') as f:
        do_something(f)

And if it wasn’t for that encoding parameter I would leave it as is, without wrapping that open(path_to(filename), <mode>) in another function, because it’s idiomatic and most Python programmers will immediately understand what’s going on. That’s much more value than removing this particular piece of duplication.

Having to specify encoding changes things because unlike with file name and mode, omitting it by mistake leads to a bug that might go unnoticed for a while. So let’s create a wrapper here.

The combination of function name and interface is going to be important. The name in particular might take a while, but it’s worth it to get it right because this is how you lead the reader to understanding what is going on.

I want something based on open to use associations with the built-in. open_data_file might work, but the word data is very ambiguous and in most situations you’re better off with something more specific. Are our files part of configuration? Cache? Static files for a website? Let’s assume configuration files.

Next thing to do is get the interface right. Write how you would like to use the function before implementing it.

    with open_config_file(filename, 'w') as f:
        do_something(f)

Does it read right? If I see it in code I open for the first time in my life, will it make it easier for me to understand it? Hopefully. I pushed encoding and path_to into open_config_file, tried to choose a name that might convey some idea about what’s going on, but otherwise I kept the interface as close to open as possible to make it easier to understand by anyone who already knows that one.

So now I can implement it.

def open_config_file(filename, mode='r', encoding='utf-8', *args, **kwargs):
    return open(path_to(filename), mode=mode, encoding=encoding, *args, **kwargs)

It ended up being a one-liner that builds the right file name and overrides the default value of one of open arguments.

Example: unit tests

This is fairly common in projects I’ve seen:

class ViewTest(ModuleSpecificTestCase):
    def setUp(self):
        self.instance = MyModel.objects.create(<intialization data>)

    # some more tests here
    [...]

    def test_the_view(self):
        self.instance.do_something()
        self.assertEqual(self.instance.attribute, 'expected value')

There’s a piece of initialisation that is [probably] used by multiple test cases. Some of them might depend on it by using self.instance, others might depend on it indirectly by assuming it’s in the DB and taking it into account when counting objects or checking results of non-ORM queries. Those test cases are now coupled and it makes changes more difficult.

Sometimes that assignment will migrate to a middle class in the hierarchy, in which case it’s even less convenient to get all the code necessary to understand a test case on the screen at the same time. And then since the assignment is in one of superclasses, you might want to introduce a way to customize it, and sometimes this happens:

class ModuleSpecificTestCase(unittest.TestCase):
    instance_options = {}
    def setUp(self):
        self.instance = MyModel.objects.create(<intialization data>,
                                               **instance_options)

class ViewTest(ModuleSpecificTestCase):
    instance_options = {'attribute': 'override'}
    [...]

    def test_the_view(self):
        self.instance.do_something()
        self.assertEqual(self.instance.attribute, 'expected value')

Or, alternatively:

class ModuleSpecificTestCase(unittest.TestCase):
    def setUp(self):
        self.instance = self.create_instance()

    def create_instance(self):
        # override to create custom models
        return MyModel.objects.create(<intialization data>)

class ViewTest(ModuleSpecificTestCase):
    def create_instance(self):
        return MyModel.objects.create(<ViewTest-specific initialization data>)

    def test_the_view(self):
        self.instance.do_something()
        self.assertEqual(self.instance.attribute, 'expected value')

At this point those attempts to reduce code duplication end up creating more complexity than they prevent. What I try to do instead is avoid passing data between setUp and test_*.

class ViewTest(ModuleSpecificTestCase):
    def create_instance(self):
        return Model.objects.create(<intialization data>)

    def test_the_view(self):
        instance = self.create_instance()
        instance.do_something()
        self.assertEqual(instance.attribute, 'expected value')

At first glance this might look like going the wrong way: my test is now longer, and having to do additional work per test is definitely some cost. On the other hand, I gain:

Readability: I have the whole data flow in one place, and with the right naming for helper methods like create_instance (this one is generic, but for non-generic initialization data I would choose a name that gives a hint what is special about the instance) I have more information in the test.
Decoupling: in the first version, setUp controlled the data that went into instance. In the second, individual tests do that; if some of them need slightly different data I can easily add that by having create_instance allow overriding defaults, eg create_instance(some_field='override').
Clarity: now I know for certain which tests really use this instance. It’s opt-in.
Flexibility: now I can have a test that creates multiple instances.

To me it’s a win.

Least maintainer astonishment

UX world has the Principle of Least Astonishment. It’s about understanding that users build some expectations based on what the system is supposed to do, and how it looks and behaves, and trying to match those.

I like that rule a lot, and try to apply it to programming: people reading my code will use patterns and conventions matching what I wrote to reason about it. I can try to work with that to make things easier to understand.

In one of previous lives I had to [briefly] deal with code created by merger of three teams who used English, German, and French respectively for their code and comments. I don’t remember trying to make sense of that mess fondly. Stick to English, please. ↩

Remote work

Thu, 19 Jan 2017 00:00:00 +0100

File under “blog posts I had on my TODO list for a long time, but now that I found it written by someone else I can just link to it” category.

“Why I only work remotely” - Yah Lhert

This is precisely why I have been strictly filtering out all job offers that require majority of work to happen on site, at a physical office.

V-REP kinect + ROS + rgbdslam

Sat, 10 Sep 2016 00:00:00 +0200

In which I share negligible amounts of code resulting from surprisingly time consuming research to get it right, along with some gotchas encountered on the way. In the hope it will save someone else the time: here’s an example of how you hook up a kinect simulated by V-REP to rgbdslam.

Spoiler: you’ll need to modify the ros_plugin bundled with v-rep and use a short Lua script to set up publishers.

The issue

Publish the minimal set of ROS topics required to run rgbdslam off of Kinect simulated in V-REP.

As a minimum, rgbdslam requires:

sensor_msgs/Image topic with RGB image
sensor_msgs/CameraInfo topic with camera geometry data
sensor_msgs/Image topic with depth image

In practice you’ll probably want to also send at least

The plugins

V-REP comes with two different ROS plugins: RosPlugin and RosInterface.

RosInterface is built to resemble the ROS API to a large degree: your Lua scripts work with subscribers and publishers directly, sending and receiving messages very much like you would in your C++ or Python ROS code.

RosPlugin, on the other hand, is not as generic, but – in the part that is relevant here – lets you set up fire-and-forget publishers that will stream data without any further work on Lua side. Which is awesome because it means no need to marshal the data to and from Lua, everything happens on C++ side.

V-REP documentation says to “make sure not to mix up” the two, which sounds like a warning about plugin clash but turns out to mean just that they are two separate things. It is perfectly okay to use them both at the same time, and it makes a lot of sense: use RosPlugin to stream high-bandwidth image data, and RosInterface to send or receive lower-bandwidth control messages that are easier to handle in Lua.

In this case you’ll only need RosPlugin.

The plugin tweak

RosPlugin provides almost everything necessary to pull it off: out of the box it can publish the RGB and camera geometry data, but falls short when it comes to depth information: it can stream it as vrep_common/VisionSensorDepthBuff, or sensor_msgs/PointCloud2, but rgbdslam really needs it as sensor_msgs/Image.

Apply this changeset to RosPlugin to add a depth Image publisher.

Build it, put the resulting dylib/so in the same directory with the main vrep library, and remember to tell it how to find roscore. You should see line like Plugin 'Ros': load succeeded. in output:

[@trurl ~] ROS_MASTER_URI=http://roshost:11311/ /Applications/vrep/vrep.app/Contents/MacOS/vrep
Using the default Lua library.
Loaded the video compression library.
[...]
Plugin 'Ros': loading...
Plugin 'Ros': load succeeded.
[...]
Initialization successful.

The simulation

Being lazy, I just bolted Kinect on top of a DR12 robot from one of examples bundled with V-REP. Where by “bolted on top” I mean “have it hover 1m above the robot to get a better view.”

Throw in some objects around the robot so that SLAM has some details to pick up and that’s it.

And then, to configure publishers:

function setup_kinect_sensor_topics(prefix, colorCam, depthCam)
   simExtROS_enablePublisher(prefix .. "rgb/image_rect_color", 1,
                             simros_strmcmd_get_vision_sensor_image,
                             colorCam, -1, "")
   simExtROS_enablePublisher(prefix .. "rgb/camera_info", 1,
                             simros_strmcmd_get_vision_sensor_info,
                             colorCam, -1, "")

   simExtROS_enablePublisher(prefix .. "depth/image_rect", 1,
                             simros_strmcmd_get_vision_sensor_depth_image,
                             depthCam, -1, "")
end


if (sim_call_type==sim_childscriptcall_initialization) then
   setup_kinect_sensor_topics("/sim/kinect1/",
                              simGetObjectHandle("kinect_rgb"),
                              simGetObjectHandle("kinect_depth"))
end

Where kinect_rgb and kinect_depth are the names of simulated sensors.

Rgbdslam configuration

Use the rgbdslam.launch bundled with rgbdslam, changing the parameters that specify input topics:

<param name="config/camera_info_topic" value="/sim/kinect1/rgb/camera_info"/>
<param name="config/topic_image_mono"  value="/sim/kinect1/rgb/image_rect_color"/>
<param name="config/topic_image_depth" value="/sim/kinect1/depth/image_rect"/>

The result

The room in V-REP:

The same scene, as seen by rgbdslam after some rotation:

I have no idea why the point cloud reconstructed by rgbdslam swaps red and blue channels, since – as visible in the bottom row – input images have them the right way, but it’s not important as all I need from SLAM as output is odometry.

Reset

Fri, 09 Sep 2016 00:00:00 +0200

Being fed up with WordPress I’m switching my home page over to static files generated by Jekyll. Which means that old blog posts go into the “let’s see when I feel nostalgic enough to put in the work to convert them” limbo for the time being.