1What's new in MORSE 1.4? 2======================== 3 4General 5------- 6 7- `Numpy <http://www.numpy.org/>`_ is now needed for Morse. It is used in 8 several places where computations using mathutils is not precise enough 9 (e.g., float vs. double precision). 10- Time management has been improved in various way. A **morse_sync** tool has 11 been introduced to improve the precision and timing of high-frequency components 12 (`#683 <https://github.com/morse-simulator/morse/issues/683>`_). 13 If available in Blender (Blender > 2.77), it is also possible to accelerate 14 or slow-down the simulation (`#388 <https://github.com/morse-simulator/morse/issues/388>`_). 15 Moreover, Morse now tries to automatically compute the correct time settings. 16 If you encounter any time related problem, make sure you read 17 :doc:`dev/time_event` and / or report the issue to the Morse project. 18 19Components 20---------- 21 22Robots 23++++++ 24 25- The MORSE :doc:`user/robots/human` has been entirely rewritten. The new 26 human model is much simpler, yet much nicer (in particular, it features mesh 27 skinning for attractive animations). On the downside, the interactive mode 28 has gone for now. Depending on interest, it may be revived in a future version 29 (possibly through external scripts, for added flexibility). 30 31 32Actuators 33+++++++++ 34 35- The semantics of the :doc:`user/actuators/waypoint` and 36 :doc:`user/actuators/destination` actuators has slightly changed: once the 37 destination is reached, they no longer actively attempt to stay at this 38 position. This allows another motion actuator to 'take over' the control of 39 the robot. The previous behaviour is still desirable in certain cases (notably 40 for flying robots), and can be re-enabled by setting the property 41 ``RemainAtDestination`` to true: 42 ``motion.properties(RemainAtDestination=True)``. This option is also added to 43 the :doc:`user/actuators/rotorcraft_waypoint` actuator, but it defaults to 44 true (hence, no behaviour change compared to MORSE 1.3). 45- The :doc:`user/actuators/orientation` actuator has been enhanced to possibly 46 work more realistically, by limiting the speed of the rotations. The default 47 is still to go directly to the desired orientation. 48- The :doc:`user/actuators/keyboard` and :doc:`user/actuators/joystick` 49 actuators no longer call the robot's ``apply_speed`` method with values set 50 to zero when no input is received. The previous behaviour prevented them from being 51 used in combination with another motion actuator (since they would always overwrite 52 other motion commands with zeros). 53- The :doc:`user/actuators/armature` actuator has two new services 54 (``rotate_joints`` and ``translate_joints``) that let the user set the 55 rotations/translations of only a subset of the armature's joints by providing 56 a custom mapping ``{joint name: value}``. 57- The :doc:`user/actuators/rotorcraft_attitude` has been extended to be able 58 to control the rotorcraft in yaw rate or in absolute yaw (using the 59 ``YawRateControl`` property). So it is now possible 60 to use, for example, ``normal yaw`` or ``north`` using the 61 property ``UseAngleAgainstNorth``. Also, you can configure the actuator to 62 use a linear or quadratic thrust model using ``LinearThrust``. 63- Added a new :doc:`user/actuators/drag` "actuator" which allows for the simulation 64 of a drag (air resistance) force opposing the robot's movement. If used, this allows 65 more realistic simulations. 66- Added a new :doc:`user/actuators/external_force` actuator which can 67 apply external force (typically force from the environment such as wind), to 68 a robot. It has the same interface as :doc:`user/actuators/force_torque`, 69 but applies force in the global frame. 70- Added a new :doc:`user/actuators/quadrotor_dynamic_control` actuator which 71 supports controlling a quadrotor from the speed of its four engines, using 72 a simple dynamic equation. 73 74 75Sensors 76+++++++ 77 78- The **longitude**, **latitude** and **altitude** properties are no longer properties of 79 :doc:`user/sensors/gps` but must be set at the environment level. Moreover, 80 the property **angle_against_north** allows the angle between 81 the X-axis and the geographic north to be configured (It must be positive when the Blender 82 X-axis is East of true North, negative if is West of true North.). 83- Added a new high-level :doc:`user/sensors/attitude` sensor, allowing 84 the computation of the system's attitude. 85- Added a new :doc:`user/sensors/magnetometer` sensor, allowing the 86 computation of the Earth's magnetic field vector. 87- Extended the :doc:`user/sensors/imu` sensor, to also return the magnetic field 88 vector. 89- Fixed the :doc:`user/sensors/collision` sensor: it now detects collisions only 90 when it is actually colliding (before, any object in a 1x1x1m box around the 91 sensor would return a collision). Also the documentation has been 92 improved with the addition of a complete example. 93- Added a new :doc:`user/sensors/airspeed` sensor, allowing the computation of 94 the speed of a vehicle relative to the air. 95 96Modifiers 97+++++++++ 98 99- Introduced ECEF, Geodetic, and Geocentric modifiers, allowing the conversion 100 of coordinates from Blender world to ECEF-r or Geodetic or Geocentric 101 coordinates (and vice-versa). This should improve interoperability with flight 102 systems in general. 103- Introduced the Feet modifier, to convert imperial units to meter units (and 104 vice-versa) 105 106Middlewares 107----------- 108 109General 110+++++++ 111 112- Introduced a binding for the `Mavlink protocol 113 <http://qgroundcontrol.org/mavlink/start>`_, easing the interoperability of 114 Morse with a lot of free autopilots / architectures. 115 116ROS 117+++ 118 119- Some ROS 'housekeeping' has been performed in this release, including 120 removing the need for ``rospkg`` (easier installation!), removing the ROS interface 121 with the non-standard (and unused?) ``JointPositions`` message, and removing 122 references to ``roslib.load_manifest()``, a hangover from the rosbuild-era. 123 124HLA 125+++ 126 127- Now automatically handle the case where attributes published by Morse are not 128 owned by it. 129- Allow the specification of a ``stop_time`` for the simulation (in simulated seconds) 130- Make ``lookahead`` configurable for the Morse federate. 131 132YARP 133++++ 134 135- Addded an adapter for the :doc:`user/sensors/depth_camera`. 136 137Builder API 138----------- 139 140API additions 141+++++++++++++ 142 143- It is now possible to import environments composed of multiple scenes. The 144 user should choose which is the ``main_scene`` when importing the environment. 145 In addition, the ``Environment.set_background_scene`` method has been added to configure the 146 scene to use as background (`#651 <https://github.com/morse-simulator/morse/issues/651>`_). 147- The ``bpymorse.set_speed`` method , used to change the frequency of Morse's 148 main loop is now deprecated in favor of the ``Environment.simulator_frequency`` method. 149- The ``Environmement.set_time_scale`` method allows the simulation to be accelerated or 150 slowed-down (`#388 <https://github.com/morse-simulator/morse/issues/388>`_). 151- The new ``Environment.use_vsync`` method allows the vsync parameter to be controlled. 152 153 154Pymorse 155------- 156 157- Robots created in loops are now intelligently handled. They are still usable as 158 before, but it is also possible to access them using the list foos (if 159 your robot name is foo) (`#358 <https://github.com/morse-simulator/morse/issues/358>`_). 160- Streams are now created lazily, fixing control with a large number of robots / 161 sensors (`#626 <https://github.com/morse-simulator/morse/issues/626>`_). 162 163Previous releases 164----------------- 165 166.. toctree:: 167 :maxdepth: 1 168 169 releasenotes/1.3 170 releasenotes/1.2 171 releasenotes/1.1 172 releasenotes/1.0 173 releasenotes/0.6 174 releasenotes/0.5 175 releasenotes/0.4 176