VC++2005 Servo problems

[arobo88]

Guys,

Does anyone have a VC++2005(8.0) servo project I can copy.
I can't seem to get XP VC++ running without link errors.
I have done the Setup in VC2005/2008 installation instructions
but no luck.

Thanks

arobo88

[mondy1]

I feel there is an extremely high learning curve going from robobasic or similar, to C++ in robotics. I'm struggling with sort of the same thing, I can't even get the programming environment up and running. I've previously got no c++ experience, but lots of perl and some python experience, and I guess I will manage eventually. My only hope is that I don't get fed up.

I am a bit annoyed at the community, as I think there is very little interest in sharing. I know there is got to be a lot of people out there with lots of experience in programming the roboard, but they all keep silent.

A simple environment set up "how to", and a simple program moving a servo would help a lot...

Well, I'll keep struggling, I'm stubborn SOB, and I'll make sure to share when I've got something useful. Sorry I can't be of any help to you.

Regards,
Mondy

[arobo88]

mondy1,

Thanks for you feedback. I share your opinion. In fact I have given up
on using the Roboard's I/O and Servo outputs. It is maybe a combination
of me not being a good enough programmer and the poor documentation
on the Roboard to date.

What I am doing is using the Roboards USB port to talk to the "ServoCenter 4.1 Controller Board". It is not the best solution, but
using the Roboards IO and servo ports under Visual C++ was to difficult.

I can have my Roboard talk servos and receive IO from the ServoCenter 4.1 USB board (which is very small) with visual basic or C++. It is easy and very well documented.

It is not the best solution but it is much less of a headache.

[mondy1]

Hi again arobo88,
I don't know if you have the same problem as me, but my first goal was to be able to successfully compile the roboRC example, so that I could begin with modifying this software.

It wasn't before today I was able to do this, due to wrong environment setup. To be able to compile the demo software, you'll need to:

Step 1: Install Microsoft Visual C++ 2008 Express.
Step 2: Install the Windows SDK for Windows Server 2008 and .NET Framework 3.5.

And apparently it needs to be in this order.

When opening the roboRC example after installation, the visual c++ asks you to convert it to 2008, answer yes to this. Then you are able to compile.

Regards.

[arobo88]

Mondy1,

Thanks for the assist!
I will give it a try.

arobo88

[PaulL]

This is a hobby for me, and I work on it when I can, sometimes I'm off this site for a few weeks, sometimes longer!

I am not a C++ guy, not even a C# guy, but I have spent a huge amount of time working with the C++ ROBOIO code to be able to understand what's going on, and have managed some capability from that from within .Net. Ultimately, if I ever end up doing any C++ work in my career, it will be in large part from the experience I got going through working with the RoboIO code, and learning how to do C++ versions of .Net things.

As I started in this, as I found the awesome product that is Roboard, I knew, seeing the C++ open source library, that I was in for a long road. Most guys that do embedded controllers, more directly working with hardware, generally don't bother with the VB or C# side of .Net. I have looked, I have checked out, and I have seen very few C# / VB .Net posts regarding Roboard. Seems some folks want to do that, but the "how" has been the issue. I'm working on it, in my spare time, as something I like to do, at my own slow pace, meaning NOT a job.

Unfortunately, as spectacular as Roboard is, for it to be spectacular comes at a price: it's complicated. Just moving one servo takes more than just a line or two of code, and is also impacted by choice of operating system, programming environment, personal opinions, lots of things. If you want to move several servos, it becomes more than just itterating what you've already done, you have to coordinate the movements. If you want to do something else at the same time, more complication. The system / application / code that manages this is the part that is tricky under XP. My posts should provide some info there..

I've managed to destroy a few key philosophies of the glory that is "managed code" in my efforts thus far, but at the end of the day, what I want is to run Roboard from .Net under Windows XP, and I don't care if my libraries are all "managed" or not, and I don't much care if I break certain general rules about how an application "should" behave- this is a dedicated PC, no different from a SCADA station running an assembly line- it only has to work. I work with .Net in my day job, and to be able to do the same with my hobby means that once I've got enough code there, I can be much more productive, and what I do at work or at home becomes very much the same type of thing.

Would I like to see someone post source for the perfect .Net / Roboard interface that's easy to use / program? Sure I would, would save me a lot of time and effort, but as I haven't seen that yet, I'm doing it myself, so some day, there will be one more "opinion" of how it can be done.

Take Care,
Paul

[roboard]

