PDA

View Full Version : OKQ1: 4DOF MX Quad Mech



Upgrayd
09-25-2012, 10:57 AM
After my hiatus from competing in 2012 I have started a new mech to dominate in 2013!

OKQ1 (Off-Kilter Quad One) will be an MX servo based quad with four degree of freedom legs.

Between the end of MW 2012 and now I have been experimenting and perfecting new IK calculations, gait algorithms and control ideas.

Pictured below you can see my prototype chassis using AX-12 servos. I have not yet settled on a final leg configuration. Currently I am borrowing heavily from Zenta's T-Hex hexapod configuration.
http://forums.trossenrobotics.com/gallery/files/3/3/1/6/okq1-2_thumb.jpg

In this first video you can see me testing my 4DOF IK calculations with a single leg. The foot is being moved in a circular motion. You can see that the final leg joint is always kept perpendicular to the ground.
http://www.youtube.com/watch?v=He6WeLmsaYc

http://www.youtube.com/watch?v=He6WeLmsaYc

In this second video you can see my first test of the new gait algorithm working smoothly and accurately.
http://www.youtube.com/watch?v=c-W1z0hRlE8

http://www.youtube.com/watch?v=c-W1z0hRlE8

As always my work is open and freely available. Take a look at my github account (https://github.com/RyanLowerr).

cire
09-25-2012, 12:05 PM
Interesting, looks pretty smooth. MX28's eh? Could be scary.

Th232
09-25-2012, 06:01 PM
This'll be good, will be watching closely.

Upgrayd
09-26-2012, 01:26 PM
Interesting, looks pretty smooth. MX28's eh? Could be scary.

28's? That would be cute. :D

Xevel
09-26-2012, 06:53 PM
28's? That would be cute. :D

Oh my. That's what I assumed too reading your post. Please don't tell me you plan on using 106s, you don't need to be able to stride over Insanity Wolf and Chimera you know :p

Th232
09-27-2012, 01:41 AM
For sheer overpoweredness, double MX-106 joints?:robotsurprised:

Upgrayd
09-27-2012, 09:50 AM
For sheer overpoweredness, double MX-106 joints?:robotsurprised:

Not quite that much overkill! I am going to be using MX-64T servos.

jwatte
09-28-2012, 12:00 AM
You know, just the other day, I was thinking how FREAKING AWESOME it would be to build a MX-64 quad. I'm glad you're doing it!
(I mean, who needs a new car, anyway, right? ;-)

Gertlex
09-28-2012, 03:08 PM
Nice work so far, Upgrayd.


You know, just the other day, I was thinking how FREAKING AWESOME it would be to build a MX-64 quad. I'm glad you're doing it!
(I mean, who needs a new car, anyway, right? ;-)

Well Chimera is an RX-64 quad... :)

elaughlin
09-28-2012, 06:51 PM
As well as Insanity Wolf

Upgrayd
09-28-2012, 09:02 PM
Continuing to make some great progress with the code over the week.
I now have all four legs working in tandem with the gait algorithm.

http://www.youtube.com/watch?v=goDxCRBggB4

http://www.youtube.com/watch?v=goDxCRBggB4

Next up is to start tackling a controller interface and a motion manager.

jwatte
09-29-2012, 01:39 PM
What's the white controller board (on top)? A homebrew?

Upgrayd
09-29-2012, 02:08 PM
What's the white controller board (on top)? A homebrew?

Its the ATMEGA644 board that I used in my 2011 mech Gold Rush. This blog post (http://offkilterengineering.com/mechcontroller-v1/) has some pictures of it. I will be using a new smd version of that board in OKQ1.

jwatte
09-29-2012, 06:15 PM
I added ‘Faux Silkscreen’ by printing out and gluing a sheet of paper

Super Ghetto! But pretty sweet nevertheless ;-)

Upgrayd
10-10-2012, 11:12 PM
Auto targeting would be a great feature for a mech to have. I just so happens I have been working on a target panel tracking solution.

Enjoy this short teaser of my first working demo! :D

https://www.youtube.com/watch?v=YkVcolsU6pA

https://www.youtube.com/watch?v=YkVcolsU6pA

Upgrayd
10-13-2012, 07:43 PM
Auto targeting teaser #2

https://www.youtube.com/watch?v=hQVFpXx4yGg

https://www.youtube.com/watch?v=hQVFpXx4yGg

gdubb2
10-13-2012, 10:05 PM
Well, we're in trouble now... As if you really needed that.

Overachiever...:wink:

Ok..Ok.. Nice work.

Gary

Th232
10-13-2012, 10:34 PM
Very nice.

I wonder if anyone will have dummy panels on their robots to counter this...

jwatte
10-13-2012, 11:32 PM
The rules state that you're allowed to attach frames/colors/tape to the competitor's panels. Given that I just wrote a "cone recognizer" for my robomagellan rover, it would be easy to make the color it looks for configurable. If you put on red panels, I select green tape for outlining... (oh, oh, are we seeing the beginnings of a metagame evolve? :-)

darkback2
10-14-2012, 12:41 AM
that is amazingly fast! great work. Now I'll have to perfect Hikari's grab the toy cars scattered around the arena and throw them move.

Upgrayd
10-14-2012, 02:29 PM
Overachiever...:wink:

Jealous as ever I see!


I wonder if anyone will have dummy panels on their robots to counter this...

I doubt it. It is still a quite a challenge to fit everything that is required on your machine as it is.


If you put on red panels, I select green tape for outlining... (oh, oh, are we seeing the beginnings of a metagame evolve? :-)

I sure hope it does not devolve into swapping "skins" for each fights. Seems somewhat outside of the spirit of the event in my opinion. Either way I think that the rule implies that I would get to decide how to attach my fiducial marker on my opponents target panels.

jwatte
10-14-2012, 11:18 PM
Either way I think that the rule implies that I would get to decide how to attach my fiducial marker on my opponents target panels.[/QUOTE]

That's right! And once you attach your neon yellow frames, I attach a second set of neon yellow frames, in different locations. Gives me 50/50% chance to confuse you :-) Metagame, begin!

Upgrayd
10-19-2012, 09:50 PM
Continuing to work with my targeting/tracking solution. I am now able to track multiple targets at the same time!

http://www.youtube.com/watch?v=dUk00fm6LKc

http://youtu.be/dUk00fm6LKc?hd=1

Upgrayd
10-21-2012, 07:22 PM
Starting to do some CAD work with leg designs.

The goal here is to try and make as many the robot's non standard parts from simple laser cut pieces.

http://forums.trossenrobotics.com/gallery/files/3/3/1/6/chassismockup_thumb.png (http://forums.trossenrobotics.com/gallery/showimage.php?i=5001)

I think the femur segment I have pictured is too tall/long but this will be the leg configuration OKQ1 will have.

jwatte
10-21-2012, 09:09 PM
Long legs means faster speed, as long as you can move them, right?

Th232
10-21-2012, 09:46 PM
Longer legs may also run into issues with flex if they're not designed well. Doesn't look like it'll be a problem for yours though, the femur looks fine from here.

Are the laser cut parts going to be aluminium or plastic of some sort?

Upgrayd
10-23-2012, 09:38 AM
Yes, longer legs will give you a theoretically faster speed because you can increase the length of a leg’s stride. Even with a shortened femur this leg configuration already has a 2x longer leg stride than my previous two mechs.

But faster is not always better. Considering the small but significant 'lag' in the camera video there is a point where stability and smooth motion benefits outweigh more speed.

I also need to consider height and weight distribution. My turret and guns need to operate in the space above the legs.


Are the laser cut parts going to be aluminium or plastic of some sort?
ABS plastic. Cheap, strong, easy to modify.

Upgrayd
11-06-2012, 05:36 PM
So some parts showed up in the mail today...

http://forums.trossenrobotics.com/gallery/files/3/3/1/6/p1010013_186204_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=5006)

Th232
11-06-2012, 07:14 PM
Very nice! Looks like you're going to have a lot of fun there.

Upgrayd
11-23-2012, 01:39 PM
Getting back into the swing of things after moving...

I was able to get my Dynamixel-AVR library updated with MX control easily. I should be receiving the ABS parts and hardware for the chassis and legs shortly.


http://www.youtube.com/watch?v=FZhbWqf-7Bk

Xevel
11-23-2012, 01:54 PM
Jealous does not begin to cover it...

Upgrayd
12-04-2012, 07:19 PM
More and more parts have been arriving in the mail. I now have all the abs parts along with the nuts and bolts to assemble the legs and chassis.

First leg assembled sans final leg segment (tarsus).
http://forums.trossenrobotics.com/gallery/files/3/3/1/6/p1010024_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=5028)

Assembled leg next to the ax-12 prototype chassis.
http://forums.trossenrobotics.com/gallery/files/3/3/1/6/p1010024_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=5028)

Upgrayd
12-09-2012, 12:06 AM
With only a few tweaks to the dimension and servo direction defines the code written for the prortype 4dof robot is running flawlessly on the now assembled OKQ1.


https://www.youtube.com/watch?v=_39y1LECMM4&feature=g-hist

Th232
12-09-2012, 12:24 AM
That looks awesome, can't wait to see it standing on its own four feet!

Probably not much of an issue for Mech Warfare and so on, but what's the power consumption like?

darkback2
12-13-2012, 03:11 PM
Are you at trossen? Something about that table looks familiar.

Upgrayd
12-13-2012, 04:07 PM
Are you at trossen? Something about that table looks familiar.

I was there on that particular day.

jwatte
12-13-2012, 05:41 PM
What distance along ground are you getting from center to tip?
With 60kgcm I'd expect 20 cm for 3 kg of mech?

Upgrayd
12-16-2012, 11:35 AM
What distance along ground are you getting from center to tip?
With 60kgcm I'd expect 20 cm for 3 kg of mech?

I am not sure what you are asking exactly.

jwatte
12-16-2012, 01:40 PM
Another way to ask the question:
When walking, what distance do you keep between two opposed feet touching the ground? What's the "span"?

The reason I'm asking is that, with 60 kgcm torque, about 20 cm / 3 kg seems like the right trade-off. And, because the worst-case torque is edge to center of mass, it's the distance from the center to the furthest tip/foot touching the ground that matters the most, if I understand the calculations right.
Thus, I estimate 20 cm from center of mass to foot touching ground, or 40 cm from front-left to rear-right foot touching the ground. But I could be totally off and not understand the math, so knowing what measurement works for you would help me check that math.

Gertlex
12-16-2012, 01:48 PM
Hey Jwatte, see this thread for why you're calculating the torque wrong: http://forums.trossenrobotics.com/showthread.php?5349-4-DOF-leg-mechanics-and-torque-requirements

Basically, the length of importance is the distance between where the foot touches the ground to the shoulder joint.

To illustrate with simple statics:


W↓
.---------------------.
/ \
/ \
↑W/2 ↑W/2

For a given weight W, the distance between the two joints has no effect on the torque at those joints.

jwatte
12-16-2012, 09:24 PM
That's great! That means I could build a bigger bot with the same servos by increasing the center plate if needed.
So, another way to think about it: Assuming the other legs do their jobs, then the shoulder joint does the job of carrying 1/N of the robot weight across (shoulder-to-foot) horizontal distance.

Also, a quad could walk with 3 feet on the ground at all times. With, say, a 6 kg robot, that's 60/(6/3) == 30 centimeters from shoulder to foot! With another 30 centimeters for the center plate, that would be a 90 centimeters (3 foot) span robot. It would have a hard time fitting on the Mech Warfare arena :-)

