Roboard Experience...
by PaulL
Sun Sep 23, 2012 12:46 am
Well, I'm not thrilled with PWM performance on the Ardiuno Pro Micro / Leonardo (32U4). I love the board, it's handy and very cool, but it's just not the best thing for lots of PWM. And, to have I2C as well, that means only 10 PWM channels available. Two boards gets me the stock positions on the RN-1 plus hip and wrist servos - none left for the neck. In all, I'd need 3 boards just for the main body, not counting hands.
SO, I got a Maple Mini, which has 12 channels of hardware PWM - this should be exactly what I need to resolve the issues I'm having with PWM on the 32U4, and the board is so freakin' fast that it should do just about anything else offboard that I want. And, with 2 of these, that's 24 channels of PWM, meaning 20 for stock + hips + wrists with 4 left, and the most I can do for neck is 3 (fwd / back tilt, side / side tilt, rotation).
I still don't know what I'm going to do about hand controllers short of designing up some purpose-specific ARM Cortex 3 boards like the Maple Mini. I've fiddled with the Pololu Maestro board, and I just don't like the accel / decel on it. With the Maple Mini, I may be able to stream position updates to the Pololu boards fast enough to suit what I'm trying to do. I have my doubts if the 32U4 could handle that and servos.
In retrospect, it's ironic that for two Maple Mini's, the cost is around $70 USD from Sparkfun, whereas the MRC-3024 was some $300 USD at some point in the past.
For connecting the two Maple Mini's, I'm thinking of using I2C, and simply maintain timers in the I2C Master for move completion on the second board - this keeps me from polling the second board, or trying to work out some multi-master method between the two boards. Response time / latency for move completion will be better with this approach as well. Not sure what the hardware serial speed is on the Maple Mini, I need to look into that.
***
I keep debating on what to do, whether I want to just slap the audio boards and speakers on the gold RN-1 w/ Roboard and do a video demonstrating Speech / Voice Rec between moves, or keep going on offboard servo motion control so I can get to walking and talking at the same time.
At the moment, my long term goal is winning out, to get motion control offboard so he can talk while moving.
A side note, has anyone here done much with visimes? Visual cues for speech? I'm thinking of doing some head-nod / tilt, maybe some peculiar sideways head ticks or jerky rotations on certain types of sounds to add character...
SO, I got a Maple Mini, which has 12 channels of hardware PWM - this should be exactly what I need to resolve the issues I'm having with PWM on the 32U4, and the board is so freakin' fast that it should do just about anything else offboard that I want. And, with 2 of these, that's 24 channels of PWM, meaning 20 for stock + hips + wrists with 4 left, and the most I can do for neck is 3 (fwd / back tilt, side / side tilt, rotation).
I still don't know what I'm going to do about hand controllers short of designing up some purpose-specific ARM Cortex 3 boards like the Maple Mini. I've fiddled with the Pololu Maestro board, and I just don't like the accel / decel on it. With the Maple Mini, I may be able to stream position updates to the Pololu boards fast enough to suit what I'm trying to do. I have my doubts if the 32U4 could handle that and servos.
In retrospect, it's ironic that for two Maple Mini's, the cost is around $70 USD from Sparkfun, whereas the MRC-3024 was some $300 USD at some point in the past.
For connecting the two Maple Mini's, I'm thinking of using I2C, and simply maintain timers in the I2C Master for move completion on the second board - this keeps me from polling the second board, or trying to work out some multi-master method between the two boards. Response time / latency for move completion will be better with this approach as well. Not sure what the hardware serial speed is on the Maple Mini, I need to look into that.
***
I keep debating on what to do, whether I want to just slap the audio boards and speakers on the gold RN-1 w/ Roboard and do a video demonstrating Speech / Voice Rec between moves, or keep going on offboard servo motion control so I can get to walking and talking at the same time.
At the moment, my long term goal is winning out, to get motion control offboard so he can talk while moving.
A side note, has anyone here done much with visimes? Visual cues for speech? I'm thinking of doing some head-nod / tilt, maybe some peculiar sideways head ticks or jerky rotations on certain types of sounds to add character...
by PaulL
Sun Oct 07, 2012 5:03 am
My Arduino code is ported to the Maple Mini (some changes needed, but not too bad), and the code on the Maple Mini works GREAT! PWM works beautifully, no problems at all, as good as I get out of the Roboard via onboard PWM. Problems I had w/ Arduino Servo PWM are gone.
Awesome would be a smaller board with serial, I2C, and PWM broken out, USB available for programming, available without mounted headers.
Large quantities of GPIO really doesn't provide much benefit for 'bot controllers...
Pins for a "wish" Maple Mini Modified (STM32F103CBT6):
12 x PWM pins (and associated re-taskable purposes)
2 x Power pins (+V to regulator to chip / Gnd)
2 x Serial / I2C pins (tx3 / rx3 / I2C2)
That's a 16 pin device, with USB jack mounted on top, perfect for hardware interfacing to a PC. Other boards can be slaved to a main board that interfaces with the PC, expanding PWM as needed.
A few words about control systems / embedded concepts:
In the course of time, computers have grown from single-chip processors that do everything from video to bit-banged serial, to hybrid devices that today incorporate a central processor with purpose-specific processors attached to it that handle tedious and application-specific tasks (GPU's, drive controllers, hardware UART's etc). I believe this fundamental aspect of computer evolution has its place in hobby robotics: there is no reason to limit oneself to a single processor to do motion AND everything else.
I see an outboard motion controller as being no different from and analogous to a controller one can find in a printer. The main PC doesn't control nozzles in an inkjet printer, nor does it control the position of the print head, nor the stepper motor that advances the paper. Instead, the PC tells the printer what to do in macro terms (ex, print a line with these dots of xyz color). The printer's embedded controller ultimately handles the tedious task of printing, allowing the computer to carry on with anything else it is tasked to handle.
Why shouldn't hobby robotics take on a similar form? It makes sense to leave motion control up to a dedicated motion controller, but must that same controller run every other aspect of the 'bot at the same time? My thinking is, no. Now, all I need is my dream board. Meanwhile, the Maple Mini is VERY close.
Awesome would be a smaller board with serial, I2C, and PWM broken out, USB available for programming, available without mounted headers.
Large quantities of GPIO really doesn't provide much benefit for 'bot controllers...
Pins for a "wish" Maple Mini Modified (STM32F103CBT6):
12 x PWM pins (and associated re-taskable purposes)
2 x Power pins (+V to regulator to chip / Gnd)
2 x Serial / I2C pins (tx3 / rx3 / I2C2)
That's a 16 pin device, with USB jack mounted on top, perfect for hardware interfacing to a PC. Other boards can be slaved to a main board that interfaces with the PC, expanding PWM as needed.
A few words about control systems / embedded concepts:
In the course of time, computers have grown from single-chip processors that do everything from video to bit-banged serial, to hybrid devices that today incorporate a central processor with purpose-specific processors attached to it that handle tedious and application-specific tasks (GPU's, drive controllers, hardware UART's etc). I believe this fundamental aspect of computer evolution has its place in hobby robotics: there is no reason to limit oneself to a single processor to do motion AND everything else.
I see an outboard motion controller as being no different from and analogous to a controller one can find in a printer. The main PC doesn't control nozzles in an inkjet printer, nor does it control the position of the print head, nor the stepper motor that advances the paper. Instead, the PC tells the printer what to do in macro terms (ex, print a line with these dots of xyz color). The printer's embedded controller ultimately handles the tedious task of printing, allowing the computer to carry on with anything else it is tasked to handle.
Why shouldn't hobby robotics take on a similar form? It makes sense to leave motion control up to a dedicated motion controller, but must that same controller run every other aspect of the 'bot at the same time? My thinking is, no. Now, all I need is my dream board. Meanwhile, the Maple Mini is VERY close.
by i-Bot
Mon Oct 08, 2012 11:50 am
I would suggest the partitioning of a robot function like motion to a subcontroller is a compromise rather than an architectural objective, especially during the development phase of robotics. We already often have partioning of low level single joint control to the servo, and even this is demanding greater bus bandwidth to manage not just position, but also PID parameters, also to feedback even more motor data to achieve optimum movement and efficiency.
Robotis have moved away from having the motion engine in the subcontroller on DARwin to having it on the FitPC, so it can better implement kinematics to work in different space frames. Developers want to use Python, LUA or Matlab to develop their motion algorithms, not work on an embedded device.
As algorithms mature, I assume there will be a partioning and delegation of parts of the motion engine, but I would expect it to demand performance similar to graphics processors and significant bus bandwidth as the number of degrees of freedom increase and the sensory feedback grows.
But I can see it is a necessity in your case and the Maple and STM32 are great devices.
Robotis have moved away from having the motion engine in the subcontroller on DARwin to having it on the FitPC, so it can better implement kinematics to work in different space frames. Developers want to use Python, LUA or Matlab to develop their motion algorithms, not work on an embedded device.
As algorithms mature, I assume there will be a partioning and delegation of parts of the motion engine, but I would expect it to demand performance similar to graphics processors and significant bus bandwidth as the number of degrees of freedom increase and the sensory feedback grows.
But I can see it is a necessity in your case and the Maple and STM32 are great devices.
by PaulL
Mon Oct 15, 2012 12:35 am
Wow, someone actually reads this thread! I've been keeping this thread up mostly out of personal commitment, but it's nice to know someone is reading...
I've been giving some thought to your post, about kinematics processing and how it fits into the scheme of things.
Compromise, optimization, now we're just playing with words.
What this approach does is move high bandwidth / CPU motions off the Roboard (keeps Roboard from handling interpolation), but it doesn't deny the ability to stream motions for use with inverse kinematics / sensor feedback-controlled motions / etc.
It also offers some benefit turning something like an STM32 into a PWM interface. Then, any serial / USB / etc host can plug right in (I'm thinking Atom Z530). As there is no "standard" for servo controllers out there, I figured I'd try a different piece of hardware and method.
If the intent of inverse kinematics is a point in 3D space, this approach can facilitate this. Regarding kinematics, how fine a resolution is intended for a particular instance? Depending on the precision required, this approach could "fill in the gaps" between points, not necessarily a bad thing.
I think active inverse kinematics is overkill for taking a stroll around the house on a "large footed" bot, but this is my opinion. But, a sensor input saying "you're about to lose your balance" can interrupt and offset those rudimentary motions - not outside the capabilities of the STM32.
What we're really talking about is CPU load and priority of complex functions. If the intent is to experiment in the realm of kinematics, sure, you can do that on the RB-100 or other, and use the onboard PWM right on top of the Vortex86DX in whatever language makes you happy. If TTS and Voice Rec is needed, that's a good chunk of CPU (esp on Roboard), and doesn't quite leave enough room for motion to play without some sacrifice (ex, TTS / Voice Rec when standing still, off while moving).
This offboard control gives me options, and it doesn't quite take any away - I think that's a good thing. If I want to fiddle with kinematics and swamp the CPU, I can, and when I want to walk and talk, I can. This aspect of choice is what I think is key here. The heavy hitters are vision, kinematics, TTS / voice rec, and AI. Today, it's simply not possible to do all on the same small bot concurrently.
In people, there is a kind of "mode switch" regarding focus. If we're performing a delicate or unique motion, we focus, and we sometimes don't even talk while we're concentrating. This is possible with an offboard controller that can accept streamed position updates and does kinematics host-side. At the same time, many motions we make don't require concentration, and the same offboard controller can do the interpolation for similar types of motions, even using sensor feedback (gyro, accelerometer). There are other situations such as where we may be walking, but holding a glass of water, perhaps we can talk, perhaps we can't if the water is very near the rim of the glass. This controller approach supports this as well (interpolations + discrete position updates).
I agree regarding the complexity of kinematics / inverse kinematics. For the same reason GPU's exist, the same logically will eventually be true for kinematics (but practically will this be of benefit to semiconductor manufacturers? Maybe as an unintended application of gate arrays and the like).
I agree about the STM32, it's a very slick little processor. The 32U4 isn't bad, but the STM32 is a good bit better. I don't need all that GPIO, but what I really want is a pretty specialized board. For now, I'll just use the Maple Mini as-is. Waiting on Sparkfun to get them back in stock, I need a couple more.
Paul
I've been keeping this thread up mostly out of personal commitment, but it's nice to know someone is reading...
I've been giving some thought to your post, about kinematics processing and how it fits into the scheme of things.
Compromise, optimization, now we're just playing with words.
What this approach does is move high bandwidth / CPU motions off the Roboard (keeps Roboard from handling interpolation), but it doesn't deny the ability to stream motions for use with inverse kinematics / sensor feedback-controlled motions / etc.
It also offers some benefit turning something like an STM32 into a PWM interface. Then, any serial / USB / etc host can plug right in (I'm thinking Atom Z530). As there is no "standard" for servo controllers out there, I figured I'd try a different piece of hardware and method.
If the intent of inverse kinematics is a point in 3D space, this approach can facilitate this. Regarding kinematics, how fine a resolution is intended for a particular instance? Depending on the precision required, this approach could "fill in the gaps" between points, not necessarily a bad thing.
I think active inverse kinematics is overkill for taking a stroll around the house on a "large footed" bot, but this is my opinion. But, a sensor input saying "you're about to lose your balance" can interrupt and offset those rudimentary motions - not outside the capabilities of the STM32.
What we're really talking about is CPU load and priority of complex functions. If the intent is to experiment in the realm of kinematics, sure, you can do that on the RB-100 or other, and use the onboard PWM right on top of the Vortex86DX in whatever language makes you happy. If TTS and Voice Rec is needed, that's a good chunk of CPU (esp on Roboard), and doesn't quite leave enough room for motion to play without some sacrifice (ex, TTS / Voice Rec when standing still, off while moving).
This offboard control gives me options, and it doesn't quite take any away - I think that's a good thing. If I want to fiddle with kinematics and swamp the CPU, I can, and when I want to walk and talk, I can. This aspect of choice is what I think is key here. The heavy hitters are vision, kinematics, TTS / voice rec, and AI. Today, it's simply not possible to do all on the same small bot concurrently.
In people, there is a kind of "mode switch" regarding focus. If we're performing a delicate or unique motion, we focus, and we sometimes don't even talk while we're concentrating. This is possible with an offboard controller that can accept streamed position updates and does kinematics host-side. At the same time, many motions we make don't require concentration, and the same offboard controller can do the interpolation for similar types of motions, even using sensor feedback (gyro, accelerometer). There are other situations such as where we may be walking, but holding a glass of water, perhaps we can talk, perhaps we can't if the water is very near the rim of the glass. This controller approach supports this as well (interpolations + discrete position updates).
I agree regarding the complexity of kinematics / inverse kinematics. For the same reason GPU's exist, the same logically will eventually be true for kinematics (but practically will this be of benefit to semiconductor manufacturers? Maybe as an unintended application of gate arrays and the like).
I agree about the STM32, it's a very slick little processor. The 32U4 isn't bad, but the STM32 is a good bit better. I don't need all that GPIO, but what I really want is a pretty specialized board. For now, I'll just use the Maple Mini as-is. Waiting on Sparkfun to get them back in stock, I need a couple more.
Paul
by PaulL
Wed Jan 02, 2013 9:33 am
I found a nice bit of software, http://www.visualmicro.com. It's a plugin that lets you do Arduino code in the Visual Studio IDE.
As Arduino isn't perfectly compatible with Maple, some changes will be needed, but I much prefer the VS IDE.
I've been slowly working on the method and code to use Maple Mini's for servo control - it's getting there. Work came first, past few months were pretty hectic.
I'm sold on the main board I'm going to use: Kontron's PicoITX based on an Intel Atom Z530, the 1.6 Ghz Standard (not the Plus, that has an IDE connector projecting off the side). It's a tad too wide, but I think I can make it work. If I had a bigger bot, it would be less of an issue, but I don't know if I'd have ended up with a different solution... Maybe FitPC2, maybe not.
I looked into other boards, some with faster CPU's and such, but this remains the winner.
As Arduino isn't perfectly compatible with Maple, some changes will be needed, but I much prefer the VS IDE.
I've been slowly working on the method and code to use Maple Mini's for servo control - it's getting there. Work came first, past few months were pretty hectic.
I'm sold on the main board I'm going to use: Kontron's PicoITX based on an Intel Atom Z530, the 1.6 Ghz Standard (not the Plus, that has an IDE connector projecting off the side). It's a tad too wide, but I think I can make it work. If I had a bigger bot, it would be less of an issue, but I don't know if I'd have ended up with a different solution... Maybe FitPC2, maybe not.
I looked into other boards, some with faster CPU's and such, but this remains the winner.