Closed fedeallocati closed 8 years ago
Thanks for all that work ! I'll read and comment on the code.
For now, based on your description, what about renaming the base class for exceptions to something specific to dynamixels, like DynamixelError (or put it in the dynamixel namespace) ? I find it misleading when reading code using this library and finding exceptions instances of that type. It doesn't let the programmer know where to look for the definition of the class and what it represents.
I know you kept the existing class, the original name is not your doing. :)
For now, based on your description, what about renaming the base class for exceptions to something specific to dynamixels, like DynamixelError (or put it in the dynamixel namespace) ? I find it misleading when reading code using this library and finding exceptions instances of that type. It doesn't let the programmer know where to look for the definition of the class and what it represents.
Actually they are inside the dynamixel
namespace, and also the new errors
namespace.
I will also add some comments, so it's clear how to add new models/fix current ones.
I finished the object oriented API.
We now have a dynamixel::auto_detect
method (in the misc file), with inheritance and model abstraction.
With this I think that the V2 is completed and ready to merge. The arm compilation is missing(because I updated the waf version, and their API changed), and also all of the old examples, but we can add that later.
In the code, there are many assertions. Are they the proper use cases for assertions ?
cc: @jbmouret @costashatz
In the code, there are many assertions. Are they the proper use cases for assertions ?
cc: @jbmouret @costashatz
I will have a look this week... I am not convinced yet that all these assertions should be there.
They should'nt be, but it was the quickest way to leave a TODO for throwing exceptions :P
2016-03-01 10:58 GMT+01:00 Konstantinos Chatzilygeroudis < notifications@github.com>:
In the code, there are many assertions. Are they the proper use cases for assertions ?
cc: @jbmouret https://github.com/jbmouret @costashatz https://github.com/costashatz
I will have a look this week... I am not convinced yet that all these assertions should be there.
— Reply to this email directly or view it on GitHub https://github.com/resibots/libdynamixel/pull/6#issuecomment-190641600.
It seems that we love typedefs. Then, why don't we use one for the packet's parameters (like here) ? We already use typedefs for instr_t
, even though it maps to the same type for protocol 1 and 2.
What is the difference between a reg_goal_position_angle and a set_goal_position_angle ?
Reg methods store the value in a temporary memory of the servos, that gets written to the RAM or ROM when you send it an Action instruction. That's what we are using in dynamixel_control_hw to send the joint positions all at the same time: we first register the positions in all the servos, and then broadcast an Action instruction El mar. 2, 2016 8:59, "Dorian Goepp" notifications@github.com escribió:
What is the difference between a reg_goal_position_angle and a set_goal_position_angle ?
— Reply to this email directly or view it on GitHub https://github.com/resibots/libdynamixel/pull/6#issuecomment-191118180.
OK thanks
As soon as all previous comments are solved, I'm ok for merging.
@costashatz Did you have a look at the asserts ? Shall I do this ?
@dogoepp I will do it this weekend. I would have done it today but I got held up by a bug in hexapod_dart..
On Fri, Mar 4, 2016, 17:38 Dorian Goepp notifications@github.com wrote:
@costashatz https://github.com/costashatz Did you have a look at the asserts ? Shall I do this ?
— Reply to this email directly or view it on GitHub https://github.com/resibots/libdynamixel/pull/6#issuecomment-192346821.
Konstantinos Chatzilygeroudis PhD Candidate Team Larsen INRIA Nancy Grand-Est Room C121 e-mail: konstantinos.chatzilygeroudis@inria.fr web: http://costashatz.github.io/
@costashatz Did you have a look at the asserts ? Shall I do this ?
@dogoepp @fedeallocati please look at #11 ..
Please have a look at #13.
Besides, ready to merge ?
Please have a look at #13.
Besides, ready to merge ?
Once we merge #13, I will format the code. Then we are ready to merge..
When do you think you coud take care of the formating @costashatz ? Do you need help on this ?
OK to merge ?
OK to merge ?
There are conflicts...
Because I updated v1 but the related file is deleted in v2 (utility program).
Le 11/03/2016 16:44, Konstantinos Chatzilygeroudis a écrit :
OK to merge ?
There are conflicts...
— Reply to this email directly or view it on GitHub https://github.com/resibots/libdynamixel/pull/6#issuecomment-195421710.
Because I updated v1 but the related file is deleted in v2 (utility program).
Yes but we need to fix it..
I finally finished the version 2 of the implementation:
CRCError
(when the dynamixel sends a package and the computed CRC doesn't match the received CRC) andStatusError
(the error bit fields in the Status Packet). They both inherit from the base class Error.Usb2Dynamixel
controller for the timeout parameter (now it is in the class instead of therecv
methodWhat is missing is the adaption of the examples and tools to the new API, and some higher level functionality like search of the available servos.
I don't expect to merge rigth now, but I need feedback on this. CC: @dogoepp @costashatz @jbmouret