I wish companies that offer such a core technology and what not were at times entered into a public trust, similar to how some public lands are managed, that would protect them from private equity takeovers; I know it defeats the purpose of the companies in the first place (making money), and it probably would backfire in myriad worse ways than the problems it might solve... But I do think there are many options for how products, services and what not can be structured that give the people who maintain them what they need to thrive; without mining the users for money.
Overly idealistic thinking, maybe... but still thinking.
Public management exists for natural monopolies where no market competition is feasible. The role of the public entities is to protect competition. In this case that would be mandating import/export interoperability.
Rule 3 is still very much real. Fancy fast algorithms often have other trade-offs. The best algorithm for the job is the one that meets all requirements well... Big-O is one aspect, data is another, determinism of the underlying things that are needed (dynamic memory allocation, etc) can be another.
It is important to remember that the art of sw engineering (like all engineering) lives in a balance between all these different requirements; not just in OPTIMIZE BIG-O.
Sure but the default (and usually correct) assumption when working at google (as an example) is basically "all numbers are big", so you you have to cluey about algorithms and data structures and not default to brute forcing something.
At 99% of shops it should be the other way around .
Even when you are working with large numbers, most numbers are usually small. Most of the code is probably not dealing with the large things, and a large thing may consist of a large number of instances that are individually small.
I've personally found it useful to always have concrete numbers in mind. An algorithm or data structure designed for N will probably be fine for N/10 and 10N, but it will often be inefficient for N/1000 or 1000N.
I will admit I have almost always made the choice to not use ros2. I am trying to use it now for some work, and I can see where/when it would be useful...
But I almost always feel like there is just so much STUFF involved in ros, that really is just better resolved by having really robust controllers, well defined protocols, and everything else.
I wait to pass judgement until I have more information though
I've been a ROS 1 (and now 2) user since 2010. I like the game engine analogy given elsewhere in the thread, in that ROS gives you some important things "for free" if you cooperate with its ecosystem conventions. Data bagging, visualization, teleop, and sim are the some obvious ones that I think a lot of teams don't think about if they're just focused on getting cartographer or whatever going, and not considering the larger development and debugging questions.
For some, packaging/deployment would also fall under the umbrella of a solved-by-ROS problem, however I don't think the Open Robotics supplied debs are suitable for most product deployments, for a variety of reasons that I've discussed in two separate ROSCon talks.
I usually feel the same when starting something new. The "STUFF" is annoying and often feels like overkill when a project is new and minimal. Installing/building ROS, the package boilerplate, etc. And often I can get away with more minimal alternatives like just a single (possibly multithreaded) process, or multiple processes with a simple IPC. But then again I often end up wanting a lot of the extra stuff you get with ROS like the bags, the viewers, the cli tools, etc. LLMs help on both fronts though - they're decent at making DIY versions of ROS-like functionality, but they're also pretty good at handling the ROS boilerplate. (Which is one area where I'd see peppyOS being a severe disadvantage).
As someone who has used ros2, I feel fine passing judgment; it is terrible. If its easier to write your own stack, do it. Your own stack will be easier to add to and maintain long term. The conceptual design (nodes) is great, its just the execution that is awful.
This is my experience as well. The average quality in ROS is rock-bottom and so while it contains all of the things you might want from a robotics framework, you pay dearly for it. I would also say that whole the concept of distributed network modes is a convenient one for robotics development, stringing your control loops through such a structure is a recipe for disaster and should be avoided in your system design as much as possible (and one of the problems with ROS as a framework is that it heavily encourages this)
Our goal is to make all of this super easy with the installation of a single script. We're also working on a SaaS in parallel which will allow you to fire up the whole stack in your browser, 0 setup required (you pick the robot you want and it runs in a sim in your browser). Then, when you're satisfied with the result you just run a bash script on your Jetson board and everything will work the same on your real robot.
Love the article! Honest reflections on shifting goals, is great.
I personally have found grinding and grit mostly counter productive unless it is accompanied by a reasonably short term outcome.
Also grinding continuously to get an abstract thing that might help you somedays is a recipe for burnout. Sustainable self improvement has to come from a place of intention, and the grid can service that intention in the short term; but sometimes you need to refuel your intention.
Find something you can bring a unique level of energy too, and bring it. One person’s generalist is another’s expert, thinking in those terms just isn’t that useful. The ability to take on hard problems and get something done and unwedge a team will always be useful.
Meet people in your org and others and make friends, develop some soft skills. I think these things really are career differentiator.
Idk I think just get passionate about things, learn about them, and be curious. Maybe you’ll find something you can specialize in, maybe you’ll find a unique constellation of skills and interests. Do some side projects here and there, it’s a way to take charge of your own skill development… yeah it’s sad that work can’t always provide this; but that’s how it goes…
Oh and to your best ability don’t let what everyone else is saying get you down, there is a lot of cynicism going around here , people are feeling pain… don’t let that pain become yours.
TVS diodes can protect from transient voltage spikes when used properly (low impedance to the input connector, properly chosen and with the proper supporting circuitry)
Zener diodes can temporarily protect an overvoltage too but you will need something to take all that current that is now going through it, making it pretty hot and likely to fry something
You can pair something like this with a positive temperature coefficient thermistor to act as a fuse (as it gets hotter the resistance goes up).
These circuits are tricky to tune right, take up space and can add significant cost to a product. So with a drive in consumer products to lower cost smaller things you may not see them everywhere.
The wealth of formal verification tools in the safety critical c and c++ world is very high. Those tools, not the compilers are what get validated during tool qualification. Ultimately it is about the formal verification, static analysis and dynamic analysis tools, as well as, traceable code execution, robustness tests etc.
A formally verified rust compiler could really be a game changer, but until then, the tools do exist to write safe c and c++, but they are expensive and adherence is low outside of the places they must be used
I once made something very similar for myself in College when I was told not to use git for something in a lab… so my solution was to automate making archives. It worked ok. Definitely helped me appreciate git. Now a days i would have just used git and released archives to the rest of the org
I would contend that 10kHz is pretty fast for a control loop thats doing anything complicated in a Garbage Collected language on a non real-time OS. The later issue being some what of a bigger issue than the GC. You CAN do it... some of the Basic linux real time stuff helps the situation a lot.
In .NET you can also change the GC policy at the thread level which can help a lot.
Pool Allocation (long held chunks of memory that can be manually repurposed) can help a lot, since you can write custom Pools where the Gc never knows it needs to clean up. It is a useful tool when you have big chunks of memory that need to be manipulated at a high rates.
I would say from experience that 500Hz-1kHz is a more reasonable loop time
Overly idealistic thinking, maybe... but still thinking.