Roboard Experience...

[PaulL]

Ok, strange- I've tried twice to post that code, and both times it gets botched partway through- code is simply dropped from the listing. I don't get it! UGH! Some of it is there, but not all of it. A few functions / lines are completely obliterated when posting. UGH!

[PaulL]

Well, I understand what the code posting problem is, the forum doesn't like seeing the < <and> > bit shift operators in the code. Ugh! Anyone got a suggestion for me to post code here on RoboSavvy?

[veltrop]

I don't seem to have a problem using the [ code ] [ / code ] blocks with greater/less than.

Code: Select all

char test=0x55>>5;
test = test << 2;
if (test < 0x55) {}
myobj1 <myobj2<float>> o;
>
<
>>
<<


[PaulL]

You're right, it's not using < <and> >. It's a little different:

Do this char sequence:

less than Symbol
the word test1
space
the word test2
greater than Symbol

You get only "Test1"!!! Even with code tags. UGH!

Code: Select all

<test1>

[veltrop]

Your right. Very strange indeed!

[PaulL]

I finished up debugging code, and a major concern was alleviated - I can update motors and utilize speech without motor stumbling due to XP timing issues. He will be able to walk and talk at the same time under Windows XP.

New batteries arrived yesterday, and the 2200mA batteries fit inside my RN-1 nicely. I also managed to finish installing a "blue bracket set". I like the blue brackets so much better than the orange / gold.

I did however notice an issue, moving just two servos at the same time at high speeds rebooted the Roboard. Drop out due to the spike in amp draw. I could do the "wait 1ms" trick between position updates as in the other recent post, but I'd prefer to identify the weak point in the power system. This was running off a desktop power supply, so that could have contributed.

I have concern over the gauge of power wires to the Roboard with the provided power plug pigtail, the wire seems pretty thin. It shouldn't be a problem with the DC to DC converter, as it's rated at 6 amps, and two servos and a roboard with nothing in the PCI socket aren't anywhere close to that.

The cut-out problem is indicative of resistance in the power connections ahead of the power to the servos. Right now, the path is from a power supply through about 4 inches of 22 gauge wire to the DC to DC converter to the power supply connector and wires to the roboard, then to the servos from the Roboard plugs.

I'd like to separate the power to the Roboard and the Servos, but that will require a fairly extensive rewiring job, and will ultimately take up more space on his back. An o-scope would be really handy right about now, but I'll have to stick with volt meters (one analog) and an LED. I'll probably set up some resistive loads at the power pins on the servo plugs on the Roboard and see how much it takes to make it drop out, then back off that a bit, and check voltage drops in the power. I'll try a strategically placed capacitor as a last resort.

I also am having some initialization issues I haven't bothered to track down yet, whereby the servos lock up, held in a static position, or are powered off, and reset once unplugged and plugged back in. I'd guess that the Hitec robotic servos have entered serial mode due to a short duration pulse from the PWM circuitry, but I need to research it more.

Summary:

I have servo movement, driven by position data extracted from the Robonova's demo .bas file, under Windows XP via Microsoft Visual Studio / VB.net. I am not using the RoBoIO.dll file, but I am using WinIO.dll, WinIO.sys, and rdtsc.dll. All of the "driver" code is in VB. All IO reads and writes are done through WinIO from VB. I have only worked with the PWM and RCSERVO functions, and have not yet started the SPI / A/D / I2C code. I have built functions for accel / decel, but these are not in use at present.

Paul

Btw- my RN-1 would likely be walking if I keep the servo speed slow, and mount my Roboard on his back, but I need to order some teflon to machine some mounting brackets and a roll cage for the board. This board will requires replacing the stock covers to work on the RN-1, and the servo wiring will need to be reworked to allow movement, particularly in the shoulders. This board is ALMOST as wide as the RN-1, and if not mounted above his metal top plate (even with the top of the clips at his shoulders), the bottom corners would protrude.

[mondy1]

Hi, keep up the good work!

I don't understand why you say the roboard needs to be mounted above the top plate. I have mounted it even to the top plate, and I really can't see where there is a problem with this. Can you please explain?
I have attached some images.







I am really looking forward to some code from you that makes my nova walk
Also really appreciate it if you have any more useful code for me to try.

Thank you!

Regards, Mondy

[PaulL]

Hi Mondy,

Regarding mounting of the Roboard, what you have there is fine (looks good, btw!), but I did not want the board protruding by the waist when viewed from the front, so I put the bottom corners as high up as they needed to be to end up completely behind the back plate. I will end up fashioning a "backpack" / back shell out of some thermoformed polycarboante, which should look appropriate from the front. Also, I wanted to reduce possibility of impact to the corners protruding in that area. It just made sense for me, there's no reason what you have there won't suit just fine, and I'm probably being more cautious than I ought to be.

