You specifically mentioned two things, so I'm going to focus on those in this answer. However, you can probably generalize for a wide variety of work.
For tasks such as researching or learning something, many people use a spike (see 1, 2, 3). It's not part of Scrum, but it's a good fit. You should be able to estimate this type of work somehow, although it may be hard without prior experiences. In the end, it's no different than any other story, except that the completion of a spike yields an increase in knowledge and maybe some kind of deliverable that isn't a shippable software product. You place it on the backlog appropriately and do it before you need to deliver the functionality using whatever information you learned during the spike.
If you're estimating in story points, estimating a spike should be fairly easy. It's typically easier to learn a new library than a new framework, a new framework than a new programming language, a new language than a new paradigm. If you have domain experience already, it is likely going to be easier than if you don't have domain experience. If you have to learn multiple new things, it's going to be harder. You should be able to scale up the points for a spike appropriately. It's easier if you're using a Fibonacci sequence or t-shirt sizing for estimation, as opposed to hours.
There are also some other tasks that you mention, like discussing roadmaps and other meetings. These items should live outside of Scrum. They will influence your project planning and development activities, though, and do need to be considered.
First, anything outside the project will reduce the capacity of your team, so you will have a lower velocity that you must consider when planning. If you know that the team will have more outside activities (meetings, vacations) in one sprint than a previous sprint, you can plan for a reduced velocity up-front by planning a smaller deliverable.
Second, if your company roadmap includes things like new technology development, technology acquisition, or any kind of transformation, you may want to plan spikes as appropriate to see how various projects can support this roadmap. You may also need to account for people supporting activities on the company roadmap, both technical and non-technical, which will take them away from projects and reduce project velocity. Of course, depending on your funding structure, you may need customer buy-in and support to add stories and tasks related to internal changes to project plans, which you may or may not get.