Beta-Testers for new Simulink FRC Blockset Wanted

[akalmbach]

MathWorks is developing a Simulink/MATLAB library to program FRC robots. This library is based on the WPILib C++ library, and allows teams to create and test robot control algorithms in an interactive graphical environment using block diagrams and state charts. We are currently looking for FRC teams that would be interested in beta-testing the library and giving us feedback. Eligible teams will get licenses for relevant MathWorks products at no charge.

In order to be eligible, an FRC team should:
1) Have prior experience with WPILib (either the C++ or Java interface).
2) Have access to the NI cRIO hardware and WindRiver Workbench software; more generally, you need to have all the software and tools necessary for using WPILib, along with a Windows XP system.
3) Have a mentor who has some experience with Simulink or Stateflow. This is not a strict requirement, but keep in mind that since the library is a beta version, there may be gaps in the functionality and documentation.

Beta-testing includes: Downloading and installing the necessary MathWorks products, developing Simulink models to control the robot, downloading compiled code to the NI CompactRIO, and evaluating the ease-of-use of the entire process.

If you are interested, contact Gautam Vallabha (gautam.vallabha@mathworks.com, 508-547-2008) or myself before July 30, 2010. We plan to have the beta version ready for distribution in late July.

[Robototes2412]

does this involve proprietary and evil software?

[EricVanWyk]

Originally Posted by Robototes2412

does this involve proprietary and evil software?

MATLAB and Simulink are both created by The Mathworks, and are proprietary, but I wouldn't call them evil. MATLAB is one of my five favorite languages, and my go-to for simulation / optimization problems. Anyone in school for physics or engineering will likely learn MATLAB.

I'm not as big of a fan of Simulink (I really prefer LabVIEW's data flow model), but this is pretty exciting. I'm always happy to see new options, and The Mathworks does a really amazing job with just about everything I've used from them.

[apalrd]

Originally Posted by Robototes2412

does this involve proprietary and evil software?

proprietary != evil.

Just because everything made by a company with an apple for a logo happens to be both proprietary and evil, does not mean everything that is proprietary is evil.

Sometimes proprietary software is actually good.

[Manoel]

That's VERY cool. To me, Simulink is much easier to use than LabVIEW - too bad we don't have WPILib experience or we'd jump right in!

[Robototes2412]

I consider every single byte of software that is not open source || proprietary as evil

[Andrew Schreiber]

Originally Posted by Robototes2412

I consider every single byte of software that is not open source || proprietary as evil

Then start your own thread in chit chat to discuss that. This is not the place.

Matlab is one of those pieces of software I wish I knew better. I hope your beta test goes well.

[nathanww]

Okay, so a few questions:

1.Is this going to be an option on the table for next year's competition? If so, will it replace labview, or just be another option?. If not, when are you looking at introducing it?

2.Is this purely a third-party product, or will it be part of the "official" FIRST software, like Java, C++, and labview are now?

3.Will this be able to compile code or use native libraries for processing-intesnsive operations(like java does now)? Or will we be limited to just the interpreted MATLAB/simulink code?

[akalmbach]

Originally Posted by nathanww

Okay, so a few questions:

1.Is this going to be an option on the table for next year's competition? If so, will it replace labview, or just be another option?. If not, when are you looking at introducing it?

2.Is this purely a third-party product, or will it be part of the "official" FIRST software, like Java, C++, and labview are now?

3.Will this be able to compile code or use native libraries for processing-intesnsive operations(like java does now)? Or will we be limited to just the interpreted MATLAB/simulink code?

To answer your questions,

1. Yes, we are planning on having a version of the Simulink FRC Library ready for the 2011 season. It is not a replacement for LabVIEW; rather, it is an alternative graphical environment for designing robot control algorithms and generating code for them. The graphical notation can include state diagrams as well as signal flow diagrams, and is especially well suited for simulation and testing.

2. For the 2011 season, the Simulink FRC Library will be a third party product, available to any team who requests it from us. It will not be part of the official FIRST FRC kit for 2011.

3. The Simulink FRC Library can be used in two ways. (a) you can run the Simulink model (on your host computer) to simulate and test your algorithm. (b) you can generate C++ code from it which will be compiled, linked with the WPILib and native libraries, and downloaded to the NI CompactRIO. There is no interpreter or virtual machine involved; the generated code is straight C++ code that you can read and modify if you wish (though typically this would not be necessary). You can incorporate custom C++ code as well.

[Ether]

Originally Posted by akalmbach

you can generate C++ code from it which will be compiled, linked with the WPILib and native libraries, and downloaded to the NI CompactRIO. There is no interpreter or virtual machine involved; the generated code is straight C++ code that you can read and modify if you wish

Last time I looked at Simulink C code generation (admittedly probably 20-odd years ago) it used double-precision floats for booleans. Has the code generator now been optimized for realtime embedded controllers?

~

[EricVanWyk]

Originally Posted by Ether

Last time I looked at Simulink C code generation (admittedly probably 20-odd years ago) it used double-precision floats for booleans. Has the code generator now been optimized for realtime embedded controllers?

~

Ether -

It sounds like it implemented political booleans, rather than engineering booleans: True, False, and nearly 2^64 shades of grey including whiter than white and blacker than black.

[R2D2DOC]

Greetings,

I would like to participate in the MATLAB/Simulink/Stateflow SW evaluation. Have used the SW as a university professor as well as in industry. Currently using the SW for embedded control of vehicle powertrain controls, conventional and hybrid applications for Chrysler.

Thanks

[Ether]

Originally Posted by EricVanWyk

It sounds like it implemented political booleans, rather than engineering booleans: True, False, and nearly 2^64 shades of grey including whiter than white and blacker than black.

Aha. An intrinsic datatype to support fuzzy logic. :-)


~

[Chris Hibner]

Originally Posted by Ether

Last time I looked at Simulink C code generation (admittedly probably 20-odd years ago) it used double-precision floats for booleans. Has the code generator now been optimized for realtime embedded controllers?

~

Yes, it has been optimized. Real Time Workshop supports virtually all of the data types you need, whether they are floating point, fixed point, or boolean. Many current controls companies (like the one I work for) put auto-generated code from Simulink into production controllers. My previous company first put it into production in 2004, with good results.

As a side note, for the first three years of autonomous (2003-2005) my teams used Simulink to do all of our autonomous control. We auto-generated the code using TargetLink (a third party product from dSPACE). The microcontroller we used wasn't particularly powerful so we did it all in 16-bit fixed point types (with a few 32-bit calculations where we needed the extra accuracy). We even had Stateflow going to do the big-picture sequencing. That's when I first got the basic robot simulator going to test and debug the autonomous code. It really helped finding out where we had precision problems in the fixed point calculations.

[Ether]

Originally Posted by Chris Hibner

The microcontroller we used wasn't particularly powerful so we did it all in 16-bit fixed point types (with a few 32-bit calculations where we needed the extra accuracy).

Just curious: what kind of calculations did you have to make for which 16 bits of precision was not adequate?

~