This is a particular release for us, many things have changed. We are in the process of cleaning our whole framework.
We made a clear separation between public and private APIs, we hope that will help to have cleaner and backward compatible API.
We are in the process of opensourcing the NAOqi framework. This will allow us to build a better product and to integrate it easily with other robotics framework like Urbi and ROS. Opensource is coming slowly, in the 1.12 release you will find the two opensource foundation project: qibuild and libqi-doc. You will get more in the next release, the goal being to have the whole SDK opensource.
The documentation has been reorganised and converted to Sphinx.
We added documentation for all public C++ libraries (C++ library APIs) and for our cmake framework.
Brief
This version introduces a powerful tool to control and check NAO volume. No need to go on the robot web page anymore, it can be done directly from Choregraphe with the volume slider. This slider is accesible from the right part of the toolbar among all tools that concern the robot.
The volume slider is frequently refreshed to take in account every volume changes made outside of Choregraphe.
The battery indicator displays the robot battery level directly in Choregraphe. Each of the five states of the battery corresponds to a different display of the indicator. The indicator is visible from the right part of the toolbar among all tools that concern the robot.
The reconnection manager is a new feature that tries to re-establish a connection that has been lost. The process of reconnection goes with the display of a pop-up to warn the user that the connection was lost and that Choregraphe will try to reconnect to the robot at the end of the countdown. The initial value of the countdown is set to 30 seconds.
It is possible to reconnect without waiting the countdown by clicking on Reconnect or to cancel the reconnection process by clicking on Cancel.
The animation mode is an easier way to animate NAO. This mode proposes the possibility to activate and deactivate the stiffness of each part of NAO including the head.
Activation or deactivation can be made by calling each part of the robot as voice commands such as: left arm, right leg, head or by touching tactile sensors and pushing bumpers.
The tactile sensor on the middle of the head controls head stiffness. Left and right bumpers control respectively left and right legs stiffness. If the robot has hand’s tactile sensors, stiffness of arms can be controlled by them, if not, it is controlled by the two remaining head’s tactile sensors. Leds provide visual indications about which member of NAO has stiffness or not.
In the recording mode, the recording of joints positions can be made by saying Store positions or by pressing the chest button.
For further details, see sections:
NAOqi core has been cleanup up. Public APIs have been documented and reduced to their smallest subset. This will help us to have a stable and maintainable SDK. A new library ‘libqi’ has been written from scratch to provide cross-platform support. It includes log, data and configuration path management and posix abstraction for shared library, time and path.
Brief
This version contains a faster walk for NAO. Maximum walk speed has increased from 9 cm/s up to 14 cm/s, thanks to longer steps (going from 4 cm to 6 cm).
This walk is made possible by an adapted torso elevation, which makes the walk stable even if the movements are quicker.
This new walk is bit more battery-consuming, and increase NAO’s motors temperature quicker, but the walk speed is x 1.5 when NAO walks straight forward (x 1.5 for lateral movements, and unchanged for backward walk)
It is now possible to customize any walk parameters: footsteps height, length, rotation angle, torso orientation etc. These walk parameters can be set independently for each leg.
With these parameters, you can design totally custom walks, while still using trajectory interpolation features. These parameters can be updated on the fly, giving you even more possibilities.
Two new useful features are now available:
to start walking, ALMotionProxy::walkInit()
A new method in ALMotion that places the robot in a good position to start walking
to stop walking in a secure fashion, ALMotionProxy::stopWalk()
A new method that stops the robot quickly, but still in a secure position, that is with both feet on the ground (and not with one foot hanging in the air like what could occur with the previous method ALMotionProxy::killWalk())
The walk interpolation method has been changed. There used to be a Dubins curve interpolation for long walk distances, which has been removed to make NAO’s moves more predictable.
See Locomotion control for more details.
This version introduces a new motion security feature: anti self-collision on NAO’s arms. The idea is to prevent NAO’s arms from bumping into the rest of its body, to prevent possible damage.
The first part is collision detection. To do so, the algorithm uses the current position of the arms, and a model of NAO’s body (arms, head, torso etc) to compute the distance between each element. If at this position, a collision is possible, the collision avoidance step intervenes.
The collision avoidance step prevents the collision, and finds an alternative trajectory, that is as near to the desired command as possible. To do so, the trajectory is computed as an optimization under constraint of non-collision.
For the moment, this feature concerns NAO’s arms joint commands (joint command API and Choregraphe). It can be enabled or disabled (it can sometimes prevent particular movements which are too close from collision).
Refer to Self-collision avoidance for more details.
In the version, you will see the first step of dynamics computation in motion. We compute every cycle the dynamic model of NAO and deduced for static position (no joint in movement) the good stiffness to apply for each joint. As the stiffness is a limitation of torque, we first introduced in NAO a torque control startegy.
The result is a robot more compliant in static position and a lower increase of NAO’s motors temperature.
Refer to Smart Stiffness for more details.
A significantly better speech recognition engine is now available for V4 robot owners. It features an improved recognition rate, a better reactivity and can spot words/groups of words into a whole speech stream.
Note
The new ASR engine is only available for NAO V4 owners.
Processing audio signals is now significantly easier.
A new module called “ALAudioRecorder” has been introduced to handle specifically the recording of the signal coming from the microphones to wav and ogg files.
The reactivity (launch time, time to loop, etc...) of the wav files playing has been significantly improved allowing for example an easier synchronization with movements during choregraphies.
The ALAudioPlayer module is now also capable of playing a web stream and features new methods to monitor what files are currently loaded.
Brief
From the 1.10 to the 1.12 OpenNAO release, a lot of things have changed in the GNU/Linux distribution.
OpenNAO is no longer based on OpenEmbedded, it is now based on Gentoo.
This major change is motivated by:
OpenNAO is more standard, programs on the robot are more standard, you will have standard ps, grep, ls, bash, etc.. We hope it will be easier to work with the robot from a system point of view.
Brief
We have done many efforts to improve the Wi-Fi stability. We changed the driver for Ralink network adapter, and fixed many bugs in the whole stack including in connman.
Brief
The NAOqi C++ SDK had always come with various CMake scripts to help you build software for NAO.
Previous releases were using a lot of undocumented CMake functions, known as the ‘t001chain Framework’.
For this release, we decided to rename and document these functions, and this is how the qiBuild CMake framework was born.
The qiBuild CMake framework helps you write C++ code in a cross-platform way, it makes it easy to handle dependencies between libraries, to cross-compile, and to support compiler from gcc to Visual Studio.
It also comes with a set of command line tools, (qibuild configure, qibuild make ...) which helps you manage several C++ projects with their dependencies.
This is still a work in progress, but in the future this will be the easiest way to build applications using the NAOqi framework, on the robot, as well as on the desktop.
The whole project will of course be put in open-source license for everyone to contribute.
See also