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.

Answers (1)

Matt J
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.
Walter Roberson
Walter Roberson on 14 Jun 2022
"The suggestion was that there would be "base module" which would support both/all toolboxes with any common functionalities."
That is already implemented for some pieces.
  • Audio System and DSP share
  • Some specific aspects of Fixed Point Toolbox are shared (in particular double precision and half precision)
  • code generation is shared with a number of tools, such as deploying to Raspberry Pi and Arduino (at least from Simulink)

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!