nbarikipoulos / poppy-robot-core Goto Github PK

aka from 0.19.2 to 0.20.0

In the exec function, in addition to ellipsis parameters, add possibility to use array of scripts.

To many lack/fail cases.

If the 'present_position' register value is not equal to the 'goal_position' one, switching the 'compliant' state of a motor to 'false' will imply movement to the goal position.

Then, add a new boolean argument named 'safe' to the setCompliant function of the ExtMotorRequest in order to reset or not the goal position to the present position when switching the compliant state to 'false'.

Set it default value to 'true' i.e. it will reset the goal position value to the present position one when compliant state is set to 'false'

To resume, add the following argument: @param {boolean=} [safe=true]

and then, it could be impossible to use the default 'poppy.local' hostname.

Store motor id in the robot descriptor when discovering the robot structure

Poppy motors and set of motors (aka alias) are nowadays provided through:

• An internal json file for common configuration (Poppy Ergo Jr),
• An external json file provided by users.
  Note such file is named robot descriptor.

Furthermore The default configuration is set to internal Poppy Ergo Jr descriptor.

In order to avoid extra settings for users to extend to any motor configuration driven by pypot (or other robot of the Poppy family), Change it to:

• Use the live discovering feature as default method to set up the robot structure,
• Allow users to provide their own robot descriptor , if needed.

In the computation of the estimated duration:

• When awaiting the end of movement is requested,
• If the speed is set to 0.

Use 1023 as speed value (cf. XL 320 manual )

Replace the compliant(boolean) function in Script with two functions witout arguments:

• compliant()
• stiff()

In ExtMotorRequest the optional wait value is set to:

• true for the function rotate,
• false in setPosition.

Set it to false for both.

Post request are not correctly performed and could implies dysfunctionnement of the robot (corrupting the registers of the motors.)

• Do not send all kind of values as string => use JSON.stringify,
• Set up request headers to { ‘content-type’: ‘application/json’ },
• In post request:
  • For the compliant register: Replace the boolean value by 0/1,
  • For posted numerical values: use integer instead of float.

The response of the request /motor//list.json has changed: it now returns { : ["m1", "m2", etc...] } instead of { "alias": ["m1", "m2", etc...] }

• Avoid message about promise rejection,
• Update error message to more human-readable error.

In PoppyRequestHandler object:

• Add more explicit post and get functions,
• In perform function remove default value for request method,
• Remove useless async keywords to functions.

Generic issue that gathers code improvement or update.

Do not "hide" anymore the asynchronous js/node "behavior."

This is mainly motivated by removing the limitation due to the sync-like suggered coding nowadays used.

Indeed, all async operations execution are "deported" in the last stage i.e. the script execution ( which is asynchronous). All others, such as Poppy instantiation, script definition, etc... could be considered as pre-execution stages only dedicated to define and describe operations for script execution.

That:

• harms maintainability/evolutivity of this module conflicting with js/node paragdims,
• may misleading users: at last "real" operations to the robot are executed asynchrinously.

In particular, #2 which need to query robot as initial step, could not be fixed.

Do not instantiate the robot descriptor from inner methods of Poppy robot but provide it from constructor parameters.

Then, adapt the poppy object factory to handle descriptor instantiation.

aka the 0.21.0 one.

It seems to be connected with the use of (many?) custom instance in Axios.
As:

• Custom instances imply recurrent bugs/issues (see the axios project),
• Calling directly the axios API solves this issue.

Replace custom instance with direct call of axios with specific config settings for each kind of request.

Way to provide robot descriptor through an input file is useless and it should be only done via live disovering of the target robot.

Then notion of descriptor locator in config should be removed as well as corresponding code.

• Remove david badges (almost always down),
• Add lgtm/codeclimate badges.

In settings, add a function in order to:

• First set up properties of the connection object with defaut values if not provided,
• On a second hand, resolve hostname.

In connection object:

• Rename the 'ip' property to 'hostname',
• Add a property in order to store resolved adress,

In order to avoid "overload" of the robot server, chain requests of "complex" commands (aka that are based on many requests) such as discovering the structure of the robot/ querying many registers/motors.

Aim is to avoid to "overload" the robot REST api with to many requests in the same time, especially when many clients are connected on (cli or ui as example).

Sometimes (often enough) next to some (unfortunately unidentified) actions, register value seems to be frozen or http server does not respond well.

Next to perfoming a reset request, everything seems to back to normal.
Then add it.

When motors are already stiff, changing the target speed with 'goal_speed' could imply "invonluntary" movement depending of the goal/present position values.
Too boring/complicate to use/set in script compared to the 'moving_speed' register

On getRegister function of PoppyRequestHandler, in order to avoid globally throwing an error when a request failed for a register:

• Catch the error,
• Set returned value for return data with value set to 'undefined'.
  As example, querying motor m1 for 'present_position' and 'compliant' register values:

req.getRegister('m1', 'present_position', 'compliant')

will return

{ present_position: 90.0, compliant: undefined }

instead of throwing error is request on register 'compliant' failed.

Add new condition about expected duration of the mouvement.

• In poppy object rename property allMotorIds to motorNames,
• In PoppyrequestHandler, remove useless getter settings,
• Misc. update/renaming/code cleaning.

Use the "files" property in package.json on order to ensure to not pack unwanted/extra files.

Add the model of the motor.

Mention these points in documentation:

• This module requires the v3.x.x release (aka it is based on pypot REST API v3.x.x),
• It has been only tested with dynamixel XL-320 (aka Ergo Jr).

aka to poppy software 4.0.0

In object factories, simplify arg from
createXXX({ connect })
to
js createXXX(connect)
aka change the poppy configuration object structure from
{ connect: { hostname: .., port: ..., ... } }
to
{ hostname: .., port: ..., ... }

• axios from 0,21 to 0.24,
• dev dependencies.

• Remove the utils folder and dispatch it to new ones: poppy and request,
• Rename:
  • default-settings.js to settings.js,
  • descriptor-factory.js to descriptor.js,
  • poppy-utils.js to factories.js.
• Split factory and discoverDescriptor in descriptor.js.

As it could be a hostname or an ip, it seems to be clearer.

When an error occurs, the perform function of the PoppyRequestHandler return an error object instead of throwing it.

Uniformize it with other get request: '/list.json' sufix is missing.

Next to #12, it is not mandatory to use the snap rest api to set led values (it was a side effect).

Then remove any use of the rest api exposed by snap.

Then simplify the connection settings object: rename httpPort to port.

Add a factory to create new PoppyRequestHandler that automatically:

• Add missing connection properties to connection object (aka set to default),
• Resolve hostname.

Robot descriptor (aka motors list and settings) are nowadays:

• hard-coded for a set of common configuation (Ergo Jr),
• provided via a json file by user.

Add a live discovering feature.

Set it to 500ms instead of 1s

Use the 'goal_position' register instead of 'present_postion' to get the target position value.