Message Boards Message Boards

1
|
15464 Views
|
2 Replies
|
2 Total Likes
View groups...
Share
Share this post:

ModelPlug and Firmdata for Hw-in-the-Loop

Hellmut Kohlsdorf
Posted 10 years ago

Finally with SystemModeler 4.01 the ModelPlug utility has been added. I have the goal to apply the methodology of "Design by Modelling" to Design, Simulate and Optimize a certain design I have in mind. With ModelPlug and the Firmata protocol finally Wolfram is reacting to a market segment need that has been addressed so far i.e. by Maple and MapleSim, as well as Matlab and Simulink. Embed real hw based external systems in the process of design and simulation. This is key to verify i.e. the quality of models against data being generated in real external systems.

As well as it is that Wolfram is finally presenting a method to address this need, different from what I was suggested to look into from technical support feedback to my questions, this first release is a typical 0.x version. Let me try to express why!

Probably motivated by their activities with RaspBerry Pi and Mathematica, Wolfram has chosen Arduino and refers specifically to Uno being the recommended version of the Arduino. Lets face it. Dominating microcontroller architecture out in the embedded marketplace are those using the ARM Cortex Mx license. Wolfram chooses an exotic board using a Freescale ARM based controller, apparently a ARM Cortex M4 to address this architecture. A user that did port that implementation of the protocol Firmata to an LPC800 controller has to write his own patches, both for the PC and for his board and clearly identified the weaknesses coming from choosing with Firmata a protocol that is based on its MIDI origin, limited not only by the number of PWMs that can be supported, but also by limiting the rate of update to 10 ms, improving to 1 ms if a faster controller is used. Also the amount of data to be transferred is very limited.

So knowing that Wolfram is at its best when it comes to supply a powerful mathematical tool, the concept of promoting Mathematica and the Wolfram Language to run natively, see Raspberry Pi. The embedded world is different! A proper implementation of linking SystemModeler with the concept/tool ModelPlug has to support powerful communication means like WIFI/Bluetooth, Ethernet to link the PC to the external hardware so that huge volumes of data can be fed into SystemModeler and Mathematica. The impact of Wolframs design resources would be better spend to implement a generic support for ARM Cortex M controllers taking advantage of the CMSIS library that all licencees of ARM Cortex M controller have to make available for their ICs. Finally also the protocol chosen, Firmata is much less than a good choice! There are protocols out there in the market that are much better suited for the task of making a protocol.

Finally Wolfram needs to invest, as all in the market do, to generate good documentation in writing and paper or PDF, tutorials with videos and to be specific about what versions they use, which functions are supported and equally important which ones not or not completely. Allow me to take Firmata protocol as an example. Wolfram nowhere I have been able to find specifies which version of firmata is supported. They only speak about "standardFirmata"! Goto to Firmata.org and you will see there are a couple of those. Adding to Wolfram tools the option to simulate and verify against real hardware, the domain of SystemModeler and now finally ModelPlug, This already being addressed by the 2 suppliers mentioned above and others and the expectations and needs of the clients in this marketplace are used to standards Wolfram is still missing by miles.

Just to point out. I have decided to go the way with Mathematica and SystemModeler/ModelPlug because of the great reputation Wolfram has acquired thanks to Mathematica. SystemModeler and its combination with Modelica opens the path to catch up against competitors and finally coming out with ModelPlug confirms that i am jumping on a waggon with great potential, but still just beginning to mature. Not least important is the fact that I hate to use stolen licenses based on cracks and Wolfram, different from their competitors, offers licenses for non commercial use and tolerable price tags!

I would like to see in this thread users who share my interest in SystemModeler linked to external hardware and software and together contribute to have Wolfram go a good path!
POSTED BY: Hellmut Kohlsdorf
2 Replies
Sort By:

Hi Hellmut,

I appreciate you comments on the ModelPlug library. Some of the things you mentioned is that the required Firmata version is not specified. ModelPlug requires a version 2.2 or higher. The Arduino 1.0.5 ships with version 2.3 which of course works fine.