Would I like to see someone post source for the perfect .Net / Roboard interface that's easy to use / program? Sure I would, would save me a lot of time and effort, but as I haven't seen that yet, I'm doing it myself, so some day, there will be one more "opinion" of how it can be done.

Any opinion and suggestion for improving RoBoard's H/W & S/W is very welcome

RoBoard is our first attempt at improving robot controllers. Because it is a complete new product for us, we are working hard to build satisfiable H/W & S/W support of RoBoard. Every user feedback about RoBoard's H/W & S/W will be took into account and, if it is useful, will get respondences in future RoBoard S/W (or H/W) release.

[PaulL]

Hey Roboard,

I have a few I'll throw your way, as soon as I develop a clearer picture myself of what the .Net libraries should look like as a whole!

One of the kickers for me in the C++ arena is that I haven't had much luck directly integrating the C++ ROBOIO code in a way that multitasks in XP well via .Net, but I have replicated a good part of that functionality in VB.Net such that it does. Also, I was looking to modify the movement from .Net, not just saying "go from point X to point Y". I have this working, and can do XP's text-to-speech WHILE moving servos with accel / decel curves, updating each new set-position, with no lag or jitteriness in either. Walking and talking will be a reality!

Your product, the RB-100 is absolutely awesome. I've shown the guys at work, and they're simply amazed. It's exactly what I was looking for when I first got my RN-1 (though I had to wait a couple years for it!), and I thank you for bringing such a product to market. Some might be put off by the learning curve, but I know in time, as more people invest the time it truly takes to do this right, this hobby will take a number of leaps and bounds towards things we haven't even yet imagined due to the nature of your product. The thing that blows me away is, I know what custom hardware costs, and the price on the RB-100 is, well, just OUTSTANDING! And yes, I do intend to buy more!!!

I have a question, regarding the RB-110- will the RB-100 be phased out any time soon?

Thank You!
Paul

[roboard]

Hi RN1AsOf091407,

many thanks and love RoBoard family, the RB-100 and RB-110 will always available, no need to worry about phase issue.

[arobo88]

Guys,

Don't let my comments make anyone feel that I do not like my roboard. Sure its not easy and I had to do some unplanned work arounds, but bottom line is I plan to buy another one for my next project

arobo88

[PaulL]

Arobo,

No offense intended, but I know what posts like that can do for a specialized product such as this- I've seen it happen to other vendors for other hobbies, and a Roboard is just too special to let it fall by the wayside over a few negative posts. Technologically, Roboard is absolutely leaps and bounds above any ATMEGA, or any other embedded controller that has made it to this market. Software is the key, and it does take time. An interesting footnote, the MRC board in my RN-1 used to cost very close to what I can get a Roboard for- I'd love someone to explain that to me, why the embedded controller board costs so much in contrast with a PC-based solution that can do so much more. Long term, I don't have much hope for the embedded controller world, particularly due to over-specialization and the costs that that entails.

I absolutely encourage anyone with a Roboard to invest some time in working on software. I've been tempted to start a project on SourceForge, but I'm pretty stubborn when it comes to how I think something should be done. LOL!

But, one thing is clear to me, Robotics Studio, and every other MS attempt at the embedded world (PLC's, OLE, etc), all have fallen short of the mark in my book. Object models I've seen and have worked with aren't set up the way they really should be to address robotics properly. The gap to be bridged is between the die-hard embedded guys and the OO MS guys. IMHO, I don't think either truly understand each other, but I do think there are a rare few out there that can do both, and I think they also have answers. There's no reason to me why the programming methods applied to, say, a Kuka industrial robot, or a hobby servo-based robot such as ours, should be any different- we all want motion, in a certain way, and the difference really is in how some object model talks to the actual hardware. That interface layer should be such that a universal "go here" command translates to the appropriate movements given the driver layer for the device. Standardization is key, a unified means to handle movement. I think people over-complicate things in general. A Kuka has its own everything, and has little in common with servo moves like we want to do. Is it really all that different? My answer is absolutely not. And, with Roboard as a platform, there's even MORE reason for the differences to be fewer and fewer. What we do with our robots isn't so different from any industrial robot- we just happen not to expect as high a level of capability and performance. Oh, and we typically have more degrees of freedom... LOL!

If there was a more generic robotic control methodology, I think it would benefit both worlds, but I can say, I do have concern that the "money making" world of industrial robotics will fight tooth-and-nail to protect their "investments" in custom software packages they can sell to their customers for a mint. I'd like to see them taken down a notch or two, but that's me.

Take Care,
Paul