I am implementing some head tracking and I get 2 matrices of horizontal velocities. (A vector field decomposed into vertical and horizontal velocities). For each of these matrices I do some math to calculate the actual head tracking.
My question is, is there a way to do that math (which is a set of blocks) on both matrices without copying the math blocks onto each signal?
It's hard to explain so here's a screen shot of my model:
You can see that the "complex to real-imag" block has 2 outputs (this is the little one in the middle). The mean block and the integrator circuit then calculate the head velocity and position for the real matrix (horizontal position). I want to do exactly the same routine on the imaginary matrix (vertical direction). Obviously I can just copy the blocks, but surely there must be a better way of doing it? In a way I'm looking for an analogue of a loop in "normal programming" like C or something, where a block of code is executed several times on different inputs.
You can create a Library in Simulink that contains code you can reference multiple times.
Go to File -> New -> Library. In the model window that opens, you can create any number of subsystems with whatever code you want. Then, just drag a subsystem from the library into your model. The subsystem will now appear in your model with a little arrow icon in the lower left. This indicates that the subsystem in the model is a link. You can drag as many instances of the library subsystem into your model as you wish, just as you can call a function as many times as you wish in any other programming language.
If you right-click on the subsystem in your model, you can select "Link Options -> Go To Library Block" to get back to the library. You can make changes in your model and propogate them back to the library as well.
One way to easily reuse a set of blocks is to create a subsystem out of them. In your case, you can create a subsystem by grouping existing blocks, then simply copy and paste your subsystem to use it for your imaginary output.
Although potentially more complicated, you could also look into using mux signals to avoid having to copy parts of your model.
Related
This is more of a formatting problem than code logic and probably seems silly (considering I've seen far more dense block diagrams). I'm working with a lot of numeric constants and they're starting to clutter my Block Diagram. Is there something I can use to group them nice and compactly?
Preferably I would like to avoid clustering them because I would need to bundle and unbundle every time I needed access.
EDIT: Picture of code in question (code segment is used repeatedly, so would be nice to have a more compact case structure)
I think you should rethink how much of your block diagram you expect to devote to constants :-)
Using numbers directly in code, the equivalent of unlabelled constants on the LabVIEW block diagram, is a recognised anti-pattern. Unless the reason for the constant value is both obvious and fundamental to the operation being carried out, anyone looking at your code (including you, any time after a couple of weeks since you wrote it) will not understand why the value was chosen. Therefore, you should make this clear by labelling the constant somehow (equivalent to assigning it to a name in a text language) and also make it easy to change the value if necessary.
It's usually clear what a 0 or 1 constant is doing there but in the code image you've posted you have two constants of 1000 and one of 999. Why is it 1000, and if I decide that it should be (say) 2000 instead, do I need to update the other two values as well? If so you should define it once, label it with a suitable name describing what it is (in your example it might be chunk size or something) and wire that value to wherever you need to use it. Where you have a constant 999 you could get that value with a Decrement function, or you could also change your Greater Than function to a Greater or Equal and compare directly with the 1000 value. In this way your initial constant definition will take up more space because of the label, but you'll save space and improve maintainability by wiring that value to wherever you need it rather than placing additional constants.
If you need to refer to the same constants in multiple places on your block diagram, you can place the constants (and just the constants, not any other program logic) in a subVI, with each constant wired to an indicator with a suitable label, and each indicator wired to a different output on the connector pane. When you hover the wiring tool over the SubVI's terminals you'll see the label in the tip-strip. Alternatively, especially if you need loads of different constant values, you can do the same thing but in your SubVI bundle the different constants into a named cluster (which you save as a typedef), and then use Unbundle by Name to access specific constant values from the cluster where you need them. Again this doesn't necessarily save block diagram space, but it does make your code more readable and maintainable.
Simple answer was to reorganize my block diagram making more space for the constants. Dave_St suggested creating subvi's for the case structures for anyone looking for alternatives. Wanted to mark this as resolved regardless.
I am currently working with multibody mechanical systems using the MultiBody library included in the standard Modelica distribution.
I need to implement a switch between flanges, in order to select position or force control for a given joint.
model FlangeSwitch "Switch between flanges"
Modelica.Mechanics.Translational.Interfaces.Flange_a flange_a_1;
Modelica.Mechanics.Translational.Interfaces.Flange_b flange_b_1;
Modelica.Mechanics.Translational.Interfaces.Flange_a flange_a_2;
Modelica.Mechanics.Translational.Interfaces.Flange_b flange_b_2;
Modelica.Mechanics.Translational.Interfaces.Flange_a flange_a_exit;
Modelica.Mechanics.Translational.Interfaces.Flange_b flange_b_exit;
Modelica.Blocks.Interfaces.BooleanInput u;
equation
if u then
flange_a_exit = flange_a_2;
flange_b_exit = flange_b_2;
else
flange_a_exit = flange_a_1;
flange_b_exit = flange_b_1;
end if;
end FlangeSwitch;
But this approach does not work, the system is not balanced: 10 equations and 12 variables.
Is there any way to do this?
I don't think a Modelica tool will allow this operation (even if you have a balanced model), as it would potentially result in a variable structure system. Which is something Modelica does not support at the moment. See a nice introduction here: https://www.modelica.org/events/modelica2017/proceedings/html/submissions/ecp17132291_Stuber.pdf
Without fully knowing the application you could try two approaches:
Use a model that emulates a rotational clutch, like the Modelica.Mechanics.Translational.Components.Brake with an activated parameter useSupport. This way you can generate a "controllable mechanical connection" for connecting either of the flanges to the support connector. If I read your code correctly you should connect flange_a_2 to the support and the flange_a_exit to either flange_a or flange_b. When activating the brake via the RealInput there will be a mechanical connection.
The second thing you can try is to measure either position or force (which of both you want to apply by a sensor Modelica.Mechanics.Translational.Sensors.PositionSensor and then apply it using the respective source, which in this case would be Modelica.Mechanics.Translational.Sources.Position. Switching between the sources could then be done by switching the Real signals instead of the physical connectors. Mind that is could generate jumps in positions when applying positions directly.
The link you posted is related to non-phyiscal connectors, which are less restrictive compared to the physical connectors. So comparing the two solutions should be done very carefully.
Switching from position as an input to force as an input would require the system of equations to be rebuilt when executing this switch. This will not be possible with current generation Modelica. You will need to find a solution that is based on the same input for the whole simulation.
Would it be enough to initialize position in a way that the system starts the simulation in the point where you want to move it to first (using the Position Source)? What you loose is the movement of the system to this position.
For Matlab simulink, how does one go about generating multiple step function at different conditions for a system
I am trying to simulate a simple flow through a tank and controlling the temperature within. At various interval say time at 10ses and 20secs i intend to draw out different flowrate/flow amount of water.
With the system designed, how do I show on a single scope how Flow in changes with the different amount of flow out drawn.
Appreciate any kind advises
There are many different ways of doing this, for example defining the data in MATLAB and using a From Workspace block or using multiple Step blocks summed together appropriately. But to start I'd suggest you look at the Signal Builder block.
To view multiple signals at once in the same Scope, either set the scope up to have multiple inports, or Mux the signals together and feed them in in the usual way.
I would like to optimize output signals, by tuning some of the input parameters with ease (preferably in real-time) by looping the simulation of the model again and again at a speed where the speed of simulation can be controlled.
You have various options as far as I can see.
The first one is to have the parameters of interest defined as workspace variables, and then write a MATLAB script looping over those variables, with the use of the sim command to run the Simulink model programmatically. You can control the "speed" of the simulations with things such as step size used by the solver. If you want to combine this with optimizing parameters, you can put the call to sim in a cost function, and then pass this to the optimization routine.
The second option is to use an add-on product called Simulink Design Optimization, which provides a nice interface and uses optimization routines under the hood to loop over the parameters. This requires the Optimization Toolbox.
If you want to invest nothing in the creation of your user interface, you might want to use cell evaluation. Check out this link.
Increment Values in Code Sections
You can increment numbers within a section, rerunning that section
after every change. This helps you fine-tune and experiment with your
code.
To increment or decrement a number in a section:
Highlight or place your cursor next to the number. Right-click to open
the context menu. Select Increment Value and Run Section. A small
dialog box appears.
Input appropriate values in the / text box or / text box. Click
the , , , or button to add to, subtract from, multiply, or divide
the selected number in your section. MATLAB runs the section after
every click.
background
I'm working on a group project to simulate some consensus algorithms used by a group of independent robots to form an arbitrary shape on a 2D plane. The robots are modeled as unit disks, and all run the same algorithm. Basically, each robot can move, wait, or observe its local environment at any moment, but cannot communicate explicitly with an other robots. We'd like to find a simulation or even 2d graphics library to help us without writing too much from scratch.
Question
Can anyone recommend a simulation library meeting the requirements below, which could be used for a multi-robot 2D simulation?
I've never coded a simulation before, so it's possible some of my concerns are readily addressed by many existing libraries. However, the Mason project is the only resource I've found that seems promising so far. Unfortunately, a few of our team members are not very proficient in Java, so I'd like to find something suitable in a different language, if possible.
Requirements
* language preference (descending order): python, c++, (maybe) java
* open source/FOSS recommendations only
* Options/flags to disable simulation: We plan on running several thousand trials of randomly generated shapes against each algorithm, so for the bulk of trials we don't care about any visual representation, just data. So the simulation logic has to be decoupled from the graphics components if this makes sense.
* collision detection
* Customizable visual representations: Within a simulation, we'd like to have several views (or toggles for a single view) that present additional information about each robot like current state, the area it's currently observing etc.
For such simple graphics you can surely get away with either pyqt or wxpython.
The simulation itself should be its own python module; the GUI should just load the module, then call its "timestep" function at regular intervals (timer, GUI idle callback, etc); the step function should evolve the robot system by one small time step.
The GUI should just display the simulation state. Avoid mixing everything (display and simulation) in one module, it'll get pretty messy, plus if your simulation engine is a separate module you can then also run it directly from the command line and look at the output file.
It would be pretty easy to write a python script that reads such output file and generates commands to represent it graphically in either excel or powerpoint using win32com, in which case you don't even need pyqt or wxpython.
For the collision detection, look at pybox2d.