Does anyone know why Mathworks has not made a real attempt at supporting simulink for FIRST? Simulink seems to be more used in the industry just seems strange for them not to be more interested in FIRST
You can request licenses for Mathworks software for your team here: http://www.mathworks.com/academia/student-competitions/first-robotics/
There was a Mathworks project to use Simulink’s code generator to generate C++ WPILib code, but it never made it out of beta. See http://www.chiefdelphi.com/forums/showthread.php?t=86223
The Mathworks has supported FIRST in the past. A few years ago, we were able to get a few licenses of MATLAB, Simulink, and a some toolboxes. We may have gone through an unconventional path since we deal with NI and The Mathworks on a regular basis at work. Unfortunately, we weren’t able to devote enough time with all of our other duties to really utilize the software.
I would love to see it become a standard offering with FRC-specific training and sample models for calculating trajectories, force-damping problems, motor/gearbox torque calculators, etc. With a good modeler, the possibilities of apps for designing robots are really limitless. For instance, there could be a MATLAB app that allowed for adjustments in width/length/wheel selection and showed the calculations for scrub force and torque requirement of the gearboxes.
LabVIEW is more prominent in industry with regard to graphically programmed control systems, which is what many of the FRC robots use. Some of the actual modeling of the control systems is primarily can be done with Simulink and then converted into LabVIEW using the NI Control Design and Simulation Module. There are certain idiosyncrasies in translating the code that may make this a more challenging approach than using the NI offering in the first place.
There are other software packages out there for modeling as well. Some additional examples that my [work] team and I have looked at include Wolfram SystemModeler, Maple, and LMS (Siemens) AMESim. All have their strengths and most can interface with NI hardware with various levels of efficacy.
At the end of the day, the software in FRC for control has to be able to interface with NI hardware. This theoretically can be done using xPC Target for Simulink and the NI drivers. How well this works has yet to be tested for FRC as far as I am aware.
Does their code generator still use double-precision floats for booleans?
No. Simulink started to support data types many releases ago. Even before Simulink supported data types, you could get third party tools (such as TargetLink from dSPACE) that would support fixed point code generation.
In case anyone is interested in how prevalent Mathworks products are, many current control systems in production use auto-generated code from Simulink and Stateflow. Many engine and transmission controllers on cars that you drive use code generated from Simulink. The company that I currently work for does the vast majority of our control software in Simulink/Stateflow and the code is auto-generated. Likewise for the last company that I worked for.
What would I do without you Joe. I can’t even remember posting that.
Funny, I don’t remember that post either. Funnier yet, my earlier post is quite similar to the post I just made.
You know you’ve overdosed on FIRST when…
You answer the same question, from the same person, with the same answer, and don’t ever remember doing it.
MathWorks does get involved with FIRST and sponsors events and many teams in the area, mine included. I know they have tried to get more involved with getting MATLAB and Simulink to work with WPILib but for one reason or another it hasn’t happened.