tician
12-16-2012, 10:42 PM
Also, a quad could walk with 3 feet on the ground at all times. With, say, a 6 kg robot, that's 60/(6/3) == 30 centimeters from shoulder to foot! With another 30 centimeters for the center plate, that would be a 90 centimeters (3 foot) span robot. It would have a hard time fitting on the Mech Warfare arena :-)
Note that the 60 [kg-cm] rating of the MX-64 is not for continuous use. Running at full load like that will cause it to overheat before too long, and repeated overheating without permitting a full cool down can cause the motor to seize. If that motor failure is not caught early enough you can wind up with a complete paperweight instead of just the $70+ to replace a motor (that's just the MX-28 motor, MX-64 is probably more). We've had multiple MX-28 fail without full load, and the most likely cause at this point (other than falling off the 4' stage) is that the theatre students did not permit the cool down period after an over-temp shutdown (working on a really hot stage doesn't help). There are a couple other users on the DARwIn-OP forum to report similar problems with repeated overheating causing servo failure, so just a quick word of caution.

jwatte
12-16-2012, 11:15 PM
Note that the 60 [kg-cm] rating of the MX-64 is not for continuous use.

Interesting. The specifications don't say anything about that being the case... While I would assume RC-type "steering" servos to not be rated for full duty, I'd expect a robot servo to be able to stay put at the rated torque without damaging the servo.

Is there a known torque at which it will work okay indefinitely? Most motors, inductors, etc, are rated at a current that will cause a heat gain to ambient that the insulation and other parts of the motor/assembly can take. Typically this is about 80 degree C gain over 25 C ambient in still air.

What, if any, ability is there to air cool them? I note there's a small heat sink on the side -- would adding moving air there make a noticeable difference?

tician
12-17-2012, 12:06 AM
http://support.robotis.com/en/product/dynamixel/mx_series/mx-64.htm
6.0 [N-m] stall torque at 12V. Stall is the most you get for a very limited time without damage. Continuous torque can be a significant percentage of stall, but the lower you go then the less likely it is going to cause trouble (think of it as using a factor of safety with stall being likely damage/failure). That said, two or three of the MX-28 failures were in the elbows/shoulders with little continuous loading - moving a pencil/sword velcro'd to the inside face of the hand (lots of high-speed, short distance, repetitive motions in a really warm room under bright lights - lots of heat) (two more failures in the elbow and shoulder were sheared off output splines from falls off the stage).

There was a humanoid robot marathon competition a year or two ago where teams were using CO2 duster/cooler canisters during 'pit stops' to help prevent/counteract overheating in servos (I think robotis and kondo were the two big names in that race). It should be somewhere on either botjunkie or IEEE automaton.

Slugman
12-17-2012, 12:44 AM
Looks like you guys might have to see if my cheap, light & simple AX-12 heat-sink mod will work with the bigger servos.
S'pose the next step after that is tiny fans on the heat sinks. Lol. :)

Note: I say "my" because I've done it, but I do not profess to own the afore-mentioned mod. I'm not from Apple....

Upgrayd
12-31-2012, 02:37 PM
After spending most of my vacation enjoying myself I managed to get OKQ1 walking today.


https://www.youtube.com/watch?v=3HXWyI6f1zM

This is by no means final or optimized. It was really just a quick hack to try walking for the first time. You can see the program halt twice... not sure what exactly caused that yet.

The ghetto controller you see in the video is made out of three axis joysticks, a atmega168 breakout board, an xbee and a small lipo all stuffed into a USPS mailing box.

kamondelious
12-31-2012, 03:36 PM
Awesome, just awesome. Great work.

:D

Gertlex
12-31-2012, 04:02 PM
Smooooth. Nice!

jwatte
12-31-2012, 09:09 PM
Yeah, that looks great! I'm not quite there, having been derailed by fitting too much stuff into a too small box :-)

Slugman
01-03-2013, 02:24 AM
Just watched the video, & that is one very stable firing platform. :happy: You're gonna kick hip-servo with that.

Upgrayd
01-03-2013, 12:27 PM
Thanks for the kind words guys.

Getting the software to this point was my first major hurdle.
Unfortunately I have relied heavily on floating point calculations. This now it is starting to create an unmanageable execution speed bottleneck and accurate timing of coordinated moves is impossible. So my next goal is to covert over to entirely fixed point math.

Once that is complete I can start folding in all the other experimental control experiments I have not yet published.

These include:
Turret Follow Mode - Turret position defines the front or forward direction of the robot.

Turret/Gun Kinematics - Have the turret and guns calculate the position required to aim at a point three dimensional space.

Gait and Pose Blending - Cleanly combining gait and position interpolation based movement.

Auto Target


Exciting stuff ahead!

Upgrayd
02-17-2013, 10:57 AM
Running out of time fast!

I have completed the conversion from floating point to fixed point math. That was difficult and took much longer then I would have liked. But in the long run I learned a lot and was able to improve the performance of OKQ1 by a huge amount.


Time for an update... This video is a demonstration of some simple motion management I have programmed for OKQ1:

http://youtu.be/6qPavPBwjbw


When ever the robot does not have a travel request from the controller all the legs will interpolate to a standing position.
If the robot is idle for X amount of time it interpolates to a siting position.
At any point the robot can receive a travel request and continue walking from wherever it left off.

You can see a few times where the robot 'jumps'. I still need to add a motion to interpolate between a large change in travel request parameters.

jwatte
02-17-2013, 02:18 PM
That looks pretty good! Given your trouble with floating point performance, I'm counting myself lucky I chose to go with a real CPU on-board, and only use the microcontroller for servo driving :-)

Gertlex
02-17-2013, 05:05 PM
Buttery!


That looks pretty good! Given your trouble with floating point performance, I'm counting myself lucky I chose to go with a real CPU on-board, and only use the microcontroller for servo driving :-)

I think he switched to fixed point calculations a few weeks ago. I really need to take a gander at that code :)

Th232
02-17-2013, 05:25 PM
When ever the robot does not have a travel request from the controller all the legs will interpolate to a standing position.
If the robot is idle for X amount of time it interpolates to a siting position.
At any point the robot can receive a travel request and continue walking from wherever it left off.


I like this bit, looks much better than just pausing with a leg or two in the air.

jwatte
02-18-2013, 03:01 AM
I got a pretty similar effect by scaling the leg lift and leg swing down to 0 when there is not speed forward set.
The walk engine actually keeps the gait going internally, but it just stands still because the scale is 0 :-)
The foot lift scales from 0 to full over the first 10% of the throttle scale, whereas the forward/backward motion scales smoothly over the entire range.
I don't "sit down" when idle, though. I imagine that will save some battery, and I probably should steal^H^H^H^H^H be inspired by that!

Upgrayd
02-18-2013, 10:54 AM
That looks pretty good! Given your trouble with floating point performance, I'm counting myself lucky I chose to go with a real CPU on-board, and only use the microcontroller for servo driving :-)

It was no so much that I was having trouble. It is more about knowing achievable improvements were possible over the results I was seeing.
I would't call adding a 'real' CPU to a realtivly simple system lucky. I have been down that route and it only added points of failure.


I really need to take a gander at that code :)

Keep the ducks away from my code please.


I like this bit, looks much better than just pausing with a leg or two in the air.

Agreed. It is really nice to finally have a machine that is not just simply looping between pre calculated posisitons as fast as possible.

Gertlex
02-18-2013, 11:10 AM
I don't "sit down" when idle, though. I imagine that will save some battery, and I probably should steal^H^H^H^H^H be inspired by that!

Both cire and I did this last year. I didn't think of/implement this until I got to RG, either. :D

For me, it was more about reducing strain on the servos, rather than battery capacity. And indeed, I killed zero servos at RG, after losing ~5 AX-12s to motor failure during building/testing.

quantmfizikz
08-18-2013, 08:48 PM
Hey Upgrayd, great robot! Im also building a mech with mx64's. just wondering what material you used? or if you could point me in the direction towards materials which are similar?

thanks

Upgrayd
09-17-2013, 05:40 PM
Hello all. I am not dead! Just very very busy with work and new found interest in other hobbies.

I received an early version of the Arbotix-M a while back. I have mounted it on OKQ1 and rewrote the relevant portions of his code to run on this new hardware. Had it up and running again in no time.


5018

I hope to find the time once again to continually work on this project and be ready for whenever the next Mech Warfare event takes place.

jwatte
09-17-2013, 06:48 PM
How much does it weigh with full load?
Have you actually walked it around at speed in a real situation yet?
I'm trying to find someone who has actually successfully done a full quad mech based on MX servos, and haven't found anyone yet...
(I know of a few failures, though.)

Upgrayd
02-23-2014, 01:33 PM
Found some time this weekend to get OKQ1 back up and walking.

I have made a few improvements that simplify the gait and motion engines and have started to iron out the controller communication scheme.

I took a short video of OKQ1 walking around on carpet. The feet seem to catch and drag a little bit but overall it moves around quite well on the carpet.



http://youtu.be/_PwzMg43UKI

KevinO
02-23-2014, 01:54 PM
Looks great! Your quad was one of the reasons I decided to build with MX-64s. They are so smooth, I love the resolution compared to the AX servos.

Carl
03-07-2014, 04:08 AM
Looks good; Do you control it with the computer?
I can't wait to see it finished!

Machine27
04-13-2014, 07:33 AM
Amazing work!

Upgrayd
02-04-2015, 08:36 PM
Wow its been almost exactly a year from my last post! Time sure does slip away when you are busy...

Over the last few months I have been slowly learning ROS. After running through the tutorials multiple times and studying other peoples work I think that I am finally able to take a crack at writing my own packages.

So far I have been able to roughly model OKQ1 and visualize it in 3D. It should not be too terribly difficult to port my existing AVR gait and IK code to C++, wrap it in some ROS nodes, and publish the joint positions to the visualization. Exciting stuff!

5830

Hopefully my next update should be sometime between now and next year!

Xevel
02-04-2015, 09:11 PM
Wah, Upgrayd is back! Welcome back :)

It's looking good :)

