Multiple toolboxes with lots of redundant features?
1 view (last 30 days)
Note that this is not a question that needs to be answered, I would like to start a discussion on this. In recent years, mathworks has launched numerous new toolboxes, for example, on the large field of autonomous driving, the traditional computer vision toolbox, followed by the autonomous driving toolbox, navigation toolbox, sensor fusion and tracking toolbox, robotics toolbox, radar toolbox, and so on. Although nominally they have different applications and environments, there are too many common functions or functions that overlap, such as
1, quaternion / rotation matrix / Euler angle almost every toolbox above, even some names change a little, but still does not change the concept of quaternion.
2, Kalman filter series algorithm, particle filter algorithm, all kinds of linear nonlinear variants.
3, pose graph optimization algorithm, such as cv toolbox optimizePoses, navigation toolbox optimizePoseGraph essentially the same, the name is a little different.
4, probabilistic map / binary map construction, such as occupancyMap and other series of functions in the autopilot and navigation toolbox, etc. will appear.
5, path planning algorithms, A*, RRT will also appear in multiple toolboxes at the same time.
And so on too much, in this large functional board area can always find a function can be replaced or approximated by another toolbox of a function.
What I want to express is whether it is possible to try not to expand the number of toolboxes drastically, but to get as many function blocks under one toolbox as possible, so that their common base will remain unchanged. Just like Matlab is the base module of all toolboxes, the common functions should be ported to the "Scientific Engineering" base module (or other names). As an aside, I hope that mathworks is not trying to increase the number of "redundant functions" in the toolbox to earn more money, but rather to continue to provide quality common base modules to drive applications in various fields.
Matt J on 10 Jun 2022
Edited: Matt J on 10 Jun 2022
The issue you've raised would only be a problematic one if it somehow forced people to buy more toolboxes than they should need. Having redundant functions normally helps to prevent that. For example, there is considerable overlap between functionality in the Curve Fitting toolbox and the Optimization Toolbox (e.g., fit() and lsqcurvefit()). If you were to remove fit from the Curve Fitting Toolbox in the interest of cutting down redundancy, then it would force people who only want to focus on curve fitting to buy both toolboxes.