I would like to emphasize that the ModelPlug library does not require any patches on the PC side in order to integrate new boards. If someone has a custom board, he/she just need to add the hardware specific part to the Firmata code and it will work with ModelPlug.

I would be interested to hear which other protocols you suggest as alternative to the Firmata. The main reasons why Firmata is used are that: it's open source, well documented and it's already ported to many boards.

If you are interested in a better performance when using ModelPlug I would recommend you to use the Teensy 3.1 board which is around the same cost as an Arduino Uno.
POSTED BY: Leonardo Laguna Ruiz

Hola Leonardo I have ordered both boards to familiarize myself with the topic. I have ordered the RaspBerry Pi B+ as a bundle and I have ordered the Teensy 3.1. I believe you are right suggesting to look into this this way. I have further spend some initial reflection about the alternative to Firmata and encountered that I luck knowledge of the protocols available. So the result of that thinking about an alternative to Firmata had the following results i want to share.

Goal 1. Find a way to achieve the support of a wide number of µcontrollers and try to benefit from others efforts that might add to the usefulness: Firmata, if I have understood it properly is a means to relate the hardware of a µcontroller, registers and peripheral to symbolic objects in the SystemModeler/Mathematica environment. If we would parse the *.h file of a CMSIC i.e. supplied by the licensee that offers an instance of an ARM Cortex Mx controller and use the API of CMSIC to access those objects of the hardware such a tool could make available the means offered by Firmata regarding the hardware of the instance of any µcontroller for which a CMSIS is offered. Combing such a tool with CMSIC would allow to access lower layers of the OSI 7 Layer model and so allowing the use of any means of network communication. My first efforts into studying the ecosystem of the Teensy seems to indicate that Freescale is not adequately supporting the availability of the ARM Cortex M4 µcontroller used in the Teensy 3.1 i.e.. Further, for being a ARM Cortex M4 the µcontroller used in the Teensy is pretty scarce in its hardware resources offering. Communicating at the forum of Teensy paul, who seems to be the one writing software for this device is pretty focused on objectives that are not necessarily beneficial for users who plan to use Teensy 3.1 with SystemModeler. His objective is to offer to its target clients, first time users like young people, a means to get in touch with µcontrollers and understandably has it focus on making it as simple as possible for those targets! Additionally he is driven in his priorities to promote the use of the Teensy into its target market segment. I would believe that Wolfram trying to enter the market segment in which suppliers with competing products like Matlab/Simulink and Maple/MapleSim would benefit more by following a strategy to support as wide as possible ARM Cortex Mx devices and generating a tool that can relate the hardware resources of any such device using the CMSIS library would be a better focus. Additionally, if you would put your focus an the CMSIS library, that offers an API common across the whole offering of ARM Cortex Mx devices, you would also benefit from the CMSIS ecosystem. One issue to highlight is the availability of FreeRTOS and FreeRTOS MPU. This would address the need to manage the timing between executing a system "hardware-in-the-Loop" and exchanging data with SystemModeler. The FreeRTOS MPU would additionally help to address the memory map by protecting and limiting the access to the specific memory map area as required, such eliminating a potential hazard! As I also wrote above this way the choice of the communication means between a PC and external hardware, as well as between external hardware components would be addressed. The other even less understood topic that you can find out if it makes sense, I will study it in my experiments with the RaspBerry Pi B+ is the Wolfram language. Listening to the videos and reading the material related to the Wolfram language I am getting the impression that Wolfram sees an opportunity to place the Wolfram language into the embedded market. If I have been guessing it right, there is functionality of the Wolfram Language that requires access to the Internet and other that would work without it? I am assuming it would be very interesting to study the applicability of the Wolfram language and will do my first steps using what is available with the RaspBerry Pi B+.

Please excuse me for being so outspoken while at the same time confessing that I am far away of being able to do any final judgement. I see forward to any response to this line of thinking! Regards Hellmut
POSTED BY: Hellmut Kohlsdorf
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Tag limit exceeded
Note: Only the first five people you tag will receive an email notification; the other tagged names will appear as links to their profiles.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract