PDA

View Full Version : Humanoid control with C#



kbv2842
07-28-2007, 03:26 PM
Hi everyone,

I have bought 2 pieces of the "Bioloid Comprehensive Kit" from Trossen Robotics! I am working on the Humanoid robot that comes with the kit. The provided softwares that come with the kit are the "behavior control program" and the "motion editor". I am trying to make a C# windows project that can control the bioloid's motion. Initially, I made a C# windows application for the pan and tilt robot. The window has a drag bar where I can move the pan and tilt motors. But as soon as the program finishes sometimes one of the ID's of the motor crashes and the ID has to be reset. I don't know what's happening. I would want to know has anyone worked on the humanoid and successfully implemented a C# code on it.

I would be grateful to anyone who can share on this topic. I have been searching this forum forever :rolleyes:

Alex
07-28-2007, 11:34 PM
how'd ya implement a C# app with the Bioloid system? Are you using the CM5 module? Did you create a wrapper around the motion sequences or did you start from the ground up and create a wrapper of all the individual controls/recieve actions? Could you paste or attach the code you're using?

We've started playing around with the USB to Dynamixel adapter and Crustcrawler's wrapper, but there's still some work that needs done to bring it to the full potential.

At any rate, Jon Hylands has done some pretty incredible work with the Bioloid system. I thought he also created a .NET wrapper of the motion sequences, but I can't seem to find it right now. Here's his Bioloid Wiki:

http://www.bioloid.info/tiki/tiki-index.php

kbv2842
07-31-2007, 10:54 AM
Thanks for you quick reply. I found Jon Hylands blog here (http://www.huv.com/blog/2007_01_01_archive.html).
I implemented the Bioloid through the CM5 module that came with the Comprehensive Kit. I could have wrapped around existing sequences but this would not allow the freedom of control that I would need later. I talk through serial, when the CM5 is set to 'Manage Mode'. Heres a snippit of code that I use for controlling the position of each servo:
private void MoveServo(byte channel, short position, short speed)
{
//Set current servo
this.comPort.WriteLine("CID " + channel);

//Set servo position
this.comPort.WriteLine(String.Format("Go {0:x3} {1:x3}", position, speed));
}
This pretty much translates terminal-wize to:
CID <Servo>
GO <Position> <Speed>
The problem that happens over time is that eventually one of the servos' ID gets lost or reset to that of another servo connected. The fix currently is to unplug all other servos and send the 'ID <#>' command to reset all currently connected servos to a paticular id. Could sending CID / GO commands too fast for the serial bus be causing problems?
My thought to fix this is to not use the CID / GO command pair, but to directly call a 'WRITE' command that moves a paticular servo, but this is unknown as to whether this will help solve the problem.

Alex
07-31-2007, 02:23 PM
What version of C# are you using?

Could you perhaps zip your code up and attach it to a post? If it's too large, just email it to me directly.

kbv2842
07-31-2007, 05:13 PM
Hi!

I just shifted my Bioloid program over to a 32 bit system from a 62 bit system. And I think that was creating the error!? So far on the 32 bit system, program is running without crashing.


I have attached the file here:
43

Thanks...:o

Alex
08-01-2007, 10:02 AM
ah! I never even thought to ask if you were running a 64 bit system. I've had a lot of problems running C# apps on 64 bit systems:(

I'm glad to hear everything is working out though. The program looks pretty straight forward, thanks for including it!

Keep us posted with your progress! If you were interested, we might just want to host the project for you in our Bioloid pages when you're finished with it. We've been wanting to see someone to develop a .NET interface for the Bioloid system ever since it first came out:)

If you hit any other road blocks and/or have some development questions about programming, architecture, etc., don't hesitate to ask! My specialty is C#, so I should be able to help you out quite a bit.

fish123456
11-30-2007, 01:44 PM
Just a general question: I noticed in your code, you do this at the beginning of each Form:

this.CheckForIllegalCrossThreadCalls = false;

Are you doing this for any specific reason? I don't even see how you have multiple threads running. Was this just an attempt at making your code not break?

I'm a C# guy, too, and I have never seen anyone set that to false.

Edit: I know nothing about the Bioloid, just thought I would check out your code!

kbv2842
12-29-2007, 12:49 PM
we do that because some of our helper classes need to change properties on the main form, which fires events from the users thread. basically .NET won't let other processes modify the user's gui without properly-invoking the method, this is simply a coding shortcut :wink:- but probably not the best for coding standards :rolleyes:. it helps keep the code readable also during development as it seems unnecessary to me to have a lot of "proper" invokes to delegates on callback functions :veryhappy:. i am sorry for the late reply, got crunched up...

fish123456
12-29-2007, 05:39 PM
we do that because some of our helper classes need to change properties on the main form, which fires events from the users thread. basically .NET won't let other processes modify the user's gui without properly-invoking the method, this is simply a coding shortcut :wink:- but probably not the best for coding standards :rolleyes:. it helps keep the code readable also during development as it seems unnecessary to me to have a lot of "proper" invokes to delegates on callback functions :veryhappy:. i am sorry for the late reply, got crunched up...

OK, I was just wondering. Certainly not a good practice, and very akin to how VB 6 allows you to do that. I was worried that your problems may have been related. I know that in .NET 1.1 you could get away with doing UI updates from outside the UI thread, and sometimes it worked, sometimes it threw an exception. Now with .NET 2.0, you get an exception regardless, which I think is a definite improvement. Anyway, I would imagine that if you set that property to false, you could end up with the same problems in .NET 1.1.