Showroom Grigory’s 6DOF 24V DC

@Grigory, you are wise to go by what support said at DE. I can confirm everything they told you from my own experience with 2x60’s. You need packet serial to use the kill feature and with packet serial you can set a timeout also so it will stop the motors if a new command is not received within a stated time. Currently you can use Vinsels packet serial sketch for sabertooths. I think you can set a timeout with it too. I have written an SMC3 sketch that allows packet serial also but I’m have been waiting on my partner and assistant to finish testing it for me since he is familiar with using SMC3 and I don’t actually use it myself.

@bruce stephen , although that relay says its 300amps, look at its output power terminals. They appear to be completely inadequate of handling 300amps (but I could be wrong).

As far using car batteries, unless it’s a deep cycle, generally they should always stay on a charger to keep the battery in top shape and long lasting. Therefore a power supply/charger should be used such as for an RV. Also, the battery won’t vent much gas this way so unless you have a crib or pets bed next to you rig and battery; there really shouldn’t be an issue with gas imo.

As far as some work being done to bring a 6dof math plugin, where is it? Quite frankly, it’s been almost a year now since we were told the hard part was done but I haven’t seen anything more stated about more work being done or its impending arrival. It appeared to me, from what was already posted about it, to be one weekend of work away from being viable so I wouldn’t hold my breath while waiting for it. Its to bad he doesn't hand it off to someone that can finish it if he doesn’t have time to do it himself now imho.

@Pit , since you have Describe set for a Sabertooth 2x32 it will show you what settings are available for it. If you change it to the 2x60 then you should only see setting relevant to it. Currently, only the newer 2x32 can handle regenerative currents without an inline battery. At least when using higher amperages.

Thanks!

The difficulty I'm having is not so much with formulas, but with input parameters. I have no idea how much back current my motors will generate and what the duration will be of such back-current events.

Great, I thought so that getting packet serial to work should not be difficult.



I am wondering what the difficuly is with 6DOF math. I made a hexapod robot some time ago and its Python script happily solves inverse kinematics for 4dof legs together with adaptive gait generation tasks. Our case should be simpler as there is no gait and all "legs" are stationary on the ground.

@BlazinH, so did you use a battery in your setup with Sabertooth 2x60's? Do you happen to have a scheme of your connections?

Even if I am not putting any emergency cut-off between battery and Sabertooths, I still need some manual switch to disconnect the battery when the rig is turned off. One option would be to just remove the wire from the battery, but there definitely should be a cleaner solution.

Ok, so this seems to be the "final" layout:



Emergency stop will be as follows, together with Arduinos monitoring PSU status through DC OK contacts and pulling S2's low by opening a transistor to ground:

If you mean, like with many things in life, that once you know how to do something its not difficult, then yes.

I must be a moron then. Lol. The hard part for me is finding the maths written in computer terms already so I can understand them, or at least more or less, so I can figure it out. I don’t have a PhD in math so reading the hand written form is difficult for me to follow. I could write an interface between simtools and an arduino in a weekend though if I had the maths done already (it would likely still require some tweaking after that though).

I used a battery but I don't have a scheme to show you. But its like you posted less the fusses and the disconnect switch. And I just leave my battery connected directly to my sabertooths all the time now. It’s not really any different than leaving your television or a clock plugged in all the time. I had been using a somewhat large knife switch to cutoff battery power for a while, but even its contacts got weak after a while and didn’t always pass the full current.

Just be sure you use the DE recommended wire sizes for your motors size and solder up the ends of the wires if your using stranded cable before you put it in the 2x60 to be clamped down and you shouldn’t have any problems. Also, I minor flaw in the 2x60’s that can cause some major excitement unless they have fixed it by now is that the aluminum heat sink is immediately behind where you insert the wires into the clamp screws. If you push any of the power or motor wires in a little to far, they will touch the heat sink. Getting a couple like this can cause some major fireworks.

@BlazinH, I think the algorithm for 6DOF calculation can be like this:

1) define eight coordinate frames:

#1: Global" with center somewhere in the middle of the base
#2-7: six frames for each of the motors, so that up direction is parallel to global up and X plane is the plane of lever rotation, each of these frames should be defined by rotation and translation in the global frame #1
#8: frame of the moving cockpit
​