I've taken a break from coding for now to focus on the mechanical and electrical aspects, working on a few upgrades (hands w/ mobile fingers, wrists, hips, servo rewiring, recabling, head rotation without a servo in the battery compartment, upgrading almost all of the stock servos to HSR5498SG's - got a deal on Ebay). For Roboard, I need to add speakers (I have a few to test) and a microphone, and at some point, a camera inside the head.

In general, my overall project goals are:

* Maintain that "brawny" look of the stock RN-1 as much as possible.
* Maintain all (Ok, almost all) original capabilities (all but the remote).
* Keep modification of stock parts to a minimum.
* Add-ons should be bolt-on, preferably using the same holes already in the stock parts if needed.

This just makes it a little more challenging to me.

The hip rotation servos are what will be different from others I've seen. I have a prototype for the bracket-to-bracket bearing assembly, and may be at my lathe tonight making two bearing mounts for both hip bearing assemblies. From here, I just need to make two flat servo mount brackets (the servos will be in the butt area), and add some control arms to rotate the brackets on the hip bearings. The neat part to me is, this mod will only add about 5mm of height to my RN-1 (4mm thrust bearing stack, 1mm servo mounting plate), which will impact stability a lot less than adding in the full height of a servo- and, the thrust bearings I'm using provide a wide base for rotation, meaning very little wobble or play as one might see from the end of a servo shaft in that configuration.

Regarding current software: What I have now is very much beta code, hardly complete and just almost operational, but it does provide some capabilities. I'd hate to send it out and have folks frustrated that I haven't done more yet! For example, I have the stock RN-1 moves imported into the .Net application, but I haven't set up a movement sequencer to have him advance from "frame" to "frame". I have a drop-down box to select each pose, but you have to select each pose on the app itself to advance each position for a walk, for example. Servo directions, trims, and such haven't been set up for configuration, I believe at present, it's all code edits. Any reconfiguring of GPIO for other than PWM is sketchy at the moment, I was working on that last time I was in the code. I'm not saying "no, you can't have my code", but I am saying you might want to be careful what you wish for!

When I do have the code specific to Roboard to a useable and robust enough level, I'll publish it, no doubt there. It's largely based on the RoboIO code, so I can't call that proprietary, and I wouldn't think of trying to sell it- I just don't think it's ready for folks to load it up and let me know it doesn't work yet. But, if you still want it to see what I've got, what I have done so far, and how I did it, I can do that, but it might be a while before I get back to making it more useable while I work on the hardware.

Paul

[mondy1]

Thanks man,
I'm also planning to add hip rotation, and I've bought two HSR5498SG for the job, but now I will wait to see some pictures from your mod. I'm also not a fan of the added height.

Looking forward to see some code from you, ready or not. You shouldn't be to demanding of yourself regarding the readiness of your code. I think most code, no matter how crude, would help the community getting farther. Just code snippets could help someone like me understanding more of how things work together.

Regards,
Mondy

[PaulL]

Well, I'm working on the hands first, that's really a priority for me right now. I think the end result will be pretty cool.

Hip rotation is next after I get the hands and wrists set up. I still have a piece of aluminum in my lathe chuck waiting for me to cut the hip rotation bearing adapter, but the hands have my full undivided attention at the moment.

Hopefully when I'm working on the Pololu serial board code, I can put some stuff out here for folks to see.

Take Care,
Paul

[PaulL]

An update, including a significant change in direction regarding software:

I have finished writing the Pololu Serial Board class (need to test, but there's not much that can go wrong with it). The class supports multiple boards, on whatever comport specified. It should work well when the time comes to put it to use.

In working on the Pololu Serial Board code, I did some thinking. I also looked thoroughly through the document "DMP_Vortex86_Series_Software_Programming_Reference_091216.pdf". This has inspired me to completely rewrite what I've written thus far using a custom scripting engine I built for high-level robot control. I have requested additional register documentation from DMP, but have not yet received a reply to that email.

In short, acquiring base addresses and applying them to registers to configure hardware has driven me to build a set of classes to talk to the registers, regardless of their function, but including register-specific function maps as part of configuration. I am driving register setup and access with configuration, a big theme in the way I write code in general. Functions within the registers can be accessed separately in the way I have built the classes, which will result in a "check list" of sorts of how the board is configured. I think this new approach will be more intuitive in the long run (and adapting to board revisions or updates, even changing out register functionality to support the RB-110 and beyond, should be easy once this is done).

Right now, I'm almost done building a table that will "feed" the register configuration for the board. This approach will be simpler and easier to implement as I begin to take on the SPI interface, and the rest of the Roboard's hardware. Once I have initialized register objects corresponding to Roboard's hardware, setting the appropriate register values will be easy.

A quick word about motion: I've gone through several itterations of motion control with accel and decel, and have settled on a method of "when should the servo be at some targeted end position?" using linear accel / decel ramps. This should allow me to compensate for changes in tempo when I make my RN-1 dance to music- he won't have pre-programmed moves that lose the beat during a song like he does with the stock board, he will be able to match the beat, monitoring the mic input for the spike in volume from bass, and using that to correct when a move should end. This should allow him to "dance" to virtually any song. It should even be possible to have him DETECT rhythym in sound to dance to in order to invoke and halt "dance mode". As for figuring out what style of dance is appropriate for the song being played, that's a whole different story. Does anyone have a "music style recognition" library? (kidding)

Take Care,
Paul

[veltrop]

Paul,

I've been working on a set of ROS nodes for the Roboard (with my KHR but should work with other humanoids as well.) In particular, I set up a motion routine system, and can import motion routines from Kondo's Heart2Heart software, but it could use improvement. But my area of interest is in autonomous behavior so this stuff not where I want to spend most of my time.

I would love to see your servo target position + accel ramp methods. It should tie into ROS's joint-state paradigm well.

I'd also like to study your scripting engine.

I'm hoping to release my BSD licensed ROS stack within the next couple of weeks
Are you planning on sharing your code?

Sorry, I cant help you on the dance music detection front. Maybe check out the source from a visualization plugin for xmms?

[roboard]

Hi Paul,

I resend the register document as your require to ur mail box, check and let me know if u still can not get it

[PaulL]

Veltrop,

I considered building an automatic move import tool, but meanwhile simply manually imported position data from the Robonova programs. But, an automatic import tool isn't really high on my priority list, I've got to get a number of other things going first.

My apologies, I am not able to share the scripting engine code. It is essentially a generic intelligent SCADA system (similar to one that I have built for my employer to run industrial control systems), and like companies that produce SCADA software, I could make a lot of money by selling it for a purpose other than for our hobby.

Regarding the motion code, I need to have a look at it and see how much of it I can separate from the scripting engine.

For anyone wondering what I will give away code-wise for the sake of the hobby, basically anything but the scripting engine, anything specific to the Roboard or hardware that can be used with Roboard. That includes code for: motion control, register configuration, device control, and the pololu serial board code I've written. But, I won't put anything out until I have things tested and working.

Roboard,

Thank You for sending the register doc, it will help in building the register control code.

Take Care,
Paul

[PaulL]

Small update. I have built enough register class code to create an object structure representing almost all of the documented registers (might have a few I will find when I start reworking higher-level classes). It can itterate and load base addresses and retrieve data for all registers using a Base Address identified in the NB / SB of the board. Bit-mapped functions can be accessed individually. I will end up creating a UI to configure the board in a more "easy to access" kind of way.

In essence, I can serialize the configuration of the registers to an XML file, and load the configuration back into the program from that same XML file. This would occur on Startup / Shutdown of the 'bot software. When loaded, I have an object structure I can use to manipulate register values accessing registers and their functions by name.

I started with a table, and have 3 object types represented in the table: Register, Register Function, and Register Function Value Mapping. The Register Function object represents a function within a register based on MSB and LSB for the function represented. The Mapping is used to map values of a function using a Value Name attribute to set the Value for a register. When reading from or writing to the register, individual functions are bit-shifted as appropriate.

Next, I will build classes to wrap functionality of these registers into things like I2C, SPI, PWM, and GPIO classes. For the sake of threading, read and write access must be serialized to keep threaded operations from reading and writing (potentially interleaving) at the same time, and it is through this Register Manager class that this will occur.

See below for a snippet of the XML I am generating from the set of Register-related classes - this is a fraction of what I get (1 register out of 168) when I serialize the object structure to a file (note, this was not loaded from Roboard, which is why the Base Address is zero. Also, all values are decimal, not Hex):

- <Register>
<ID>634129085430336164</ID>
<Name>I2C0 My_Address Register</Name>
<Location>Direct</Location>
<Address>2</Address>
<BaseAddress>0</BaseAddress>
<BaseAddressSource>212</BaseAddressSource>
<BaseAddressLocation>SouthBridge</BaseAddressLocation>
<RegisterValue>0</RegisterValue>
- <Functions>
- <RegisterFunction>
<Name>Slave Address</Name>
<LSB>1</LSB>
<MSB>7</MSB>
<FunctionValue>0</FunctionValue>
<RW>RW</RW>
- <Mapping>
- <Items>
- <RegisterFunctionMappingItem>
<ItemName>User Defined</ItemName>
<MappedValue>0</MappedValue>
<Notes>7 Bit Slave Address checked by internal slave module. If address is match it will switch to slave mode. Processor can write proper value into this register to identify itself.</Notes>
</RegisterFunctionMappingItem>
</Items>
</Mapping>
</RegisterFunction>
- <RegisterFunction>
<Name>Reserved</Name>
<LSB>0</LSB>
<MSB>0</MSB>
<FunctionValue>0</FunctionValue>
<RW>R</RW>
- <Mapping>
- <Items>
- <RegisterFunctionMappingItem>
<ItemName>Reserved</ItemName>
<MappedValue>0</MappedValue>
<Notes>Reserved</Notes>
</RegisterFunctionMappingItem>
</Items>
</Mapping>
</RegisterFunction>
</Functions>
</Register>