> It would also help to have compile-time guarantees about which nodes are running.
I haven't had a chance to try it yet, but in theory I like the idea of something like Zenoh Flow to describe the larger data flow graph. https://zenoh.io/blog/2023-02-10-zenoh-flow/
> But I always like to say, why spend 5ns calling a function when you could spend 1ms waiting for a context switch or 50ms for the next event loop to tick over?
I think your context switch timing is off by several orders of magnitude, but regardless these things aren't one extreme or the other. For sharing data across threads, to an external system, or logging and visualization I still like pub/sub (and I've seen more than my share of horrible abuse), but it definitely shouldn't be treated as one size fits all.
In a best case, yes I've exaggerated wildly. But in a latency sensitive system, waiting for the message to get to the front of the queue could really take that time. Different queue priorities help, but really, why not just do a function call? To me, anything that isn't just a function call should really need to be justified. But I guess it's all design decisions.
> And this is the crux of where we disagree. This is a messy part of reality which should be, as far as possible, abstracted away from the algorithms which need to operate on the data presented to them. If I'm running a Kalman filter I don't want to have to design in my filter around frequent gyroscope dropouts because image captures are happening, I want my system to have guaranteed behaviour that this won't happen.
Annoyingly in a lot of real world setups you can't have these guarantees. Your gyroscope, camera, etc are all producing data asynchronously often with slightly different clocks, and they all have different little idiosyncrasies and failure modes.
For example the Mars helicopter almost crashed because it missed a single frame. https://mars.nasa.gov/technology/helicopter/status/305/survi...
If possible you absolutely want to fix the frame drop in the first place, but your algorithm should also be able to handle the drop out (or at least reset/recover).
> A better system would take ideas from game engine design and realtime system execution budgets, with cascaded controllers on separate threads with dedicated compute resources for components that need higher update rates.
This is how I've structured a control system, but using a pub/sub system to share data across those boundaries (and log/inspect in general). "Nodes" that share some resource or fundamentally run back to back based on the data flow can live in the same thread. Higher rate components (eg inner loop controller) live in a thread with a much higher priority. All of this is event driven, deterministic, and testable.
If you have more details about the system you're imagining I'd love to learn more, because so far I don't see what's incompatible with what you've described.
In general PX4 is better than ROS in this respect, but IMO still leans too heavily on queues. A bit of feedback there:
- more should be done by setting up constrained functionality-specific data, and then simply calling a function with just that data. Right now a lot of things are passed state they don't need just because it is part of the message they receive. This makes the code dependencies way harder to separate, because you effectively share function signatures (messages) between different modules. Of secondary concern is the extra memory bandwidth from the extra data passed around, and not being able to pass by const& due to the async.
- lots of things don't need updating at all until they tick over. If you don't update it frequently it has old data. You can try to make sure it works with the latest data by updating it frequently, but that of course has big overhead. I don't see any decent way of making this work unless you either 1) set up global threadsafe state so everything can access it, which is bad from a dependency and locking perspective, or 2) just call functions synchronously with exactly the data they need.
- The issue with message queues, beyond the need for messages to generalize as mentioned above, is that often components need multiple different messages from different sources to perform their tasks. This means every component needs to keep a local copy of the data they need, to translate this async data back into a synchronous paradigm when it runs. In fact, beyond the message passing itself, pretty much everything needs to do its work in a synchronous paradigm, so why even add the async stuff in the middle to begin with? Once the messiness of different sensors' reporting rates is consolidated into the EKF state, and external commands and directives and brought in, after that point pretty much everything could be synchronous. No overhead, no timing issues, no "which message has the data I need", no "why do we have 3 different variants of the same message with slightly different data and which one should I use", etc.
As long as you log the initial input data it should still be able to do replays for reproduction of realtime behaviour, but a) better testing can be done because you can actually tell what every subsystem needs to run correctly just by looking at its function signature, and b) its much easier to refactor (and understand) because of the same properties of the function signature describing all of the inputs and outputs.
Face reidentification is the approach this paper uses to find corresponding views of the same person, but that's not necessary if you have the ability to match the objects in your scene otherwise. For example, doing 3D triangulation to geometrically verify random matches using RANSAC.
Asus have a direct competitor featuring trackpoint and three physical buttons. Only problem is I can't seem to find its pricing or availability anywhere.
In my experience with Dell and HP laptops, their versions of the trackpoint cannot match the smoothness of IBM/Lenovo's at all. Very noticeable difference that really ruins the experience for me. However, ASUS may have done better, not sure.
I honestly don't understand why this is a problem. Isn't it enough that the app says it requires my location when I install it?
If you don't like the required permissions no one is forcing you to install it.
Popular apps can essentially request any permission and you'll still download it — are you really going to forgo having Facebook on your phone because it asks for a couple of slightly-objectionable permissions?
On iOS, the average user has a chance to download that mainstream app and deny it access to their contacts.
It sounds to me like the question was supposed to read
> are [most people] really going to forgo having Facebook [...]
There will certainly always be people who do pay attention to permissions for privacy or security reasons, but they seem* vastly outnumbered by the people who don't.
* Just an intuitive sense, I have not looked for data to back this up.
The point is valid, but it still doesn't address the 'general population' problem - how do you get the users to care about their security/privacy? Giving fine-grain control over permissions is a fantastic idea.. but then you realize that the 'general population' that you made this for will never touch those settings, so it's no different than telling users what permissions an application will take.
Also, the development cost of 'does this feature exist?' for each permission is pretty high.
Google badly obfuscated permissions in a recent Play store update.
Where before it listed each permission, and required a manual approval of any was added in a app update, it now only list categories.
And it will only require manual approval if a new category is added.
And the categories are wide enough that someone can add an innocuous permission initially, and then push a update some time later that gives them virtually free reign of the user data.
Any X or T series with intel video tends to work pretty well. I've personally had great results with Ubuntu on a T410, T420, T520, T530, X1, X60 in the last few years.
I would remove the x201 from the list. It works fine with linux, but the TN screen is absolutely awful. The viewing angle is so narrow that even sited dead in front of it, I can't watch a video without some of the blacks looking wrong.
This comment was typed on my own 4-year-old x201 :)
If you're talking about the 1400x900 screen, I agree, the viewing sweet spot is nearly nonexistent. I actually swapped out the top shell of my X200s and so I could put in an AFFS panel.
(Running Mint 17.1, which broke the display popup for brightness, but curiously not for audio.)
I replaced the TN screen of my x201 with a Boe Hydis AFFS panel with IPS like viewing angles and contrast so I would _not_ remove it from the list. It's a great laptop and you can get them really cheap used (I've never bought a ThinkPad new so far).
I would remove it again, because if you don't already have an x201, you may as well buy an x220 instead of an x201 + replacement screen + labour (and the low risk you'll damage something in the swapover). You'll get slightly better specs in the deal. Looking on ebay now, x220s are only AU$100-200 more than x201s.
Anyway, if you're going to mod laptops to say that they're good, then many laptops will re-enter the fray :)
I haven't had a chance to try it yet, but in theory I like the idea of something like Zenoh Flow to describe the larger data flow graph. https://zenoh.io/blog/2023-02-10-zenoh-flow/
> But I always like to say, why spend 5ns calling a function when you could spend 1ms waiting for a context switch or 50ms for the next event loop to tick over?
I think your context switch timing is off by several orders of magnitude, but regardless these things aren't one extreme or the other. For sharing data across threads, to an external system, or logging and visualization I still like pub/sub (and I've seen more than my share of horrible abuse), but it definitely shouldn't be treated as one size fits all.