We all remember the two Nice Guys in the garage and the effort it took them to gain attention and credibility for their idea. Today, films are made about them, books are written and their contribution to our future is honored.
The advent of personal computers had a magical effect on the world, a breakthrough, both in science and in all spheres of life.
It really was a revolution, thanks to the concept of ingenious creators, where the key condition was the democratization of technology, personalization and, importantly, a low price barrier for a wide user community.
The situation in robotics, unfortunately, is still waiting for a meeting with such a future, specialists of new thinking and other approaches to the problem.
A prime example is China, with its rapidly growing pace of robotization in economic priority areas, which is in desperate need of five million specially trained engineers and technicians, especially multidisciplinary and high-end ones, according to an analysis by The Paper newspaper, reports September 26, 2022 edition of Yicai Global.
Every year, only a few graduates meet the requirements of the robotics sector in the country, the report said, citing an industry insider. Education has not kept up with the pace of growth and technology updates. In addition, staff training is expensive, so it is very common to poach them into other areas of IT, the source added.
The all robotics industry has a high threshold for new employees, as people must have certain experience and knowledge, the robotics engineer said. This significantly hinders the growth of the number of specialists in the industry.
Many ministries in China pay close attention to the lack of human resources in the field of robotics. Over the past three years, 47 new specialties have been introduced, 15 of which are directly related to artificial intelligence, which also requires human control, as well as the creation of new accelerated development software tools that allow democratizing and expanding the community of specialists for their quick start in all areas.
One of the main challenges to accelerating development and scaling in all areas is the apparent lack of new software for rapid development.
All over the world there is a wide discussion of the topic in narrow circles, large funds are allocated for research, while the situation is changing slowly.
The educational centers of children's circles of robotics are developing most successfully. Parents pay money - children play, participate in competitions, develop a craving for technology. This beautifully and well develops children, but, unfortunately, it has a different vector in their development, without an effective contribution to the formation of a new generation of specialists.
Illusory development is like delicious chewing gum.
The younger generation is storming robotics from below, which is presented to them in the form of Lego puzzles, often with the limitations of educational software and hardware interface abstraction of the platform - an advanced constructor in the volume of a box with futuristic Lego mechanics.
It is easy to create a simple state machine there, with a certain number of sensors in interaction with load drivers.
But if we set more global, demanded tasks without restrictions in ideas, their development environment with a limited set of instructions and hardware capabilities is indecently small for the implementation of complex algorithms.
In addition to all this, even at the level of professional R&D groups, we do not observe a revolution of high-quality viable ideas, and this is the other side of the moon, where you cannot look without new thinking and breakthrough development technologies.
Evolution is inevitable and awaits the emergence of new tools for automating development processes. After a year of remote work, burnt-out and disgruntled employees want to change jobs, and researchers are warning of churn that could cost companies up to $24 billion.
In recent years, in fact, the golden age of IT has ended.Back in the early 2000s, there was a wild shortage of personnel, and now there are hundreds of responses to any vacancy, HR weeds out crowds of students and IT specialists after courses in Java, Python, etc.
Nobody needs juniors, and most of the vacancies are for seniors. Companies do not want to grow a specialist at home, but are looking for a ready-made one, which no one could have predicted 15 years ago and hired large armies of students, under generous third-party investments.
The paradox of the situation is that today, against the backdrop of ongoing mass layoffs of Hi-Tech personnel, the demand for highly qualified multidisciplinary and talented specialists is only increasing.
At the same time, old-school engineering teams are starting to emerge among startups, trying their hand at developing new frameworks and development automatics tools for the new developer community.
Evidence of the above is the development of machine learning technologies, AI, GPT-chat, which are intensively researched and tested.
I wouldn't be surprised if some of you who have read this far ask which version of GPT I used to write this article and where I got my ideas from.
The chicken and egg problem.
The fact is that for the most part, classical programmers, due to their habits and many years of experience in the programming environment through script coding, have a deterrent effect on recruits in choosing alternative tools, with a new quick start environment, where instead of the structure of text script codes, visual or verbal way to enter instructions.
In their counter-arguments, they publicly reject everything they do not want to understand, and call for the development of programming with immersion in the old classical language schools.
Such stereotypes do not allow most skeptics to take the other side, despite its persuasive power and all the advantages, and most importantly, the ability to effectively free up many resources, given the time that can be more productively used in other tasks.
The fact is that for the most part, classical programmers, due to their habits and many years of experience in the programming environment through text expressions, have a deterrent effect on recruits in choosing alternative tools, with a new quick start environment, where instead of textual code structures, visual input of instructions. Mill Beeptec Engineering is slow.
Ambitious implementation of the startup Beeptec Engineering (Israel 2019) - Framework BEEPTOOLKIT (СISC x86, OC Windows LTSC) forms a new generation developer community. Beeptoolkit is conceptually an automated robotics development framework, like a good dozen other frameworks that sometimes appear and are discussed behind closed corridors.
The history of the creation of Beeptoolkit (Framework - a software environment for accelerated prototyping and development of robotics, automation and intelligent systems) is the result of many years (over 25 years) of experience of the author - developer, Alexander Kapitulsky in many high-tech robotics and automation enterprises, from animal husbandry to medicine and the defense industry, summarize the results of many years of scientific work in the laboratory of the startup Beeptec Engineering (Israel 2019).
To date, the framework has been brought to the boxed level, which can be put on the shelves of many specialized distributors.
At the same time, it has been tested in commercial projects, but, alas, has not yet gained popularity among a wide range of potential customers.
At the same time, thanks to several successful projects and was noticed by a number of well-known public publications such as Welp Magazine (London), included in the national scientific registers of Israeli technology start-ups and is considering proposals for participation in the priority areas of robotics in the field of trade (vending robotics).
Tool in a box waiting for its time.
Framework BEEPTOOLKIT (СISC x86, OC Windows LTSC). Short description:
Demanded by R&D groups and private entrepreneurs interested in self-development of software and hardware solutions for personal or commercial use.
First of all, it is intended where it is required:
• A large number of different in length, format and number of instructions executed in a few cycles of the processor;
• Control by means of programmable logic (visual autonomous coding of instructions);
• Predominance of two-address addressing and a developed mechanism for addressing operands (a variable on which operations are performed in the code);
• Multithreading, use of finite state machines (FSM), microservices, etc.
It allows you to translate into a boxed product a rather impressive set of robotic ideas, where hardware is inexpensive modules, from the world's online trading counters (device drivers, sensors, communicators, etc.). Let us present here an example of a design in the form of one of our projects, which is practically included from the prototype without the slightest changes in the final version of the robotic vending machine:
There is no need to create hardware from scratch, write, compile code and upload it to RISC MCU-based controllers with a distributed communication scheme and attendant bouquet of problems familiar to all classic developers of embedded programs for Arduino, STM, ESP. , Raspberry Pi and other DSP platforms or controllers based on them.
If you are still in doubt, take a look at these examples of solving the same simple problem with different platforms, but if you understand, you can continue reading without getting hung up on these facts:
Why is our mill running so slowly?
Unfortunately, the few development teams for platforms like Biptoolkit are very small, sometimes just one enthusiast.
They cannot devote much time to active marketing, so such systems are not very popular in IT.
Perhaps on an individual level they still spend a lot of time on marketing, but it's hard to gain popularity if only one person does all the public speaking, plus he's often not a professional speaker and marketer, again, lack of funds to attract professionals...
No good books have been written about it, very few podcasts or blogs have been written about it, and it is not on the agenda of most conferences.
One of the pitfalls is the author's fanatical love for his solution, which is fraught with an inadequate understanding of how difficult or easy it is for programmers or non-programmers to understand it, understanding for themselves how powerful this prospect is.
In such a situation, self-control with a hand on your own pulse is important, otherwise you will burn on a slow fire, like Giordano Bruno (February 17, 1600, Rome, accused of heresy).
Perhaps there is a chicken and egg problem here: people don't write or talk about it because it's not very popular, and it's not popular because people don't write or talk about it.
If we assume that highly experienced developers are divided into two types of people who are looking for the best method of language implementation of algorithms in their comfortable programming environment in conjunction with hardware designers who, in addition to hardware architecture and design, are looking for a simple and affordable way to test and in front of them on the table 2 boxes with familiar tools and our alternative flamework.
They may mistakenly believe that they cannot use their favorite tool there to create procedures, tests, compile, debug, and so on. and very few developers are willing to use any new tool other than the editor or IDE they have known and loved for years.
Thus, they can completely abandon the framework and throw it into the next room behind the wall to the apparatchiks, without any plans for further use of it.
The problem with the second group is that, frankly, they are in a stupor before large assemblies when they think about the difficulties of adopting the framework in the case of spaced peripherals using a server station.
Despite all their fears, All demos look great and therefore the programmers behind the wall essentially became an extra link in the group, since the engineers independently entered all the instructions in accordance with the algorithm script, they also collected tests with hardware diagnostics at all stages, up to before certification testing.
And again, psychological barriers in conjecture, fear of taking full responsibility, believing that there are no good resources for training individuals or advisory groups to work with the framework, and even in emergency conditions, something third ...
As a result, when you combine all of this with the way many organizations operate, where testing and validation is not done until coding is complete or nearly complete, Beeptoolkit looks like a Genie in a bottle that is scary to open.
Finally, I believe that the Beeptoolkit is a powerful tool and should be treated accordingly, as is the case with many general purpose industrial tools that still require little effort, some experience and knowledge to reach their full potential.
If you want to get the most out of Beeptoolkit, you need someone to dedicate a significant number of hands-on, simple demos to make sure you decide in favor of the new tool.
It's definitely not a silver bullet. My guess is that some R&D teams give up too soon before they realize the true potential of Beeptoolkit.
We feel that our framework is under-represented in the information field among its potential community, as well as those who can share such information, as well as those who accidentally stumbled upon the information but did not see the cherry on the cake.
IT evangelist, if you exist, I will be immensely glad for your coming to the Beeptookit temple!
The property of a slow-running mill is high-quality grinding.
The real strength of our Framework is that it was created in the LabVIEW engineering programming environment, with the visualization of instructions for processing and analyzing data received from real physical objects.
Essentially, LabVIEW makes no distinction between using virtual instruments (functions or libraries) through I/O sets. It is a G conceptual language that is designed, compiled in C++ and partly in Qt, specifically for engineering teams, not for classical script programmers.
When a developer needs to make a major change, he doesn't need to change any of the code structures in the body, he just needs to make sure that the key instructions of the entire script work. You can do very large and serious refactorings with very little impact on commands as well as parametric properties (provided your actual user experience isn't marred by faulty visual console instructions or underlying platform issues.
It would be unfair not to say a few words about errors that are predictable.
There will always be mistakes, since no one has canceled the human factor.
It is important to understand that any development environment is a minefield where the developer is required to have sufficient professional experience, often many years with the involvement of sappers - QA testers who work accordingly with their neutralization tools and must also have the appropriate qualifications for such works.
In the case of Beeptoolkit, the level of errors and their number fundamentally differ at the level of the framework core or its environment, on the one hand, and the human factor in the process of constructing instructions from the developer.
In the first case:
the likelihood of core infrastructure failure due to PC hardware issues or operating system failures. The probability of such failures in modern PCs is minimized, in addition, a special assembly is used for the OS, which does not run other programs in the background.
At the same time, the platform allows the application of instructions for self-monitoring of the PC hardware and its life support, for example, turning on the CPU power with switching to emergency mode, stopping scenario execution, rebooting until the PC is completely turned off with switching to a backup PC and etc.
In the second case, the errors of the so-called human factor:
1. The channel number is not specified when accessing the output module;
2. One or a series of entered instructions violates the script for the correct operation of the algorithm;
3. Wrong USB kit number;
4. The USB kit is not used for its intended purpose and not according to the established instructions and etc.
Damn it, but I did it! It took me several years of working with Beeptoolkit core before I really understood how powerful and scalable it can be both in a development team and alone.
Unfortunately, even now I'm not sure that I was able to convey this to you and a wide range of major script skeptics, in any case, I sincerely thank you for taking the time to read this text and getting to this point.
Summary.
To sum it up, I don't think that people avoid the Beeptoolkit framework because of any specific technical limitations, but rather because they simply perceive it in the paradigm of their own habits and perceptions, while recognizing that they are not able to refuse them. May be too lazyes or too late.
What would you like to add or understand from this post? We will be interested to know your opinion.
Comments