Embedded C programming
Embedded C programming
by Fritzoid
Mon Oct 04, 2010 1:40 pm
Good news! The BioCode Project is announcing its latest creation, BioC. Now you can replace your interpreted RoboPlus Task code with compiled C. That's right, real C, with printf() and switch() and so much more.
Bad news! So far, there's only one compiler on earth that supports BioC. It's ICCAVR by ImageCraft Creations.
Good news! A non-commercial license for ICCVAR is only $99 US and a 45-day free trial is available for download at...
http://www.imagecraft.com/
Bad news! ICCAVR only runs on Windows platforms. Sorry, I can't do anything about that.
Great news! If you're OK with all that, then the rest is easy and it's free. The BioC.zip archive is available for download in my files area at...
http://robosavvy.com/Builders/Fritzoid
The package includes everything you will need to get up and running with BioC. To show you how to write programs in BioC, the archive includes two prebuilt sample projects.
1. BioUtility demonstrates the reading and writing of control table entries with BioC and makes use of the printf() function.
2. Humanoid_A is a complete translation, into C, of the Robotis demonstration program HumanoidTypeA.tsk. That's right, the whole thing; Demo mode, Remote mode, and Auto-walk mode plus the "Walking Machine." Enough to get your robot up and moving today.
If you are serious about programming the Bioloid then this is what you've been looking for. Honestly, you have got to check this out.
Bad news! So far, there's only one compiler on earth that supports BioC. It's ICCAVR by ImageCraft Creations.
Good news! A non-commercial license for ICCVAR is only $99 US and a 45-day free trial is available for download at...
http://www.imagecraft.com/
Bad news! ICCAVR only runs on Windows platforms. Sorry, I can't do anything about that.
Great news! If you're OK with all that, then the rest is easy and it's free. The BioC.zip archive is available for download in my files area at...
http://robosavvy.com/Builders/Fritzoid
The package includes everything you will need to get up and running with BioC. To show you how to write programs in BioC, the archive includes two prebuilt sample projects.
1. BioUtility demonstrates the reading and writing of control table entries with BioC and makes use of the printf() function.
2. Humanoid_A is a complete translation, into C, of the Robotis demonstration program HumanoidTypeA.tsk. That's right, the whole thing; Demo mode, Remote mode, and Auto-walk mode plus the "Walking Machine." Enough to get your robot up and moving today.
If you are serious about programming the Bioloid then this is what you've been looking for. Honestly, you have got to check this out.
by Fritzoid
Tue Oct 12, 2010 12:35 pm
I have updated the BioC archive at the above link!
This release fixes a serious bug that was causing havoc when the printf() function was being used in a complicated program.
In addition, a third sample project is included in the package. This program demonstrates use of the rdpkt() and wrpkt() functions. With these functions a programmer can send and receive custom packets on the dynamixel bus.
Finally, the BioLoad downloader program has new reliability and failure detection improvements that make it a good deal more useable.
With BioC you can now go well beyond the capabilities of RoboPlus Task,
plus you get to use a real editor and compiler at the same time. To an experienced C programmer, this just "feels right".
Together these improvements make BioC the most flexible and efficient solution to date for controlling your Bioloid.
This release fixes a serious bug that was causing havoc when the printf() function was being used in a complicated program.
In addition, a third sample project is included in the package. This program demonstrates use of the rdpkt() and wrpkt() functions. With these functions a programmer can send and receive custom packets on the dynamixel bus.
Finally, the BioLoad downloader program has new reliability and failure detection improvements that make it a good deal more useable.
With BioC you can now go well beyond the capabilities of RoboPlus Task,
plus you get to use a real editor and compiler at the same time. To an experienced C programmer, this just "feels right".
Together these improvements make BioC the most flexible and efficient solution to date for controlling your Bioloid.
by siempre.aprendiendo
Tue Oct 12, 2010 4:41 pm
It seems very interesting, Fritzoid
Is still possible to use the Toss Mode? I use it a lot!
Do it execute the motion as RoboPlus generated code?
Recently I have created a little program to use the CM-510 as a bridge between the PC (by BT) and the new sensors and dynamixels. It's like the Toss mode, but with the added function of querying the CM-510 for the sensor values.
I'm not very good programming microcontrollers, but it works and If it seems interesting to you I could publish the code.
Is still possible to use the Toss Mode? I use it a lot!
Do it execute the motion as RoboPlus generated code?
Recently I have created a little program to use the CM-510 as a bridge between the PC (by BT) and the new sensors and dynamixels. It's like the Toss mode, but with the added function of querying the CM-510 for the sensor values.
I'm not very good programming microcontrollers, but it works and If it seems interesting to you I could publish the code.
by Fritzoid
Tue Oct 12, 2010 6:17 pm
siempre.aprendiendo wrote:
Yes, Toss mode works the same as always. It is usually entered from Manage mode, which is unchanged in the firmware. BioC runs in Play mode.
he also wrote:
The answer yes again. The native RoboPlus motions are run by the existing Robotis firmware. All your program has to do is set the Motion Page to the number you want, just like in RoboPlus Task.
RoboPlus Task (BCP) is modelled after C, so converting from BCP to BioC is actually very easy. Compare the sample file Humanoid_A.c to its RoboPlus equivalent, Humanoid_A.tsk, and you'll see they are strikingly similar.
Is still possible to use the Toss Mode? I use it a lot!
Yes, Toss mode works the same as always. It is usually entered from Manage mode, which is unchanged in the firmware. BioC runs in Play mode.
he also wrote:
Do it execute the motion as RoboPlus generated code?
The answer yes again. The native RoboPlus motions are run by the existing Robotis firmware. All your program has to do is set the Motion Page to the number you want, just like in RoboPlus Task.
RoboPlus Task (BCP) is modelled after C, so converting from BCP to BioC is actually very easy. Compare the sample file Humanoid_A.c to its RoboPlus equivalent, Humanoid_A.tsk, and you'll see they are strikingly similar.
by Buell24
Sun Oct 31, 2010 7:37 pm
I tested the bioC. For me it don’t works!
I think the firmware is ok, because I could choose the play LED pressing the red Button as it is with the roboplus firmware. When I then choose the demo mode, only the sound “do” appears. And nothing more.
Another issue I detected is, that the restoring of the roboplus firmware after the bioC couldn’t be done correctly. I also opened a theme about that.
Anybody else, who had this problems?
I think the firmware is ok, because I could choose the play LED pressing the red Button as it is with the roboplus firmware. When I then choose the demo mode, only the sound “do” appears. And nothing more.
Another issue I detected is, that the restoring of the roboplus firmware after the bioC couldn’t be done correctly. I also opened a theme about that.
Anybody else, who had this problems?
by Fritzoid
Mon Nov 01, 2010 3:46 pm
Buell24 wrote:
The Do sound indicates that the robot is a type A configuration. That is, that all 18 servos are present. After the robot type is determined the the CheckAssembly subroutine is called and the robot should stand up. Only after the robot stands up are the buttons read.
When Demo mode is entered the robot plays a little dun-da-da melody, much more than a single note. It sounds like you didn't actually get into Demo mode. So, I would like to know if your robot stood up after playing the Do note.
As far as restoring the Robotis firmware, you shouldn't really have to. You can still run a RoboPlus Task with the BioC firmware installed. However it should always be possible to reinstall the firmware using RoboPlus Manage. I have done this myself many times. It can be a little tricky and may take a couple of tries to get right.
You can also restore the firmware using RoboPlus Terminal in just the same way as you loaded the BioC firmware. Just get into the bootloader and Load the original hex file.
Since you may not have saved the original firmware before overlaying it with BioC firmware, I have uploaded a copy to my files area. You can get the file CM-510_1964.zip at the following link:
http://robosavvy.com/Builders/Fritzoid/
From your other post I think that you may have gotten past this problem already.
When I then choose the demo mode, only the sound “do” appears
The Do sound indicates that the robot is a type A configuration. That is, that all 18 servos are present. After the robot type is determined the the CheckAssembly subroutine is called and the robot should stand up. Only after the robot stands up are the buttons read.
When Demo mode is entered the robot plays a little dun-da-da melody, much more than a single note. It sounds like you didn't actually get into Demo mode. So, I would like to know if your robot stood up after playing the Do note.
As far as restoring the Robotis firmware, you shouldn't really have to. You can still run a RoboPlus Task with the BioC firmware installed. However it should always be possible to reinstall the firmware using RoboPlus Manage. I have done this myself many times. It can be a little tricky and may take a couple of tries to get right.
You can also restore the firmware using RoboPlus Terminal in just the same way as you loaded the BioC firmware. Just get into the bootloader and Load the original hex file.
Since you may not have saved the original firmware before overlaying it with BioC firmware, I have uploaded a copy to my files area. You can get the file CM-510_1964.zip at the following link:
http://robosavvy.com/Builders/Fritzoid/
From your other post I think that you may have gotten past this problem already.
by Fritzoid
Tue Nov 09, 2010 1:17 pm
My first choice was to use GCC and I've take a few runs at it so far, but I just keep hitting complications. The Imagecraft compiler has a couple of critical features that GCC cannot duplicate.
Firstly, the register usage and calling conventions are identical to the compiler used by Robotis. This avoids a bunch of register swapping around the function calls. Inconvenient but not a deal breaker!
The key feature is how ICCAVR handles input and output. Rather than buffering the data themselves, the Imagecraft people rely on the user to write the low-level getchar() and putchar() routines. These routines are then called by the higher-level formatting I/O routines, like printf(), when there is a single byte of data to process. This might seem like a drawback but for BioC it's a blessing.
Because I have already identified the entry points in the Robotis firmware that perform the getchar() and putchar(), the compiler can use the actual internal Robotis subroutines to read and write data. This means that they use the internal Robotis buffers too!
GCC has no similar ability that I can find. It's probably not a big deal on the output side because that's not buffered. However, the input is buffered by interrupt-driven logic and GCC will not coexist with this. So some code to establish the GCC buffering and interrupt environment will be necessary as well as some code to reestablish the Robotis environment at completion time. I seriously doubt that the remote control processing will work without a bunch of new code too.
So with GCC it's a battle at every step but with ICCAVR the pieces just fall into place. It doesn't take long before the $99 solution looks compelling!
Firstly, the register usage and calling conventions are identical to the compiler used by Robotis. This avoids a bunch of register swapping around the function calls. Inconvenient but not a deal breaker!
The key feature is how ICCAVR handles input and output. Rather than buffering the data themselves, the Imagecraft people rely on the user to write the low-level getchar() and putchar() routines. These routines are then called by the higher-level formatting I/O routines, like printf(), when there is a single byte of data to process. This might seem like a drawback but for BioC it's a blessing.
Because I have already identified the entry points in the Robotis firmware that perform the getchar() and putchar(), the compiler can use the actual internal Robotis subroutines to read and write data. This means that they use the internal Robotis buffers too!
GCC has no similar ability that I can find. It's probably not a big deal on the output side because that's not buffered. However, the input is buffered by interrupt-driven logic and GCC will not coexist with this. So some code to establish the GCC buffering and interrupt environment will be necessary as well as some code to reestablish the Robotis environment at completion time. I seriously doubt that the remote control processing will work without a bunch of new code too.
So with GCC it's a battle at every step but with ICCAVR the pieces just fall into place. It doesn't take long before the $99 solution looks compelling!
How to use Usb2Dynamixel to control 18 Ax 12 servos?
by MOHIT JINDAL
Wed Nov 17, 2010 4:32 am
can anyone tell me how i can program to control ax 12 servos from usb2dynamixel. Do you have a code to share it with me ? 
Mail me at mohitjindal_niit@yahoo.co.in
Mail me at mohitjindal_niit@yahoo.co.in
by Fritzoid
Wed Nov 17, 2010 12:04 pm
take a look at this page...
http://www.forestmoon.com/Software/DynaCommander/
You can also control a string of dynamixels through a CM-5 or CM-510 using Toss mode.
http://www.forestmoon.com/Software/DynaCommander/
You can also control a string of dynamixels through a CM-5 or CM-510 using Toss mode.
cm 500 board or Usb2dynamixel? Which is easy
by MOHIT JINDAL
Wed Nov 17, 2010 4:41 pm
Can you tell me what to use for controlling bioloid ? Cm 100 or Usb2dynamixel which is more easy programmable.
by Fritzoid
Wed Nov 17, 2010 5:22 pm
There are advantages and disadvantages to each method.
Programming a CM-10, CM-100, etc. by means of RoboPlus Task is the easiest way to control your dynamixel creation. RoboPlus is an embedded interpreter specifically designed to make controlling dynamixels fast and easy. However, there are limitations in both speed and functionality with using RoboPlus Task.
The big advantage of an embedded program like RoboPlus is that the robot can operate autonomously once programmed. If you go the USB2Dynamixel route then the robot must always be connected by an umbilical cord.
The programming for something like DynaCommander is done in Windows using C# which is a powerful and more general language than RoboPlus, but has a high learning curve. Unless you are already a wiz in Visual Studio it's gonna take a while to figure out the source code.
The big advantage of the USB2Dynamixel solution is that the code runs on your home computer at 2-4 Ghz. which is much faster than the poor CM-100 at only 16 Mhz.
Programming a CM-10, CM-100, etc. by means of RoboPlus Task is the easiest way to control your dynamixel creation. RoboPlus is an embedded interpreter specifically designed to make controlling dynamixels fast and easy. However, there are limitations in both speed and functionality with using RoboPlus Task.
The big advantage of an embedded program like RoboPlus is that the robot can operate autonomously once programmed. If you go the USB2Dynamixel route then the robot must always be connected by an umbilical cord.
The programming for something like DynaCommander is done in Windows using C# which is a powerful and more general language than RoboPlus, but has a high learning curve. Unless you are already a wiz in Visual Studio it's gonna take a while to figure out the source code.
The big advantage of the USB2Dynamixel solution is that the code runs on your home computer at 2-4 Ghz. which is much faster than the poor CM-100 at only 16 Mhz.
Can roboplus auto program ?
by MOHIT JINDAL
Fri Nov 26, 2010 9:35 am
When we make programs for bioloid it walks and moves.
Is there any way we move the bioloid parts and roboplus can make program itself ?
If any one of you saw uncle bob video in which he moves legs and roboplus record that movements and at last he press play button in roboplus !
Is there any way we move the bioloid parts and roboplus can make program itself ?
If any one of you saw uncle bob video in which he moves legs and roboplus record that movements and at last he press play button in roboplus !
by Fritzoid
Tue Nov 30, 2010 4:29 pm
You can't make a program but you can make a motion file that a program can run.
With RoboPlus Motion you simply release the torque on one or more servos using the lightbulb icon. Then move the servo(s) to the desired position and turn the torque back on. The new position(s) can then be saved in the position file using the left-point arrow.
This function is sometimes called catch-and-play named after the Robonova-1 RoboBasic program that does the same thing.
With RoboPlus Motion you simply release the torque on one or more servos using the lightbulb icon. Then move the servo(s) to the desired position and turn the torque back on. The new position(s) can then be saved in the position file using the left-point arrow.
This function is sometimes called catch-and-play named after the Robonova-1 RoboBasic program that does the same thing.