libavr/libbioloid C library for CM5 released!

[buhochileno]

For the AX-S1, I need to write some better documentation(*). In the meantime try something like:

Code: Select all

uint8_t value = dx_get_IR_data_left(id);

Uhuuu, yeap, I now able to get my IR sensor data, very happy , if you want I can send you the code to be added as an a example...

One issue still bug me (but is related to the srvos not the sensor), and is that it seems that I can't turn off the torque to allow manual servo manipulation, my code is like this:
...
s.servo[1].id = 101; s.servo[1].position = 0;
dx_set_compliance(101, 30, 1, 0);
dx_set_max_torque(101, TORQUE_MAX);
dx_set_torque_enable(101, 1);
...
//key switch...
case 'e':
dx_set_torque_enable(101, 1);
break;
case 'd':
dx_set_torque_enable(101, 0);
break;
...no matter how many time I press "d", servo is still lock at his position, is that may be becouse the torque is set to max?, what is a proper setting for a manual servo manipulation?

Also as different matter, make a C# test that send the typical "w" or "s" bytes to the serial port to allow control of the CM-5 program from a diferent app (want to control my program from c#) and it seems that not all the "w" are received (or correctly sended), is like I send 100 "w" (to move the servo 100 positions in a direction) and it seems to move like 10..so is not the right way to control the program/robot from outside...I also want to send trough the serial port from c# more complex commands like "m 100" to move the robot at 100 speed...Any suggestions? (all this tested with C# with mono on linux of course)

Cheers,

Mauricio

[RandomMatt]

my code is like this:
...
s.servo[1].id = 101; s.servo[1].position = 0;
dx_set_compliance(101, 30, 1, 0);
dx_set_max_torque(101, TORQUE_MAX);
dx_set_torque_enable(101, 1);
...
//key switch...
case 'e':
dx_set_torque_enable(101, 1);
break;
case 'd':
dx_set_torque_enable(101, 0);
break;
...no matter how many time I press "d", servo is still lock at his position, is that may be becouse the torque is set to max?, what is a proper setting for a manual servo manipulation?

You don't need the "dx_set_max_torque" line - the torque specified in the robot structure is automatically given to the servo.

The case statement looks fine... so, you've possibly found a bug.

--

For clever input functions you could look in supervisor.c for how the supervisor works... basically you need to use getchar() and ungetchar() to build a parser.

On the plus side, as getchar() and ungetchar() are standard C functions you can test you parser on a PC without having to program the CM5 many times.

[StuartL]

...no matter how many time I press "d", servo is still lock at his position, is that may be becouse the torque is set to max?, what is a proper setting for a manual servo manipulation?

Can you include a get..() call to get the current torque setting and print that to the console? i.e. is the byte being set correctly. Maybe trigger a printf before and after the set_torque_enable call...?

[RandomMatt]

The case statement looks fine... so, you've possibly found a bug.

You have found a feature of the AX12 servo.

Let me explain - any attempt to write to the GOAL_POSITION of a servo will enable torque. So dx_set_torque_enable works, but it is overridden by dx_set_stance.

The fix is easy - download r1228 or later and have a look at the new example.c

[RandomMatt]

In the new version of libbioloid (r1226 or later) i've removed the delay member from the robot_t structure - so you'll all need to delete the corresponding line in your robot definitions.

The AX12 manual says that one should set the delay value as low as possible, assuming your code can deal with it. As libbioliod works fine with it set to 0 that is what it does in all cases

[buhochileno]

In the new version of libbioloid (r1226 or later) i've removed the delay member from the robot_t structure - so you'll all need to delete the corresponding line in your robot definitions.

The AX12 manual says that one should set the delay value as low as possible, assuming your code can deal with it. As libbioliod works fine with it set to 0 that is what it does in all cases

ok, do you have any svn repo to keep my source updated more easy?

Thanks

Mauricio

[RandomMatt]

do you have any svn repo to keep my source updated more easy?

no... for two reasons:

