libavr/libbioloid C library for CM5 released!

[Mirko]

@Dimitris

Hello, excuse me, have you succeded in moving the dynamixels? I have the same problem. I can scan or write, but not move them (neither writing in both location 30 and 31 and enabling torque)... In example.c there is no reaction when I press w,W etc (thought the positions on screen change accordingly) , while using ',' or '.' just makes the transmission led on the Cm5 turn off or on, respectively. Additionally, it takes a very long time (several tens of seconds) to complete a scan or to have informations on the AX12s (that is, informations appear immediately, but I have to wait to obtain the > prompt). Finally, very often the messages on the terminal window become meaningless or delayed, and I have to disconnect and connect again to restore the synchronization. Can it possibly be related to the fact that I am using a usb2serial connector?

One more thing: when I come back to the original Bioloid firmware, I always find the baudrate changed to 2MBps... is it your case too?

[Dimitris]

Hi Mirko,
No I haven't had the chance to troubleshoot yet but I have more or less the same problems as you and I'm also using a usb-to-serial connector.
I haven't switched back to the original firmware to check the baudrate.

[Mirko]

Thank you...

The synchronization problem is probably connected only to the Robot Terminal, and not to the communication with the CM5, but when scanning the Dynamixels it always ends up with a bus error, even if it correctly finds every connected IDs...

[limor]

Spent some time with libbioloid yesterday and have some feedback.
This is the best written library i've seen so far for CM5. the coding style is not straightforward and it takes some time to understand the sequence of things in the code and makefiles.

1) to compile the little code that produces the trig-tables, you must use mingw. such a small harmless piece of code but it must be compiled with mingw nothing else worked out of the box.

2) the example.c can read the servos but not move them. however if instead of using the setstance routine, you use the dx_write or dx_setposition, it works.

3) i tried compiling with the -DNO_SUPERVISOR flag and that worked as expected. however, there is no easy option to turn off the whole timer utility functions with the 6250/HZ timer frequency flag thingy. I get unexpected performance problems because of that TMR3 interrupt routine seems to be hogging up the CPU resources. i don't understand what it does. Tried different values of HZ but i'm out of ideas. looks like the interrupt routine is polling on a static/global variable and it even ran into race conditions that completely block the processor until reset

How can I disable the timers and watchdog?
Also: do the UARTs by default get handled by interrupts or by polling?

thanks!

[gigacool]

Hi everyone,

I have been toying a little with libbioloid for last few days. First I want to thank the developers as it prove a useful library. Now considering recent posts and personal experiences, I found out that the example.c out of the box does not work on my bioloid; everything seems to works fine but the motors won't move.

after a few trials, for some reason I duplicated the dx_set_stance(&s); and the motors suddenly began to move. Any reason for that ?

I have also been trying to get sensor values but no success so far. How am I supposed to do ? (I guess I have to add the sensor to the robot_t_FLASH const and change the MODEL_AX12 to some MODEL_SX1 ? Should I also modify the dx_stance_t ?)

In the end, the library looks fine but I feel that examples are not complete for a beginner to begin with and I could find very little documentation regarding methods and their parameters. Maybe I am confused as I don't usually program in C... Regarding the bioloid supervisor menu, I can't understand a few functions proposed (authorise, enter the supervisor (am I not already within it ?))

Thank you and keep the the good work

[RandomMatt]

1) to compile the little code that produces the trig-tables, you must use mingw.

I find that hard to believe... it is only standard C. it just works on unix / linux and mac. Are you sure that the other C compilers you've tried can actually compile C code from make?
That said... on windows I just use mingw because I didn't like the fact that cygwin demands to install the (removed by spam filter) sink.

2) the example.c can read the servos but not move them. however if instead of using the setstance routine, you use the dx_write or dx_setposition, it works.

Interesting... please hold while I find out what the hell is going on. (I'm sure that I found a bug with those symptoms and fixed it).

however, there is no easy option to turn off the whole timer utility functions with the 6250/HZ timer frequency flag thingy. I get unexpected performance problems because of that TMR3 interrupt routine seems to be hogging up the CPU resources. i don't understand what it does. Tried different values of HZ but i'm out of ideas. looks like the interrupt routine is polling on a static/global variable and it even ran into race conditions that completely block the processor until reset

the timer 3 handler does two things. it increments a tick counter, and calls anything that it has been asked to, as often as they have asked for. if you grep for timer_add you'll see that it is used in only two places: the battery voltage code and the auto zigbee/cable detection. neither of those uses that many cycles - so i think your performance problem is somewhere else.

My guess is that you are sending piles of data down a uart (either due to code, or retransmission) - when the buffer is full things have to block. The other performance gotcha is that dx_read() and dx_write() have to block until the servo responds - so your avoidance of dx_set_stance() is going to be a problem.

The timer count is used for the auto retransmit code in dynamixel_packet (once again, you can find this by using greping for timer) - so if you sets HZ very low you'll increase the wait time for packet retransmit... this may look like a crash.

Also: do the UARTs by default get handled by interrupts or by polling?

The uarts are interrupt driven...

[pieddemamouth]

hey there,

2) the example.c can read the servos but not move them. however if instead of using the setstance routine, you use the dx_write or dx_setposition, it works.

