ROS 2 Hardware Acceleration Working Group, 10 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ROS 2 Hardware Acceleration Working Group - meeting #21

Description

21st meeting of the ROS 2 Hardware Acceleration Working Group (HAWG, https://github.com/ros-acceleration).

The ROS 2 Hardware Acceleration Working Group is an open and community-driven robotics group that drives the creation, maintenance and testing of hardware acceleration kernels for optimized ROS 2 interactions over different compute substrates, including FPGAs and GPUs.

For more including source code, check https://github.com/ros-acceleration. Minutes of the meeting available at https://docs.google.com/document/d/185Cy1xjpAOgJygEOnlf5OCgOQTywmF0qgSpS3GiW16Q/edit?usp=sharing

For commercial support on hardware acceleration topics in robotics, refer to https://accelerationrobotics.com.

A

All right welcome everyone to the 21st uh Ross 2 Hardware, acceleration working group uh meeting um I will start sharing. My screen with the minutes um participated it in the chat and now I'm sharing my screen and if you can hear some piano in the background, that's not my music.

A

That's my neighbor playing the piano very nice I must say um all right, so uh we've got a few agenda items today, um however, we had some uh people reporting uh that they had some conflicts last minute, so uh we'll we'll cut it short I think today and just have a shorter discussion than the usual um I wanted to report on a couple of admin aspects on our site.

A

First off um concerning the robot perf project um based on the recent attendance and the recent review we've been having internally I believe we are going uh to take a step back in terms of the periodicity of those meetings and going back to monthly, uh also to try to save everyone's time and be more effective in terms of reporting progress. So the next meeting will be the 23rd of May. uh After this one and Pablo I believe you are handling the organization of everything.

A

So if you can take note of this and confirm that this is fine for you, I'd appreciate that. Are you, okay, with this yeah I'm? Okay, great got it. Thank you yeah! So uh 23rd is going to be the next one. So that's going to be the 22nd uh meeting and then, after that, one we'll get into uh the end of June for the next one.

A

So uh last Tuesday of uh the last week of June actually uh same time, Nothing's Gonna, Change uh and I'll take the action on my side to um get in touch uh with open, Robotics and record about the new periodicity, all right uh so yeah, that's uh one video I wanted to uh report on. If anyone has uh any uh concerns or any needs to meet on demand, you can always feel free to reach out to me and we'll find a way to uh to tackle your needs. No issues at all.

A

Second bit that I wanted to report and I'm really happy about this- is that internal tests that we've been doing in terms of these robot perf uh first release uh are actually pretty uh pretty nice. um Both the results, as well as the material that's coming out of our work, uh is very promising.

A

um Still, uh the current schedule and plan of record is to Target um the next meeting, so by next meeting. I think we will be in a good place to release the first uh release of robot perf uh with a bunch of um official benchmarks, as well as resource for various Hardware Solutions, so yeah just reporting about that all of the CI CD resource will also be disclosed within this first release, so that everyone can have a look and maybe reproduce or comment on them.

A

So having uh having touched on these two uh kind of like admin aspects, I wanted to have a quick discussion on the new benchmarks. I know the Harvard folks have been working on some of them, but Jason couldn't make it today.

A

So we'll postpone that for next time, I did wanted to go real, quick over two updates uh that essentially my team and Martini in here has been working on the first one is, and you can go yourself to the link, there's a new, uh very simple uh Benchmark concerning resize operations that is essentially designed, yeah inspired by uh A1 and hu, which do uh both Rectify and resize and H2 does rectify so um A5 resize is not uh much different from what exists in in those first two that I mentioned.

A

However, it does allow you to measure that independently and certainly adds value from a benchmarking perspective, we'll be adding that into the results and.

B

A

Martini also contributed uh an analyze logic, with its corresponding log file for A2, which is very appreciated. So uh folks are welcome to go, have a look at the code and if any concerns should be raised, feel free to open a ticket and report as usual. Another thing uh that pin worked recently by our team at acceleration robotics is the fact that um we have noticed that how essentially uh and purposely we have been reducing uh source code from Benchmark to Benchmark, and this certainly is not the best software engineering practice.

A

So we decided to spend some Cycles in refactoring uh the source code that the analyze scripts are are using um and uh I believe Martino has been working on it for a while. uh So we were hoping to have a now an open session and an open discussion about that and essentially um discuss it jointly and try to uh see whether um this has promise or or what feedback we can provide at this stage.

A

So martinho um would you like to maybe take the screen and uh maybe give us a ride over your work so far, and we will try our best to give you feedback.

B

Sure let me check my screen.

B

Okay, please let me know when using my screen sure.

A

Yeah, we can see your screen right now: okay,.

B

Perfect uh so, as Victor was saying, we were previously uh basically using the same code for for every analysis launch file for for every Benchmark. So what we try to do with these refactor is to create uh well, as you can see here, we have.

B

um We have this code for the analysis file for for A1 and if we uh switch to to another Benchmark, we basically see the same code, but with some some tweaks here and there to uh to adapt to the specific benchmark. So what we try to do with this refactoring is to create um to create another um Ros package, which is called Benchmark utilities, and here we actually create the Benchmark analyzer class.

B

So we can then use it on on every analysis uh file for for every benchmark, um so this is basically uh more or less the code that we had in the previews in all of the previous uh Benchmark analysis launch files. So with these refactoring, the uh the analysis would be uh much cleaner. So here we can see, for instance, the A1 package. We only have these lines of code, so here we import the so-called Benchmark analyzer. uh We tell it.

B

What's the name of the Benchmark we are trying to analyze, and then we here we have a series of configuration regarding the the traces that we previously generated with our uh with lttng and then finally, once we configure, uh for instance, here we can see uh that we are checking for for this target chain. uh For instance, we we want to see, then they have yeah and so on, and then it says.

B

So uh this is the world now and now what I discuss is the following, which is to basically uh improve this part here so I believe now it's uh cleaner than before, but it's not uh I think ideal. It's still pretty pretty cumbersome for me.

B

So what I was proposing on the on the pull request um was to somehow um improve on refactoring this code and make this section here more more cleaner. So what I propose is uh what previously we had something like this.

B

A

Is just basically any chance you can get a bit closer to the uh to that section of the code so.

B

At least for me,.

A

B

A

To the source code like, if you can augment yeah.

B

A

Make difference bigger or something like that yeah? That would be nice.

B

Yeah, so this is basically a dictionary where uh we specify uh different configuration for for each uh trays entry. So, for instance, we have the name. We have the color that we want to display uh using uh the Poke Library we have the layer and so on. So my idea here would be to uh well. This is right now very uh we are forcing the user to specify a lot of a lot of things and I think this can get repetitive over benchmarks. For instance, here we are using.

B

uh We are using the directify node uh on the resize node, but then we have some other tests, some other benchmarks, that we also use these these nodes on on Raw. So I think this can um we can avoid. You know this repetition here.

B

So as I was saying, my proposal uh on on this PR would be to perhaps create some kind of class which in this case, could be called Rectify image trace, and here we would specify.

B

Benchmark so, for instance, the the Rectify Trace would be this Trace here the call Guitar then the rectified column. He needs the Rectify any the refini uh and then the directive I call that Fini and the covalent. So that would be the same for independently of but Benchmark we are. We are trying to measure, and then this also, this would also help us to uh to create uh in the uh in the sorry, I forgot the name Benchmark analyzer class.

B

It would also allow us to to create more easily uh plots for for uh our images, because right now we are also uh hard-coding pretty much uh the results and it's kind of difficult to.

B

Let me find the function properly. We could do that yeah. So, for instance, here we we have a series of uh hard-coded. Let's call them functions where we, where we measure the time between different traces. So, for instance, here we are measuring uh the callbacks of the of the Rectify uh traces.

B

So this part here right now is a bit um difficult to I would say to to generalize. So that's what my my proposal would try to address.

A

Yeah right, yeah, I, think I think. Nevertheless, this is um this is rather specific for plotting purposes. Isn't it.

B

I I would say it's both for plotting and then also for configuring, the uh the trades that we are trying to to measure.

A

Yeah but but this is specific uh code uh is actually uh just uh picking and building up data structures that are then used for plotting, I believe.

B

A

So so other than that other than plotting itself I think it's not that useful for the rest of the uh aspects, so yeah I'm not so sure how much we want to have struggled away.

A

We have a closer look at it.

B

A

I just used to try to grasp your intention. What is the actual proposal you're making? uh How? How are you proposing to make this instead of How It's, currently done.

B

uh So I I was, as I was saying here: uh I would create some, uh for instance, for for the Rectify node I would create some some class and I would encapsulate there. The information that would be um configured for for the tracing and for the plotting so.

A

But then we need to create a class for every for every single new node that we want to Benchmark. You would need to create this class right.

B

Yeah, but the Assumption here is that we there are a lot of nodes that we are going to to reduce in in the benchmarks.

B

But maybe this assumption is wrong. I'm, not sure about that.

A

Yeah I'm not sure about that either I think we will be benchmarking plenty of no notes uh over time and I think that uh I do appreciate the effort of trying to create classes and simplify things, but um I'm not really sure. uh If this is a direction, we want to go uh so I appreciate that you brought this for discussion. uh Nevertheless, I think it's it's a great piece of of uh refactoring.

A

What you've done in terms of simplifying how um data can be added uh for the Tracer so that it can be located uh and I I like that significantly so so, yeah great contribution, great effort and thank you Martin, you I'll have a closer look at this um and I think we can. We can get this in uh as soon as possible. I think for now um just leave it as says.

A

uh Let me let me have some time and let me take a look so that uh we don't uh we don't progress uh and I don't make you waste time, uh but for now the contribution is is very acceptable and we can move into into other tasks and into other matters.

B

A

Yeah I think this is definitely a direction we want to uh move forward and consider, especially as we have more and more benchmarks, so yeah very.

B

A

Important awesome, thank you cool, so all right, um I think that clears the second agenda item that I had prepared and with that that's pretty much it any uh an additional topic. Anyone would like to bring in today.

A

Otherwise, I think we can adjourn for today and again reminding everyone next meeting will be the 23rd I, think Pablo will um coordinate and make the announcement uh as appropriate, um and by this time you should expect essentially uh us to be releasing the first uh output of the robot birth effort and and from this one we should be more active, uh just making releases um yeah. uh Thank you, everyone for participating, thank you for showing up and I'll, see you at the end of the month. I guess! Thank you. Everyone.