* trivially: it is in mercurial
* it doesn't let one partially publish stuff - my version control tree contains much code that the internet (and you) are not welcome to look at.

The obvious way to manage this is not to put code that you intend to publish in the same repo as code that you don't intend to publish - this isn't a solution because it expects you to have perfect foresight. Which I don't have.

[BillB]

RandomMatt wrote:

In the new version of libbioloid (r1226 or later) i've removed the delay member from the robot_t structure - so you'll all need to delete the corresponding line in your robot definitions.

Thanks for the update Matt.

I have noticed that upon startup, it can take a short while (approx 10 seconds) to scan through all the dynamixels on the bus. Is there anyway to speed this scan? - Perhaps by only scanning the dynamixels that are in the robot_t structure?

[RandomMatt]

Is there anyway to speed this scan? - Perhaps by only scanning the dynamixels that are in the robot_t structure?

That's what it does...
supervisor_init() runs a quick scan at power on.
if that scan fails - it runs a complete scan,
if that scan fails - it goes to the menu.
if any scan succeeds - it passes control to main().

--

So I think your problem is that a device fails during the quick scan, but sorts itself out by the time of the main scan. Is this a new problem?, i.e. have I broken the supervisor for your robot recently?

You could try tweaking the logic in supervisor_init() -- possibly putting a tick_delay(1) at the beginning (this would work if it is an initialisation race issue).

--

you can easily work around the problem by pressing the start button - this will cancel the scan ad run main() regardless.

[BillB]

RandomMatt wrote:

So I think your problem is that a device fails during the quick scan, but sorts itself out by the time of the main scan. Is this a new problem?, i.e. have I broken the supervisor for your robot recently?

No, it is not a recent problem - it has always been this slow. I suspect that I have a dodgy servo somewhere. i will try the supervisor_init() tweak and see it that makes a difference.

RandomMatt wrote:

you can easily work around the problem by pressing the start button - this will cancel the scan ad run main() regardless.

It would be easy if I could access the CM5 buttons. The CM5 is tucked deep in the abdomen of my Hexapod. Is there a variable that I can set in example.c to deactivate the scan and go straight to main()?

[RandomMatt]

Is there a variable that I can set in example.c to deactivate the scan and go straight to main()?

Just have a look in supervisor.c - adding -DNO_SUPERVISOR to your CFLAGS_AVR will do it. It will also remove the auto locking of servos - if you need that (and I think that you probably want it) - add dx_initrobot(&robot); to supervisor_init(): line 20ish.

[buhochileno]

The case statement looks fine... so, you've possibly found a bug.

You have found a feature of the AX12 servo.

Let me explain - any attempt to write to the GOAL_POSITION of a servo will enable torque. So dx_set_torque_enable works, but it is overridden by dx_set_stance.

The fix is easy - download r1228 or later and have a look at the new example.c

great!, thanks

[buhochileno]

do you have any svn repo to keep my source updated more easy?

no... for two reasons:

* trivially: it is in mercurial
* it doesn't let one partially publish stuff - my version control tree contains much code that the internet (and you) are not welcome to look at.

The obvious way to manage this is not to put code that you intend to publish in the same repo as code that you don't intend to publish - this isn't a solution because it expects you to have perfect foresight. Which I don't have.

ok man, it was just a question...

[BillB]

Random Matt wrote:

Just have a look in supervisor.c - adding -DNO_SUPERVISOR to your CFLAGS_AVR will do it. It will also remove the auto locking of servos - if you need that (and I think that you probably want it) - add dx_initrobot(&robot); to supervisor_init(): line 20ish.

Thanks Matt - I will give that a whirl.

[RandomMatt]

ok man, it was just a question...

True... and there is no harm in asking

When I decided to publish libbioloid, I did look at how to allow access to a repository - and it seems that the version control boys have not solved this particular problem (*).

* the problem is having some files that are private in a public repository.

--

You can always use wget or curl to get the tgz - in which case you'll only have a problem when I remove a file.