PDA

View Full Version : HSW-V2



ArduTank
07-20-2014, 10:17 PM
Update on HSW, went and got boxes for the body, upgraded to 3 DoF legs, and added a crossman m74dp to the turret.

Pics:

5637
5638

5636

The main box gives plenty of room for all of my electronics, plus any vents/fans I plan to add
(lots of heat between the ArbotiX, RasPi, and 10A transistor for gun control)

Planning to use the Issy code modified to have the pan and tilt values control the "neck" servos(turret).

So here comes the one question: Do I use the same commands for the hardware Servo library included with the ArbotiX as I do for the software one used by any Arduino, or is there a different set of commands used???

ArduTank
08-03-2014, 08:18 PM
Update:

Finally got NUKE working (figured out to generate the ino I was missing with 0015) so he is walking with full IK solutions now.

Added minor aesthetic touch-ups to the legs, in the form of guards sticking over the top

Completed wiring the power circuit, with enough room to leave the charge inside the body when finished. Gun will end up mounted to the body along with the camera.

Pics:

5655

(Yes, there's a hay mower in my yard; That's where the other half of my time tends to go)

5656

5657

ArduTank
08-04-2014, 09:29 AM
Anybody got any suggestions/comments???

tician
08-04-2014, 12:13 PM
Probably add bracing on the bottom of the body servos so the top flanges don't break off under loading, and add bracing on the idler side of the legs so the entirety of the weight is not supported by the horns (could just be another piece of metal and a pair of standoffs linking the two to minimize twisting).

ArduTank
08-04-2014, 08:33 PM
Looking into an old Erector set for that. Definitely good to know that those spots are very good ideas to brace.

ArduTank
08-10-2014, 08:11 PM
Got him walking recorded. I'm pretty sure the issues with walking backwards is due to the different leg lengths, and using the average of the coxa lengths for the code. I have no clue why he randomly starts walking sideways slowly, and the pan issue is likely an issue with my joystick. Will fix these eventually.

My only two questions are: is there a setting to make the step lift higher (As in, he lifts his feet higher) and is there a switch between strafing and turning with the joystick in the Commander code??

Video:


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

ArduTank
08-12-2014, 07:20 AM
Anyone know the answers??? I've sifted through the code+libraries to no avail.

tician
08-12-2014, 08:20 AM
If you have only one joystick, then you have to implement your own mode switching in your robot's sketch. Basically check for whenever the user is holding one button to make the joystick strafe (release to turn), or just use two buttons (like the shoulder buttons) to do turning.

Switching to southpaw (swap joystick values returned by Commander object) requires a call to the UseSouthpaw() function of the robot's Commander object. Once set to southpaw, the Commander object must be destroyed to return to 'standard' joystick layout.

KurtEck
08-12-2014, 09:41 AM
Sorry, I don't do much with the Nuke code base, so my answers may be a bit random.

First off, your issue with different leg lengths, causing it to not walk straight... I know with the Phoenix code base a long time ago I added provisions for different leg lengths and including the ability for some legs to be 3dof and others be 4dof as I wanted the ability for maybe big front legs...

I don't think NUKE has this ability built in... But looking at the prebuilt AX_12_PhantomX_Hexapod sketch for example: The lengths appear to contained the function legIK, so it should not be hard to make the constants, L_FEMUR, L_TIBIA, L_COXA into arrays or the like and change the call to this, to pass in, which leg....

With my dealings with the Nuke version of the Hexapod, I found that most all of the settings, like how high up the hexapod was, how much to lift the legs and the like were pretty fixed. I don't remember having any control over these values...

As for the UI for changing how the commands from the commander are used, you should have control over. At least with the prebuilt hexapods (and quads), the main sketch file has the loop function in it, which reads in commands from the commander and then acts on them. In the code I mentioned, they are using the 6 buttons on top of the commander to choose a walking gait, and using the ones on the front to do some changes to speed and the like. You should be able to do the same to help control how you are walking...

Note: In some of my versions of the commander library, I have gotten rid of the notion of southpaw and renamed the functions like: WalkV, WalkH, LookH, LookV, to something like: LJoyV, LJoyH... As I was always getting confused on which joystick was which and I also did not have one specific use for the joysticks... You can do the same with current code, you just have to remember is Look the left or right joystick? Walk is the other one...

Again not to confuse things more, but you can also do things like I did, where your code detects some button is down and uses the joysticks differently. As I mentioned above, there is already some of this in the Nuke hex code. In my code, I used the R6 button as a modifier, when pressed I used the joysticks to change things, like body height, walking speed, how far out should the legs be from the body, coxa angles of the legs from the body...

Again sorry that I may not have fully answered your actual questions.

Kurt

ArduTank
08-12-2014, 11:00 AM
Is there a quad version of the pheonix code?? I may look into it, at least for the leg difference and the smoother gaits.

KurtEck
08-12-2014, 11:38 AM
As I mentioned, for leg differences, I think it would be pretty easy to hack that into the nuke generated code base...

For example looking at the Quadruped_Mark_II sketch I downloaded awhile ago from Trossen, if you look at the nuke.h file you see the Leg lengths L_COXA... you could create some new defines like L_COXA_LR, L_COXA_LF, L_COXA_RR, L_COXA_RF... with the specific ones for each leg.

In nuke.cpp, create a static array with these in it, something like:
int alcoxa[4] = {L_COXA_RF, L_COXA_RR, LCOXA_LF, LCOXA_LR};

likewise for tibia and femur...


Then in the function legIK, pass in another parameter, which is which leg...
And change each line like:
long trueX = sqrt(sq((long)X)+sq((long)Y)) - L_COXA;

to something like:
long trueX = sqrt(sq((long)X)+sq((long)Y)) -alcoxa[legindex];

Edit: some stuff dropped out when I went to advanced mode...
You then need to change the lines in doIK, that call off to legIK, to pass the legindex to the calls to legIK.

But if you wish to try out the Phoenix code base:

There are several projects up on github that support the quads. My main project Arduino Phoenix in Parts has a quad branch:
https://github.com/KurtE/Arduino_Phoenix_Parts/tree/Quad-Support

The Quad branch name is misleading as it yes added quad support, but is also the more up to date version. What I should do is make this the master branch, and maybe make the Master branch be an Archive branch. But I am not Git wizard :lol: Probably can simply get into the master branch and create a new branch, then select quad support branch, save the files away, then switch back to master branch, copy the quad files back in and tell it to synch... But there is probably an easier way...

Or, if you want a simpler to play with version that is specific to the AX like servos and the Commander, you can simply go to the project: https://github.com/KurtE/Phantom_Phoenix

This project is setup for both the PhantomX Hexapod and Quad. There is a simple define in the main sketch file
#define QUADMODE that you uncomment for quads.

Kurt



Then in doIK, you need to pass the leg index in the calls to LegIK. Example:

sol = legIK(endpoints[RIGHT_FRONT].x+req.x+gait.x,endpoints[RIGHT_FRONT].y+req.y+gait.y,endpoints[RIGHT_FRONT].z+req.z+gait.z);

to:
sol = legIK(RIGHT_FRONT, endpoints[RIGHT_FRONT].x+req.x+gait.x,endpoints[RIGHT_FRONT].y+req.y+gait.y,endpoints[RIGHT_FRONT].z+req.z+gait.z);

ArduTank
08-28-2014, 08:32 PM
Completed build of motor driver, mounted the airsoft gun, and have him standing with full electronics weight. Pic on the project page, phone refuses to upload for forum post.

ArduTank
05-27-2015, 10:59 AM
Little teaser of new parts for him:

59565957

They fit pretty well so far, more on these when I get home (My 3rd period class had 3D printers that we're allowed to use; It also helps that today is the last day of school).

Work on him should pick up now due to lack of school for the summer. :D

ArduTank
06-01-2015, 12:45 PM
So, things have gotten interesting. Apparently, the power switch on HS Walker got flipped on, and left on. I never turned him on. This drained the battery to the point that it puffed. There goes $20 out the window.

On another note, the 3D printed parts will be on him once I've finished trimming them to fit (the printer wasn't running at the highest resolution as per my teacher's instructions because it would take forever)

ArduTank
02-08-2016, 09:22 PM
6432
















Finally back up and moving.

Gun loomed for driver, laser pointer, and 3 axis gyro for stabilization. :D

ArduTank
02-26-2016, 01:11 PM
And he's walking again, with the new 3d printed parts. Just need to figure out why he bobs up and down so much. First stop, stiffening the center frame.


https://youtu.be/2mFGsS_Y3-U

jwatte
02-26-2016, 06:45 PM
The bobbing seems to be that the servos get loaded more heavily when two legs lift, and the compliance is too soft to keep them in the same position. You could try increasing the punch and slope of the servo profile if it's AX-12a. Or maybe even know that this will happen, and artificially push the legs that remain on the ground down a little bit when you lift the others!

ArduTank
02-26-2016, 09:23 PM
I actually ran a bunch of 20lb fishing line through the bolt holes on the bottom of the coxa's in a net pattern that is always taut. It fixed a large amount of the bobbing.

What's a normal amount of gear slop for AX-12+/A?? I'm using a mix of these, and there appears to be a major amount of gear slop.

One other fix that helped was to increase the liftHeight value in the hacked up mash up of PhantomX MK2 + NUKE generated code he's running. :)

(one side effect of which is that the ripple gait goes nowhere.)

Will definitely look into adjusting the servo profile. I almost wonder if the NUKE code doesn't limit the servo force. I normally cannot force these servos to move by hand, but when running NUKE, they have some spring to them.....

ArduTank
03-04-2016, 06:38 PM
So, I extended the tibias with some aluminum bar, and that fixed the bobbing entirely. Now I have to decide if it is safe to bring liftHeight above the stock 30 to deal with the legs not clearing the ground well.