Interesting... please hold while I find out what the hell is going on. (I'm sure that I found a bug with those symptoms and fixed it).

I've work a bit on this because I need the bioloid for teaching and libbioloid was looking like something usefull. It didn't succeed to solve the pb but I post here the result of my tests. Maybe it will help someone.

There is some memory problems in dx_set_stance. For example I've try to display the value of the array packet_chunk right after declaration :

Code: Select all

    uint8_t packet_chunk[] = {DX_BROADCAST, 0, INST_SYNC_WRITE, A_goal_position, 2};
      for (id_t i=0 ;i<5 ;i++)
         printf("%x :: ",packet_chunk[i]);


And the result is :

Code: Select all

0002 :: 0000 :: 0000 :: 0000 :: 0000 ::


I display also the value of the array after the call to dx_sendpacket_start(). Here is the result :

Code: Select all

007E :: 0000 :: 0000 :: 0000 :: 0000 ::


So each time the values are wrong and moreover they are modified during the call to dx_sendpacket_start().

I've check if there was a previous declaration of this array and didn't find anything.

Interestingly everything is ok when dx_set_stance is called two times (gigacool idea). Even the first call is right.

During this debugging I've come with one more question : where is defined A_goal_position ? I've really search for it and I haven't find anything

[pieddemamouth]

A bit more debugging. It doesn't seem related to the previous bug.

Here is the log of me trying to write at various places in a AX-12.

First the initial state of the AX-12's memory :

Code: Select all

a/A: authorise, b/B: bridge 1M/57600, g/start button: go, h: help, i/I: info,
m/M: dump memory, n: repeatedly dump memory, p: power+battery status,
r: renumber, w: write, x: rescan, !: reset id, #: reboot, ~: enter supervisor
(capital letter versions of the commands operate on all ids)
> m
id: 1
id=1   E: 0C00 1601 0100 0000 FF03 833C 3C8C FF03
      0224 2400 2800 CD03
   R: 0100 0101 2020 0102 FF03 FF03 0002 0000
      0000 7E25 0000 0001 2000


Now I'm putting the led on, and display the new memory state. One can see that the value 1 has been correctly written at place 25 (second byte in ram). I have also seen the led on.

Code: Select all

> w
id: 1
starting byte: 25
value to write at 25 in device 1 or CR to exit: 1
set byte 25 in device 1 to 1, press Y to confirm:
value to write at 26 in device 1 or CR to exit:
> m
id: 1
id=1   E: 0C00 1601 0100 0000 FF03 833C 3C8C FF03
      0224 2400 2800 CD03
   R: 0101 0101 2020 0102 FF03 FF03 0002 0000
      0000 7E25 0000 0001 2000


Then I put the led off : writing 0 at address 25, and display once again the memory. Everything is fine : the led is off

Code: Select all

> w
id: 1
starting byte: 25
value to write at 25 in device 1 or CR to exit: 0
set byte 25 in device 1 to 0, press Y to confirm:
value to write at 26 in device 1 or CR to exit:
> m
id: 1
id=1   E: 0C00 1601 0100 0000 FF03 833C 3C8C FF03
      0224 2400 2800 CD03
   R: 0100 0101 2020 0102 FF03 FF03 0002 0000
      0000 7E25 0000 0001 2000


Here is the problem : I want to write 0 at addresses 8 and 9. The aim is to activate the Endless Turn Mode. When displaying the memory state after having write, one can see that the values aren't modified.

Code: Select all

> w
id: 1
starting byte: 8
value to write at 8 in device 1 or CR to exit: 0
set byte 8 in device 1 to 0, press Y to confirm:
value to write at 9 in device 1 or CR to exit: 0
set byte 9 in device 1 to 0, press Y to confirm:
value to write at 10 in device 1 or CR to exit:
> m
id: 1
id=1   E: 0C00 1601 0100 0000 FF03 833C 3C8C FF03
      0224 2400 2800 CD03
   R: 0100 0101 2020 0102 FF03 FF03 0002 0000
      0000 7E25 0000 0001 2000
>


So, it's looking like the lib is able to write in the ram but not in the Eeprom ... I don't get well the code in uart.c so I haven't been able to further debug.

[RandomMatt]

There is some memory problems in dx_set_stance. For example I've try to display the value of the array packet_chunk right after declaration :

Code: Select all

    uint8_t packet_chunk[] = {DX_BROADCAST, 0, INST_SYNC_WRITE, A_goal_position, 2};
      for (id_t i=0 ;i<5 ;i++)
         printf("%x :: ",packet_chunk[i]);


And the result is :

Code: Select all

0002 :: 0000 :: 0000 :: 0000 :: 0000 ::


Well that's clearly wrong (as you know). I remember having many many problems with the C compiler not working (i.e. compiler bugs)... my solution was to find a version of the compiler that worked with no bugs, and then never change it. FWIW I am using 4.1.2 on debian.

My rant is easily testable... just replace the defintion of packet_chunk with something like "uint8_t packet_chunk[] = {23, 12, 54, 98, 123};" and run your test code again. (the correct output is clearly whatever those numbers are turned into hex).

---

For what it is worth A_goal position is a enum, defined by a macro using dynamixel_memory.h - it has value 30 (decimal). But I don't think the bug has anything to do with that.

also... dynamixel_start() doesn't overwrite anything - so something properly weird is happening. dynamixel_start() initialises the checksum and calls uart_tx(). uart_tx() copies the bytes into the uart ring buffer for interrupt driven sending - it also doesn't trample to data.

Finally... your testing using the supervisor works exactly as I think it should. When you leave the supervisor it locks all the devices so that crap on the bus doesn't cause complete chaos. Locking an AX12 means making all the eeprom locations read-only - hence your symptoms. The way to unlock a servo is to power cycle it.

[pieddemamouth]

Hi,

Thanks for the complete reply.

Im using the version 4.3.3 of avr-gcc on Ubuntu. I will take a look latter for an old package of the version 4.1.2.

I'm ok with the various precisions you have made. I wasn't knowing about this locking system on the AX-12, interesting.

[lrice648]

Has anyone figured out what the issue with the example file is? When I initially installed libbioloid, I was able to get the example working, now I cannot.

Here is what I've done:
Installed original firmware and confirmed that baud rate is set to 1.
In console with original firmware I can read and set memory locations.
In console with original firmware I can move dynamixels around.

The example compiles fine. I transfer it as instructions say, and run program. When I run the example, I see the values for S1, etc changing, but no movement.

To test I go back to the supervisor:
I can write to the 24 (LED) with no issues.
I can do a memory dump and see changes.
I can change 30/31 (though for some reason they aren't changing to what I thought, but I can usually zero them out).

What else should I try? I've not gone so far as to start swapping out a ton of dynamixels and changing id's and what not, but everything seems to be working elsewhere, just nothing happens with dx_set_stance. I guess next time I'll get 3 working dynamixels and change their id's and hook them up...any help is appreciated though.

[pieddemamouth]

Hi lrice648,

Some ideas you could try from the last posts
The fast fix by Gigacool :

after a few trials, for some reason I duplicated the dx_set_stance(&s); and the motors suddenly began to move. Any reason for that ?

A more "permanent" solution by Matt:

Well that's clearly wrong (as you know). I remember having many many problems with the C compiler not working (i.e. compiler bugs)... my solution was to find a version of the compiler that worked with no bugs, and then never change it. FWIW I am using 4.1.2 on debian.

[lrice648]

I'll try duplicating set_stance later today.

I've been using winAVR since I first came across libbioloid, I've not reinstalled or changed compilers since (and I got the first version of libbioloid working on this very machine). I just upgraded to the newest version (in case it would fix my problem), but no go. Can anyone confirm a version of winAVR/mingw that works for them with the latest libbioloid release?

Would downgrading possibly fix my issue? I no longer remember what the very first version was, but I feel like going back to it wouldn't be that useful as I'm sure some important things have changed/been fixed.

Thanks for your suggestions!

[lrice648]

That did seem to work, for some reason I used it for a while and it would only work to move 1 dynamixel but at some point (not even sure what I did) it started working correctly.

I had a question about writing to locations 30 and 31 though, I've read on here that you have to do it a special way but I can't manage to write ANYTHING to those locations. I've tried with torque_enable on 0 and 1, and no value I try to write has any effect.

2nd question: Has anyone tried to use the zigbee wireless with libbioloid? Does anyone have any advice on where to start with that? I know how to do it in the BCP but I really don't want to use that if I can help it. The zigbee's are matched up already and we know they work. I just want to find a way to use them in C as opposed to BCP.

Thanks again for all the help and for making libbioloid!

[pieddemamouth]

Hello there,

I have finnaly try the solution proposed by Matt. And indeed it works. I have to admit that I'm a bit surprised. Not used to see the compiler failing.

Just a bit more detail on what I'm using and how I've set it up. To install my compiler I've follow the guide here : http://electrons.psychogenic.com/module ... gGuide.php
The only strong modifications was using the following line to confiture the compilatio of gcc :

Code: Select all

$ ./configure --prefix=/usr/local/AVR \
                   --target=avr --enable-languages="c,c++" \
                   --disable-nls
                   --disable-libssp


I'm now using gcc 4.1.2, binutils 2.20, avr-libc 1.7.0

Side note :
For my students I'm using another lib (partly made by another guy and I've add other stuff). This lib is simplier (doesn't have the stance system), but works well for me (moving the bioloid as a car). Is it usefull to release it ? i.e. are some people here interested ?