What package do you use for talking to the dynamixels? It seems that there are multiple of these and I would be interested to get some insight into why people use one or the other (the goal being to contribute some stuff to make the USB2AX better integrated in the long run).

KevinO
02-04-2015, 09:42 PM
Looks great!

KevinO
02-04-2015, 09:53 PM
I have a hexapod_locomotion node written and I'd love your opinion on it Upgrayd if you are interested. Currently it reads a standard twist messages as well as an optional tf for body orientation which I use for IMU auto leveling. Internally it manages the gait and IK then outputs the joints and links for the robot_publisher node. I only have a few videos out there since I'm still working on the navigation stack integration. Here is a link of the few updates I've made so far. http://forums.trossenrobotics.com/showthread.php?6725-ROS-Hexapod-project-Golem-MX-64-4dof&p=66297#post66297

Upgrayd
02-04-2015, 11:06 PM
What package do you use for talking to the dynamixels?

Nothing yet. Just simulating so far.

I am considering two options. First being the USB2AX and the second is using an arbotix-m running some custom ROS firmware.

Upgrayd
02-04-2015, 11:08 PM
I have a hexapod_locomotion node written and I'd love your opinion on it Upgrayd if you are interested.

I am interested! Always great to see how different people have solved (or tried to solve) walking locomotion.

Upgrayd
02-11-2015, 10:32 PM
I was able to hack up my existing AVR gait and IK code enough to get a visulization of a single leg walking working tonight.


http://youtu.be/6x0UgOJ4gJU

KevinO
02-11-2015, 10:44 PM
Looks awesome. Great work!

Upgrayd
02-12-2015, 07:03 PM
All four legs...


http://youtu.be/R67bsDe8hYE

Upgrayd
06-03-2015, 08:13 PM
Inspired by KevenO's and R3n33's ROS progress with their hexapods I am continuing work on OKQ1. Over the last few nights I have worked a bit with odometry to get my simulated robot to walk in circles.

http://forums.trossenrobotics.com/gallery/files/3/3/1/6/okq1rosodom_thumb.png (http://forums.trossenrobotics.com/gallery/showimage.php?i=5563)

r3n33
06-03-2015, 11:03 PM
Inspired by KevenO's and R3n33's ROS progress with their hexapods I am continuing work on OKQ1. Over the last few nights I have worked a bit with odometry to get my simulated robot to walk in circles.

http://forums.trossenrobotics.com/gallery/files/3/3/1/6/okq1rosodom_thumb.png (http://forums.trossenrobotics.com/gallery/showimage.php?i=5563)

Who me? ;)

First off, hi! I've read through this thread a couple of times. Your build is awesome. The smooth movement of the MX servos and the walk gait are most desireable. Everything is so clean and well organized in appearance. Plus the motion tracking looked well done. Did you ever get to use your motion tracking with a turret mounted up top?

All in all, very nice!

Are you still running the ATmega644? ... and ... What are your ideas or plans for migrating your ROS simlation to the physical OKQ1?

Upgrayd
06-04-2015, 10:42 AM
Who me? ;)

First off, hi! I've read through this thread a couple of times. Your build is awesome. The smooth movement of the MX servos and the walk gait are most desireable. Everything is so clean and well organized in appearance. Plus the motion tracking looked well done. Did you ever get to use your motion tracking with a turret mounted up top?

All in all, very nice!

Are you still running the ATmega644? ... and ... What are your ideas or plans for migrating your ROS simlation to the physical OKQ1?

Yes you! Thank you for the kind words. Yes I have been very happy with the MX servos and they perform great. I never took the tracking/autotarget much past a prototype.

The plan at the moment is to use the Arbotix-M or similar board running some custom firmware to pass dynamixel packets wireless from my desktop PC to the servos. Eventually I want to install ubuntu/ROS on one of the many single board computers I have and mount it on OKQ1. Just taking it one step at a time as my job keeps me quite busy these days.

KevinO
06-04-2015, 11:26 AM
Hey Upgrayd,
Make sure you eventually put in a covariance for your odometry. If you use it in any Kalman filter package you'll need it. For example robot_localization or even the robot_pose_ekf package (not a great package) both expect covariance included with odometry, it won't fuse properly with IMU odometry or visual odometry without it. The examples on the ROS wiki don't even mention it so it took me a bit to figure that out.

