Roboard Experience...
by Spiked3
Sun Dec 19, 2010 4:50 pm
Lab View drives the Lego NXT visual programming environment. I do not know if you mentioned that or not, but yeah, they are pressing in that direction some. also Microsoft MRDS is badly out of date. MRDS was more of an experiment to develop .Net improvements, that covered many disciplines, including robotics. Look at the new Async keywords in .Net and TPL, a messaging workflow pattern based on the parallel libs for .Net. Personally, I would not do anything new that uses MRDS. Whether or not VPL (part of MRDS) is revised, I have not seen any indication one way or another.
On a slightly different note, as I mentioned in another thread, i recently went through a stroke and I am having a hell of a time doing things that used to be real easy for me. Have you had any luck getting the roboboard software to work with visual studio 2010? Ive spent a week on it without success on just getting a program to run (dll name mismatches, pre-compiled header issues etc). I really do not want to install the old compiler to get this working.
On a slightly different note, as I mentioned in another thread, i recently went through a stroke and I am having a hell of a time doing things that used to be real easy for me. Have you had any luck getting the roboboard software to work with visual studio 2010? Ive spent a week on it without success on just getting a program to run (dll name mismatches, pre-compiled header issues etc). I really do not want to install the old compiler to get this working.
by PaulL
Fri Dec 31, 2010 8:43 pm
Spiked, Yah, I mentioned that in there somewhere. 
Re MSRDS, it's not that I want to use the technology in MSRDS, but if I create a UI that is very SIMILAR to theirs (as in VPL), I shouldn't have any problems with NI. Their style of front end, my engine behind it all.
I'm sorry to hear about the stroke, and I hope you recover as much as possible. Check your PM's.
I am not using the RoboIO code, I've been rewriting the functionality in VB.Net as I go. I've tested what I've written in VS 05, and VS 08, I have VS 2010, but it won't change how the code works, as it's mostly .Net native.
Take Care,
Paul
Re MSRDS, it's not that I want to use the technology in MSRDS, but if I create a UI that is very SIMILAR to theirs (as in VPL), I shouldn't have any problems with NI. Their style of front end, my engine behind it all.
I'm sorry to hear about the stroke, and I hope you recover as much as possible. Check your PM's.
I am not using the RoboIO code, I've been rewriting the functionality in VB.Net as I go. I've tested what I've written in VS 05, and VS 08, I have VS 2010, but it won't change how the code works, as it's mostly .Net native.
Take Care,
Paul
Project Status...
by PaulL
Sat Jan 29, 2011 2:00 pm
I've put this aspect off for a while, as I needed to figure out the architecture for a decent motion sequencer engine that satisfies my intentions. I didn't want to do frame-based motion, but it IS easier to do. I needed to find a better way, but for some reason found myself as being my own worst enemy. I couldn't see through to the answer, but I believe I now have an approach:
Each servo class instance, representing one servo, separate from all others, will contain a "motion stack" of discrete moves, initialized on start of some desired motion sequence. Each motion object in the stack will expose "allowed" interrupt modes for itself, such as "uninterruptable", "halt", "decel and halt", "correct", etc. This will allow moves that require uninterrupted operation to not be interrupted. Exceptions for altering motions will be based on current state of all servos that are part of a motion sequence. The motion exception will be "queued", such that moves that must complete do. A move sequence will not be complete until the last servo participating in the sequence has finished moving.
This approach is exactly what I want, the ability to utilize preconfigured moves, but have the ability to change motion when possible, and to allow other sequences to run concurrently if requiring a set of servos not partcipating in another move.
For example, if he's walking, and some event occurs that requires his head to turn, I can invoke head-turn moves while he is walking. If he performs some sequence with one hand, the other hand is free to participate in some other sequence.
This approach allows me to avoid inverse kinematics for now, as I can keep him from falling due to conflicting motions that upset balance by setting allowed exception modes for moves that prevent motion-critical moves from being altered and making him unbalanced.
Further, an exception mode can be set up to actually drive a "completion" move, for example, revert to a standing position from a walk upon move interruption.
As I'm using RDTSC to time motion, no "drift" will be realized in servo moves being specific to the servo class instances, as all servo functions are initiated with the same timestamp, and all durations are based on the same timing mechanism.
This architecture is relatively complex in comparison with frame-based motion, but appears to be the best solution for what I want out of the system.
As for other project aspects:
* Sound Card board design needs finishing (not much to do there), but I will likely just go with a prototyping area for amps and preamps and an audio steering circuit. I will be having Sunstone to make the boards.
* Hand design is more or less complete, and I need to see about the cost of a machine shop doing the rest of the work for me for time's sake. I may also have a fab shop make the thrust bearing assemblies for wrist and hip joints and related brackets, again, for the sake of time.
The neck motion design is the hardest part, as I need a universal joint that has a short length, with a hole through the middle for wiring. I don't want to push his head up a half inch, so the design needs to be low profile. With the battery butting up against the top plate, there's no room inside for the neck mechanism. It needs to be about a quarter inch tall, with front / back / side-to-side tilt, and head rotate. It can't protrude into the head, as that's where the camera will go. The USB camera will go in the head, so the mechanism can't extend into the head. Wires must pass into the head for microphones and USB camera. The micro servos to control the motion will be located elsewhere, with pushrods or fine vinyl-coated wire moving the mechanism. I can draw a picture of what I want, but the issues are manufacturability, strength of materials, and play in the mechanism. At the moment, I can see no clear solution for this.
Otherwise, I need a small enough USB camera to fit in the head. I have considered internal USB laptop boards, but the camera itself will need to be relocated, with wires extended - not sure how much trouble this will cause, and then there's the issue of non-MMX drivers required with the Vortex86.
I'm still debating on how far to go with power management and using DC to DC converters with digitally controlled output. Heat, space, and weight are my concerns in this area.
I won't be ready to thermoform new chest and back plates until I have all the functional hardware in place, this will be the last aspect I address.
But, of course, there's software, which I view as the most critical aspect to the entire project.
Software Status Update:
I have the main sequencer engine useable (recently rewritten for even better performance), I have the servo manager and servo class with accel/decel/etc working properly, the register manager is operational, the text-to-speech and voice recognition class is useable, and the GUI configuration tool for configuring the main sequencer is in progress.
I need to write:
SPI interface class, I2C interface class, ADC class, and Motion Sequencer class. Of course, there are a few simpler classes, like accelerometer, digital compass, etc, but these are straightforward.
The amount of effort required for software is high, and mechanics are something I can't seem to find time for. At some point in any project, one must ask, which is a more appropriate resource to utilize - time, or money? My answer at the moment is Time for software, and Money for hardware.
Today, I'm going to be focusing on the motion sequencer, as I finally have what I believe is an appropriate architecture for that. Woohoo!
Take Care,
Paul
Each servo class instance, representing one servo, separate from all others, will contain a "motion stack" of discrete moves, initialized on start of some desired motion sequence. Each motion object in the stack will expose "allowed" interrupt modes for itself, such as "uninterruptable", "halt", "decel and halt", "correct", etc. This will allow moves that require uninterrupted operation to not be interrupted. Exceptions for altering motions will be based on current state of all servos that are part of a motion sequence. The motion exception will be "queued", such that moves that must complete do. A move sequence will not be complete until the last servo participating in the sequence has finished moving.
This approach is exactly what I want, the ability to utilize preconfigured moves, but have the ability to change motion when possible, and to allow other sequences to run concurrently if requiring a set of servos not partcipating in another move.
For example, if he's walking, and some event occurs that requires his head to turn, I can invoke head-turn moves while he is walking. If he performs some sequence with one hand, the other hand is free to participate in some other sequence.
This approach allows me to avoid inverse kinematics for now, as I can keep him from falling due to conflicting motions that upset balance by setting allowed exception modes for moves that prevent motion-critical moves from being altered and making him unbalanced.
Further, an exception mode can be set up to actually drive a "completion" move, for example, revert to a standing position from a walk upon move interruption.
As I'm using RDTSC to time motion, no "drift" will be realized in servo moves being specific to the servo class instances, as all servo functions are initiated with the same timestamp, and all durations are based on the same timing mechanism.
This architecture is relatively complex in comparison with frame-based motion, but appears to be the best solution for what I want out of the system.
As for other project aspects:
* Sound Card board design needs finishing (not much to do there), but I will likely just go with a prototyping area for amps and preamps and an audio steering circuit. I will be having Sunstone to make the boards.
* Hand design is more or less complete, and I need to see about the cost of a machine shop doing the rest of the work for me for time's sake. I may also have a fab shop make the thrust bearing assemblies for wrist and hip joints and related brackets, again, for the sake of time.
The neck motion design is the hardest part, as I need a universal joint that has a short length, with a hole through the middle for wiring. I don't want to push his head up a half inch, so the design needs to be low profile. With the battery butting up against the top plate, there's no room inside for the neck mechanism. It needs to be about a quarter inch tall, with front / back / side-to-side tilt, and head rotate. It can't protrude into the head, as that's where the camera will go. The USB camera will go in the head, so the mechanism can't extend into the head. Wires must pass into the head for microphones and USB camera. The micro servos to control the motion will be located elsewhere, with pushrods or fine vinyl-coated wire moving the mechanism. I can draw a picture of what I want, but the issues are manufacturability, strength of materials, and play in the mechanism. At the moment, I can see no clear solution for this.
Otherwise, I need a small enough USB camera to fit in the head. I have considered internal USB laptop boards, but the camera itself will need to be relocated, with wires extended - not sure how much trouble this will cause, and then there's the issue of non-MMX drivers required with the Vortex86.
I'm still debating on how far to go with power management and using DC to DC converters with digitally controlled output. Heat, space, and weight are my concerns in this area.
I won't be ready to thermoform new chest and back plates until I have all the functional hardware in place, this will be the last aspect I address.
But, of course, there's software, which I view as the most critical aspect to the entire project.
Software Status Update:
I have the main sequencer engine useable (recently rewritten for even better performance), I have the servo manager and servo class with accel/decel/etc working properly, the register manager is operational, the text-to-speech and voice recognition class is useable, and the GUI configuration tool for configuring the main sequencer is in progress.
I need to write:
SPI interface class, I2C interface class, ADC class, and Motion Sequencer class. Of course, there are a few simpler classes, like accelerometer, digital compass, etc, but these are straightforward.
The amount of effort required for software is high, and mechanics are something I can't seem to find time for. At some point in any project, one must ask, which is a more appropriate resource to utilize - time, or money? My answer at the moment is Time for software, and Money for hardware.
Today, I'm going to be focusing on the motion sequencer, as I finally have what I believe is an appropriate architecture for that. Woohoo!
Take Care,
Paul
by Spiked3
Sat Jan 29, 2011 4:13 pm
good stuff, good luck.
One thing I saw a while back was some servos that where circular. This allowed them to run wires up the middle and worked much better as robotic joints compared to the servos we are used to. I've since lost track of them and haven't been able to find them again, although i am sure they were patented and expensive (industrial robot type stuff). but it gives you something to think about if fabricating is something you have access to. I think i mentioned it was something I was planning before (fabrication), not sure now.
The other thing I wonder about is avoiding reverse kinematics. part of me wants to believe that should be sought, not avoided - but i haven't learned enough yet to know. I picture in my head a UI where moving one thing is much simpler than a whole mechanical assembly, 1 joint at a time.
The mechanics of the neck is a fine example of why servos suck. How about the I2C cam for the legos? close enough to what you want? http://www.mindsensors.com/index.php?mo ... PAGE_id=78
One thing I saw a while back was some servos that where circular. This allowed them to run wires up the middle and worked much better as robotic joints compared to the servos we are used to. I've since lost track of them and haven't been able to find them again, although i am sure they were patented and expensive (industrial robot type stuff). but it gives you something to think about if fabricating is something you have access to. I think i mentioned it was something I was planning before (fabrication), not sure now.
The other thing I wonder about is avoiding reverse kinematics. part of me wants to believe that should be sought, not avoided - but i haven't learned enough yet to know. I picture in my head a UI where moving one thing is much simpler than a whole mechanical assembly, 1 joint at a time.
The mechanics of the neck is a fine example of why servos suck. How about the I2C cam for the legos? close enough to what you want? http://www.mindsensors.com/index.php?mo ... PAGE_id=78
by PaulL
Sat Jan 29, 2011 10:09 pm
Thanks! I've seen ring-type rotary tables, and those are very pricey, and much larger. Can't recall anything miniaturized... In miniaturizing something like the neck mechanism, the problem I have is that I want him to still be able to do headstands without breaking something. I don't want to add 3 full-sized servos for motion, that'd be way too much, so it has to be micros. Using micro servos which don't have a pile of torque, the mechanism needs to give just before the servo gears break or holding torque is exceeded, which I will try to do in the linkages to the mechanism.
What I have in mind is a bearing at the base mounted to the top plate of the chassis, with a universal joint where the bottom half is fixed in the bearing, and top half is fixed to the head - this gives the head rotation axis. For tilt, a swashplate would be attached to the top half of the universal joint, allowing tilt fwd / back / left / right. I've considered running wires out the bottom / back of his head, as his head will rotate 180, and tilt something like 30 degrees in any direction. There isn't much room to work, though.
Regarding kinematics, it's a very systemic approach to motion, and from a higher level, yes, as you say, it would be simpler to set an intended end point in 3D space than to set multiple servo positions. I think kinematics or not boils down to how you want the bot to function in the end, and what your focus is in robotics. I've read enough about inverse kinematics to know it's not something I personaly want to focus on.
From a higher level, I want to provide a more simple interface, one that is more explicit than implicit regarding desired movements. I think inverse kinematics would be more appropriate for more analog types of interactions - the only analogy I can think of at the moment would be that of dance, ballet versus disco.
With inverse kinematics, more than one solution can be realized (such as a multi-axis arm reaching a point in 3D space), but I'm really only looking for the end result.
To explain a bit further, I want to experiment with AI, and let him "figure out" what works and what doesn't. For example, "If you reach out in front of you with both hands, and lean forward, and fall on your face, then you shouldn't do that again.". I will give him the ability to adjust his motions and realize the results, much as we humans learned to walk - by falling over, many times. But, I'll start him off with what I know works, and let him improve on that.. Call it "hand-holding", if you will.
I checked out that camera, it's bigger than I'm looking for, I can tell from the lego pieces (I know lego's pretty well..). I need something that fits inside an RN-1's head. He will get a clear visor to see through. It's a tight fit in there. I know the camera devices exist that are small enough, but finding one with an equally small interface board has been tough. Perhaps the best solution is to just buy a few internal laptop cameras and USB webcams and experiment with extending the camera wiring to the interface board.
I still at this point have no clue what his runtime will be like, even with the 2200 mAh lipo. Probably short, but I hope not too short. If it's unacceptably short, this will probably cause me to further persue the DC-to-DC converter power management aspect. I will almost certainly use the DC-to-DC converters for dropping from 7.4v of the LiPo to 6v, the question is in how many I will need and whether or not I will set them up to be digitally adjustable (optocoupler, digital potentiometer, etc).
More info...
In my servo class, I haven't incorporated position feedback as an "always available" function. At first, I thought reading servo position would be useful, but I've since thought it to be unnecessary. You can't measure force using position feedback, all position feedback can really do is tell you a servo's position from a "limp" servo. However, if you measure power consumption, you CAN deduce force. Reading position, IMHO, is only truly useful at power up, or in a "capture" mode for creating new poses. Viewing servos as their human equivalents, they are just muscles.
SOMETHING FOR EVERYONE:
Regarding inverse kinematics, let's do a practical experiment. Ready? With your hands starting at the keyboard, raise your hands a bit, and touch the index finger, middle finger, and thumb together on one hand, and touch the tips of these 3 fingers to the palm of the other. Repeat. Note the position of your elbow. Now, do the same, but don't just touch this time, push really hard, lots of force. Where is your elbow now? Why wasn't it in this position with just a touch? Desired result is the difference - a touch versus a push. Same end motion, but different motion in the middle. Try varying levels of pressure, note how your elbow's position changes with intended force. Think about turning a screwdriver or a thumbscrew that is being stubborn - does your elbow change position? Why does your elbow's position change? How did you learn to do this?
Ok, one more practical test, more about sensors and motors. Fold your arms, then unfold your arms and reach out with one finger and press the Y key on your keyboard. Simple enough. Do it a few more times, and think about where your muscles position your arms throughout the movement. Now, close your eyes and repeat. With my eyes closed, I keep hitting "U" for some reason. Our muscles don't give us feedback, they just do. We humans can only vaguely get it close on muscle control alone. Now, try with your eyes open to do it faster. Faster. Faster! Me, I move quickly out, then pause before I press the key when I'm sure I'm at the key. Sensors.
We use our eyes for everything, in this case, for motion feedback. We have crappy muscle control. But, our robots are quite good at positioning via muscle control. If we were as good as our robots at moving muscles, we could do a number of things without having to observe ourselves to be successful. With that, our robots don't NEED to sense their motion, or their balance in order to, for example, walk. Our own responses are very reactionary, depending on senses to fine tune the results.
In my project, I seek to take advantage of the fact that my robot doesn't need a pile of sensory feedback or kinematics algorithms to move in a way that produces the desired result. But then, I wouldn't discourage anyone else from heading down that path if they so choose!
I've seen ring-type rotary tables, and those are very pricey, and much larger. Can't recall anything miniaturized... In miniaturizing something like the neck mechanism, the problem I have is that I want him to still be able to do headstands without breaking something. I don't want to add 3 full-sized servos for motion, that'd be way too much, so it has to be micros. Using micro servos which don't have a pile of torque, the mechanism needs to give just before the servo gears break or holding torque is exceeded, which I will try to do in the linkages to the mechanism.
What I have in mind is a bearing at the base mounted to the top plate of the chassis, with a universal joint where the bottom half is fixed in the bearing, and top half is fixed to the head - this gives the head rotation axis. For tilt, a swashplate would be attached to the top half of the universal joint, allowing tilt fwd / back / left / right. I've considered running wires out the bottom / back of his head, as his head will rotate 180, and tilt something like 30 degrees in any direction. There isn't much room to work, though.
Regarding kinematics, it's a very systemic approach to motion, and from a higher level, yes, as you say, it would be simpler to set an intended end point in 3D space than to set multiple servo positions. I think kinematics or not boils down to how you want the bot to function in the end, and what your focus is in robotics. I've read enough about inverse kinematics to know it's not something I personaly want to focus on.
From a higher level, I want to provide a more simple interface, one that is more explicit than implicit regarding desired movements. I think inverse kinematics would be more appropriate for more analog types of interactions - the only analogy I can think of at the moment would be that of dance, ballet versus disco.
With inverse kinematics, more than one solution can be realized (such as a multi-axis arm reaching a point in 3D space), but I'm really only looking for the end result.
To explain a bit further, I want to experiment with AI, and let him "figure out" what works and what doesn't. For example, "If you reach out in front of you with both hands, and lean forward, and fall on your face, then you shouldn't do that again.". I will give him the ability to adjust his motions and realize the results, much as we humans learned to walk - by falling over, many times.
But, I'll start him off with what I know works, and let him improve on that.. Call it "hand-holding", if you will.
I checked out that camera, it's bigger than I'm looking for, I can tell from the lego pieces (I know lego's pretty well..
). I need something that fits inside an RN-1's head. He will get a clear visor to see through. It's a tight fit in there. I know the camera devices exist that are small enough, but finding one with an equally small interface board has been tough. Perhaps the best solution is to just buy a few internal laptop cameras and USB webcams and experiment with extending the camera wiring to the interface board.
I still at this point have no clue what his runtime will be like, even with the 2200 mAh lipo. Probably short, but I hope not too short. If it's unacceptably short, this will probably cause me to further persue the DC-to-DC converter power management aspect. I will almost certainly use the DC-to-DC converters for dropping from 7.4v of the LiPo to 6v, the question is in how many I will need and whether or not I will set them up to be digitally adjustable (optocoupler, digital potentiometer, etc).
More info...
In my servo class, I haven't incorporated position feedback as an "always available" function. At first, I thought reading servo position would be useful, but I've since thought it to be unnecessary. You can't measure force using position feedback, all position feedback can really do is tell you a servo's position from a "limp" servo. However, if you measure power consumption, you CAN deduce force. Reading position, IMHO, is only truly useful at power up, or in a "capture" mode for creating new poses. Viewing servos as their human equivalents, they are just muscles.
SOMETHING FOR EVERYONE:
Regarding inverse kinematics, let's do a practical experiment. Ready? With your hands starting at the keyboard, raise your hands a bit, and touch the index finger, middle finger, and thumb together on one hand, and touch the tips of these 3 fingers to the palm of the other. Repeat. Note the position of your elbow. Now, do the same, but don't just touch this time, push really hard, lots of force. Where is your elbow now? Why wasn't it in this position with just a touch? Desired result is the difference - a touch versus a push. Same end motion, but different motion in the middle. Try varying levels of pressure, note how your elbow's position changes with intended force. Think about turning a screwdriver or a thumbscrew that is being stubborn - does your elbow change position? Why does your elbow's position change? How did you learn to do this?
Ok, one more practical test, more about sensors and motors. Fold your arms, then unfold your arms and reach out with one finger and press the Y key on your keyboard. Simple enough. Do it a few more times, and think about where your muscles position your arms throughout the movement. Now, close your eyes and repeat. With my eyes closed, I keep hitting "U" for some reason.
Our muscles don't give us feedback, they just do. We humans can only vaguely get it close on muscle control alone. Now, try with your eyes open to do it faster. Faster. Faster! Me, I move quickly out, then pause before I press the key when I'm sure I'm at the key. Sensors.
We use our eyes for everything, in this case, for motion feedback. We have crappy muscle control. But, our robots are quite good at positioning via muscle control. If we were as good as our robots at moving muscles, we could do a number of things without having to observe ourselves to be successful. With that, our robots don't NEED to sense their motion, or their balance in order to, for example, walk. Our own responses are very reactionary, depending on senses to fine tune the results.
In my project, I seek to take advantage of the fact that my robot doesn't need a pile of sensory feedback or kinematics algorithms to move in a way that produces the desired result. But then, I wouldn't discourage anyone else from heading down that path if they so choose!
by robaldo
Sun Feb 06, 2011 7:33 am
does anybody have the same experience like this http://robosavvy.com/forum/viewtopic.php?t=6975
please help me if you know what to do!
please help me if you know what to do!
by robaldo
Sun Feb 06, 2011 8:01 pm
RN1AsOf091407 wrote:Do Start / Run, and type "cmd" and click OK.
Type:
ipconfig /all > c:\ip.txt
(press return)
start c:\ip.txt
(press return)
Copy text from notepad and paste here.
my rb110 is at university and not available now
but i know that the physical address has set to FF FF FF FF FF
i think this is the problem!
by Spiked3
Sun Feb 06, 2011 8:43 pm
robaldo wrote:my rb110 is at university and not available now
but i know that the physical address has set to FF FF FF FF FF
i think this is the problem!
Yep, that is a problem - see here; http://robosavvy.com/forum/viewtopic.php?t=6372
the company will have to send you a program to fix it.
by robaldo
Sun Feb 06, 2011 8:51 pm
Spiked3 wrote:robaldo wrote:my rb110 is at university and not available now
but i know that the physical address has set to FF FF FF FF FF
i think this is the problem!
Yep, that is a problem - see here; http://robosavvy.com/forum/viewtopic.php?t=6372
the company will have to send you a program to fix it.
i have emailed tech@roboard.com
but there is no response!
by robaldo
Mon Feb 07, 2011 9:39 pm
Spiked3 wrote:it looks like today, the 6th was the first you mentioned the FF FF ... hardware ID - up until then your problem was anyone's guess. remember the time zone difference and give them a bit to respond - they always seemed to try and help when they can.
one day is left!
and there was no reply from Roboard!
I'm waiting! I'm in hurry!
does anybody know what to do?
by robaldo
Tue Feb 08, 2011 8:37 pm
roboard wrote:robaldo wrote:one day is left!
and there was no reply from Roboard!
I'm waiting! I'm in hurry!
does anybody know what to do?
Sorry for reply late. 2/2~2/7 are Chinese New Year vacation. Our service shall reply your email soon.
thanks
my problem was solved by your reply!