​

2) set coordinates of points where rods are connected to the cockpit -- in cockpit coordinates, i.e. Frame #8

3) when position of the moving cockpit in the global frame is known (X = sway, Y = surge, Z = heave, roll = rotation around global Y-axis, pitch = rotation around global X-axis, yaw = rotation around global Z-axis), resulting coordinates of each rod attachment point can be converted to corresponding motor frame by successive application of transformation matrices: first converting to the global frame and then to the frame of motor.

4) Now cooridinates of corresponding rod attachment point are presented as dX, dY, dZ and attachment of the lever to shaft is at 0;0;0

5) rod length is fixed and the rod goes between rod attachment point and the end of the lever. If we draw a circle showing possible positions of the lever end and another circle showing possible trajectory of the rod end in the lever rotation plane, then required lever-end position for the current coordinate of the rod-attachment point will be one of the one or two intersections between the circles:



The cases here may be like this:



Coordinate(s) of intersections can be found like this:



Then, the required shaft angle for this motor will be:







There may be an error somewhere here of course, but it now looks to me like it should work.

That’s helpful information assuming it’s correct but still leaves me with too much work to do to transform it into lines of Visual Basic code. If you could tell me step by step and in order the individual math functions that need to be performed to transform Simtools telemetry into the shaft angles given a set of rig perimeters, then I could certainly build an interface to input a rigs perimeters, take the inputs from Simtools, and send out each motors transformed position data over serial or a network to a controller or another program for further processing. And if you can also show how to do the math in order to adjust the center of gravity, I can add that to the interface too.

Ps I wouldn't need every math function stated individually if you can show multiples it in a bracketed form.

Does this need to be in VB?

It may be quite simple for me to extract parts from my hexapod's Python code, as I already have all matrix transformations implemented. I am sure, however, there should be some library for matrix operations in VB as well.

Moving the center of rotation is quite straightforward with matrix transformations: coordinates of rod attachment points are defined in the cockpit frame, where center of rotation is (0;0;0). You just put that (0;0;0) whereever you wish and when initializing your model just set attachment point coordinates accordingly. If you are rotating around a point exactly at the height of attachment points, then Z-coordinate of all attachment points would be 0, if you set it to -100mm, you will be lifting the center of rotation. You can actually move center of rotation anywhere, up/down, left/right.

For me to help it would need to be in VB. I don't have time or want to try to learn anything new atm.

I have not yet looked into the format of what comes from SimTools. Am I right in assuming it gives six figures?

1) sway = position left/right
2) surge = position fwd/back
3) heave = vertical position
4) roll = rotation forward-looking axis
5) pitch = rotation around left-right looking axis
6) yaw = rotation around vertical axis

The question is what is the reference frame here. If the cockpit is turned to some yaw angle then the cockpit's left-right axis will also turn relative to the base. If pitch is commanded by SimTools, where should the cockpit rotate, what would be the effect of adding pitch: should the cockpit ignore yaw and just raise/lower driver's legs or should it take yaw into account and lower/raise whatever part faces forward of the base?

VB.NET is fine with me as well, but we'll need to see what matrix operations libraries are available. There should be something 3d-graphics oriented for sure

I found this and its source code. Is this what I need?

Yes. And you can adjust the output type and bits used.

No, not really. Here's my code in Python to work with coordinate systems / frames hierarchy.

That's good.

And what about reference frame? Are the movements defined in the coordinate system of the base or in the moving coordinate system of cockpit?

That may be what's needed: http://www.codeproject.com/Articles/20385/D-Geometry-Library-Basic-Classes-and-D-Drawing-u


or this: http://www.vb-helper.com/tut4.htm

Yeah, I found that too.

I believe the cockpit or more so, the COG.

Just to make sure there is no misunderstanding. I am wondering how SimTools expects the rig to handle this situation:




If the cockpit is rotated by a certain Yaw angle, then its own coordinate system (dark green) will be rotated with respect to the coordinate system of the base (red). If now SimTools tells us to pitch forward, should we rotate cockpit around green X-axis or red X-axis?

I believe the base and the vehicle yaw together unless the vehicle is in a traction loss condition in which case the vehicle will no longer be perfectly aligned with the base.