Upgrayd
06-14-2015, 01:56 PM
Continuing to make progress on OKQ1 and ROS. This last week I have been focusing on communicating with hardware and cleaning up my ROS packages.

Below is a video of my testing set up. You can see my hardware with a dynamixel servo turning, the output of rqt_graph and a rviz simulation running.


https://www.youtube.com/watch?v=B5QzpxKu77c

The legs in rviz are spinning around like crazy because I made a node called "boguscmd" that simply publishes commands to each joint for testing purposes.

I am talking to the servos serially using Sparkfun's FTDI Basic Breakout (http://www.sparkfun.com/products/9716) board. I have programmed the Arbotix-M with some custom firmware that simply relays packets it receives from the PC on UART 0 to the dynamixel servos on UART 1. Likewise any return packets from the dynamixel servos received on UART 1 are passed onto the UART 0 back to the PC.

I have 3 ROS meta packages I am working on:


okq1_ros (https://github.com/RyanLowerr/okq1_ros) - Robot specific parameter and launch files for my robot.
crawler_ros (https://github.com/RyanLowerr/crawler_ros) - packages for simple crawler robots. I want to flesh this out to include generic packages that can be used to generate gaits and movements for quads and hexs with legs with various degrees of freedom. At the moment this only has the packages I need for OKQ1 and are not very generic.
atmega_ros (https://github.com/RyanLowerr/atmega_ros) - packages to serially communicate with controllers designed around the AVR ATmega micro controllers. Bascially a copy of the arbotix_ros packages but I wanted to try my hand at writing my own.

Upgrayd
07-18-2015, 11:10 PM
Made some more good progress the last few weeks and also found some time for a much needed vacation.

My focus has still been interfacing ROS with my hardware. I have written a sync read function in my custom Arbotix-M ROS firmware. This is allowing me read each servos current position and publish the robots actual state to ROS rather then assuming the servos are instantly in the position they were last commanded to go.

Below is a short video showing me manually moving OKQ1's legs while ROS in the background reads the servo positions and mirrors the movements on screen.


https://www.youtube.com/watch?v=_KlGybAohu4

KurtEck
07-19-2015, 10:26 AM
Pretty cool!

Will be interesting to see how this all integrates with the rest of the ROS Servo Driver code.

Great Work!

Zenta
07-19-2015, 11:26 AM
Great work! :happy:

r3n33
07-19-2015, 11:59 PM
Thats awesome! It's nice to see some servo feedback getting into a ROS node. How's the read performance so far?

Upgrayd
07-20-2015, 08:20 AM
Thats awesome! It's nice to see some servo feedback getting into a ROS node. How's the read performance so far?

I have tested up to 30hz. I believe it is possible to get higher.

Still have some intermittent hiccups in my Arbotix-M firmware that I need to diagnose.

KurtEck
07-20-2015, 09:28 AM
I have tested up to 30hz. I believe it is possible to get higher.

Still have some intermittent hiccups in my Arbotix-M firmware that I need to diagnose.
Sounds great.

Out of curiosity are you using this with the ROS dynamixel code base (http://wiki.ros.org/dynamixel_motor)? Last week I took a quick look at this code and if I remember correctly it was trying to read something like 8 bytes per servo (present position, speed, torque, voltage, temp) N times per second. I am still coming up to speed on ROS so it takes me awhile to understand things, like timings and who is in control of what.

In particular, when you issue your SyncRead request, it will take the USB time to send the request to the Arbotix, which will issue 18+ (or 24 for 4dof) Read requests (8 bytes each), wait for servo to respond (14 bytes each), Which then the Arbotix builds into usb packets to send back to your processor. I have not looked at Arbotix USB, but on USB2AX, I think each USB packet is 16 (maybe 32?) bytes of data, so that would take something like 9 (or 5) USB packets for data to be returned... (Sorry Probably too much here...) Anyway we can get an idea of how long each request should take.

But then we also want the hexapod to move. So we probably want to output some N requests per second. Assuming that the main processor is doing interpolation we may want a lot of updates per second (100? more?) and for smoothness we probably need these to go at some pretty consistent rate. Again we can calculate a reasonable estimate of how long it will take to issue these types of commands.

So what I am struggling with is who is synchronizing/scheduling these two different activities? I ran into this with my hacking on the USB2AX code. If two pieces of code try to hit the servo stuff at same time (update positions, query servo information), they collided and both failed... I earlier solved this for myself by updating USB2AX to do interpolation, and during the interpolation, it might schedule reading servo information (I was just doing voltage) on a round robin basis...

Sorry if this was slightly off topic, but I am very curious how you are dealing with this in ROS.

Upgrayd
07-20-2015, 11:08 AM
I have been writing my own package named atmega_ros (http://github.com/RyanLowerr/atmega_ros) to interface with an Arbotix-m board and by extension dynamixel servos. My package is basically becoming a clone of the already available arbotix_ros (https://github.com/vanadiumlabs/arbotix_ros) package. Why am I redoing work that is already done? Good question. I am a robotics hipster and just like to have fun doing my own thing!

As for synchronizing the read and write commands to the servos... My idea is to have my atmega_ros driver node running at a some high frequency that is divisible by the rates that I want to send commands to the servos, read values from the servos and read/write IO values from/to the Arbotix_m. Then the nodes main loop keeps track of when it is time to send a packet to the hardware.

KurtEck
07-20-2015, 11:22 AM
Sounds good! As for doing your own thing, I know the feeling ;) Can not wait to see what you come up with.

Upgrayd
07-21-2015, 08:36 AM
Did a large rewrite of my class that handles sending dynamixel packets (https://github.com/RyanLowerr/atmega_ros/blob/master/atmega_controller/src/atmega_controller/atmega.py) to my Arbotix_m making it much more efficient.

Was able to read positions from my 16 servos at 50hz. Tried it at 100hz and higher and it still worked. My guess is at those rates the Arbotix_m must be dropping most of the packets while it was busy reading from each servo.

Will test again tonight using a logic analyzer to measure the real upper limit.

Upgrayd
07-21-2015, 09:51 PM
After a few tweaks I am able to successfully read the goal position from OKQ1's 16 servos at 200hz!

6115

r3n33
07-23-2015, 01:18 PM
Is it closer to 170Hz? 1/0.00585

Still quite awesome! Any thoughts or expectations on how it might perform when reading and writing?

Can't wait to see more.

Xevel
07-23-2015, 04:15 PM
Nice performances, I think I'll learn a lot from your implementation.
So far, shuffling bytes around in Python hasn't been that fast for me (that's why I'm considering a C++ low level lib + python binding for next time I make a bot).

This loop is only to read positions, right?

!!SofiaMiglani!!
07-23-2015, 10:37 PM
Is there any other scripting language that can be used for this purpose other than python?

Upgrayd
07-24-2015, 08:56 AM
Yes the packet pictured is close to 170hz then it is to 200hz. The rate seemed to vary quite a bit when I was doing that initial test. It is much more stable now after I made a few more tweaks on both the pc and arbotix code. Not sure where the remaining variability comes into play...

I have been playing with reading and writing in the same loop the last two nights. I have set my node rate to 100hz and have been doing a sync read to capture all the servo's actual positions then immediately doing a sync write writing all the actual positions back into the servo's goal positions. This produced the curious behavior of being able to pose the robot like a mannequin that is quite interesting.

Upgrayd
07-24-2015, 08:57 AM
Is there any other scripting language that can be used for this purpose other than python?

For what purpose? Taking to dynamixels? I am sure you could use any language that has a serial communication library. ROS supports C++, python and Lisp.

KurtEck
07-24-2015, 05:22 PM
As already said, nice performance.

Actually I wish the official implementations for ros drivers for Arbotix as well as others Arbotix Pro (and in some case USB2AX) would adopt some of these types of enhancements into the official firmware releases. For example all three of the above should support the group read (USB2AX already does).

As I mentioned elsewhere I also think all three of these can also offload some additional stuff as well, like interpolation... But as I said I have already mentioned this before.

As for Python? I am no Python expert, but I keep meaning to rewrite the razor IMU python implementation into C++. I just don't get how some simple function that waits on input from a serial port and then publishes that data on some topic at not that high of rate of speed should consume 20+ percent of a CPU core... Plus I think it may have create several threads as well!.

Again Great work!
Kurt

jwatte
07-24-2015, 11:16 PM
Python is just generally bad news unless you're very, very, careful.

The console/controller interface for Onyx 7 runs on a Raspberry Pi (old version.) Initially, I wrote it in Python / PyGame, and got 17 Hz update rate at 100% CPU. I then re-wrote it in C++ and OpenGL, and got 60 Hz update rate, at 20% CPU load.

Python can be productive, if your goal is programmer speed rather than CPU speed, and you are very careful about performance.