View Full Version : [Question(s)] Up and walking with NUKE, next steps?

03-04-2013, 11:14 PM
A few months ago, I ordered an Arbotix Starter kit, took apart my Bioloid Premium, and started building QaLvin, a 3-DOF quad. I'm pretty limited in my programming/hacking experience and it took some trial and error...but following Inxfergy's tutorials and advice on these forums, got everything running and generated a sketch with NUKE! Here's a video of QaLvin walking in Amble mode. Control is over XBEEs through the Pypose test-drive mode.


At this point, I'm hoping for some advice on (1) how to improve the gait and (2) how to start writing a light Python program to control the robot.
For the gait, I'd like to see QaLvin taking longer steps and covering ground faster. I've looked at the Nuketuning page but am a bit lost as to which variables to start poking. I'm also not clear on how movement speed in the test dive mode works--is it set a maximum? If not, where would I go to tweak it?
For Python control, I'd like to write something along the lines of a standalone test-drive mode with inputs coming from a USB game controller, and commands issued by XBEE. I'm going through Python/Pygame examples and learning much more than I did in my required semester of C++ :tongue: However, I wonder if anyone has general advice for me. Or even an example of similar code they would be kind enough to share?

This has perhaps been a little ambitious as a robotics hobby project (I'm more comfortable with cells than servos)...but it's been a lot of fun so far and I hope to keep some steam going! Maybe even Mech warfare someday....

Thanks for any advice! --Lupes

P.S. I laser-cut body parts at my local hackerspace, Hive13. I owe design inspiration to Mech Warfare bots such as Immortal, Issydunyet, as well as the PhantomX.

03-14-2013, 09:56 AM
it should be possible to hack the standard commander.py to your needs. i tried to do that a couple years ago. i was not very successful, but my python coding is generally bad. you could probably steal some of the methods from it. if i remember correctly, there are a few methods for serial communication that are essential. add in your own input methods, and you could probably pull it off.

03-14-2013, 01:01 PM
So not sure if this would be helpful... but we have done a couple similar things

1) added to commander to send more data (specifically to control turret AZ/El motors for the mech warrior) example code change for this is here


2) We have a stand alone c# program (Called MechCommanderDebug...) that emulates the commands send by the commander since we also have our own gamepad

https://code.google.com/p/rbots/source/browse/#svn%2Ftrunk%2FMechWarrior%2FMechCommanderDebug%25 3Fstate%253Dclosed

3) Our 'pilot' code for the competition used c# with xbox 360 usb game pad and you can see code example of us sending bytes similar to commander, but also receiving bytes and longer stream


** Finally, I would recommend you use a standalone controller like the commander or this one available at jameco to keep a computer operation system out of the loop - no end of odd troubles there.


03-15-2013, 09:37 AM
Thanks to byi for the advice, and double thanks to bloftin for the advice and code examples! I'm trying to see if I can adapt the commander.py and commander.h, I'll post when I get somewhere. As bloftin said, it may be easier for me to just go with a standalone controller...

03-26-2013, 11:04 AM
You can definitely make it walk faster...

This is a video of my Nuke-based quad Roz, walking at about 42 cm/s...


That was over 3 years ago - poor Roz has sat on a shelf gathering dust for a long time. However, I recently started a new job (working for Mozilla), and I will actually start having some spare time again. So, I'm going to start working on robotics stuff again, and specifically on Roz. I plan to use a Raspberry Pi, and do some interesting software to control it.

The key to making a nuke-based quad go fast is using large steps. Your robot is taking little tiny steps. If you watch the following video, you can see I've slowed down the speed significantly, but Roz is still taking large steps. Watch the sweep of each leg as it steps:


- Jon

03-26-2013, 11:22 AM
I've been using the Raspberry Pi to control my PhantomX. It works really well!

03-27-2013, 06:37 AM
jon, what changes do you make to the raw nuke sketch to get that effect? to make mine move faster, i just added a multiplier to the xspeed and yspeed. the trouble with that, though is it is limited by the legs hitting each other if i bring themultiplier too high. also, i am interested to see what sort of code you would use on the pi, and am sort of wondering what those extra legs on roz are for.


03-27-2013, 08:32 AM
I don't know what the released version of Nuke looks like - this was based on a pre-beta that I tested for Fergs before Nuke got released.

What variables do you have to play with? What I can see is tranTime, which I set to either 98 or 131 for an amble gait. That corresponds to 3 or 4 cycles per step, where each cycle is 33 ms. One important thing to do is gradually ramp up your speed - when Roz starts off he is doing about 20% of max speed, and he increases speed smoothly and quickly to get up to full speed in a second or so.

Basically, you need to find a balance between the sweep of the legs (because the front leg will hit the back leg pretty easily if you step too far) and the actual servo speed. Too fast, and it starts to slip and bounce. Having acceleration as I described above is critical to getting up to full speed.

Roz also has silicone pads at the bottom of each foot - this is important in going fast also. Without those, plastic legs would just slide.

- Jon

03-27-2013, 09:16 AM
thanks for the acceleration idea. i will add that in if i get any traction issues. im not sure i follow how changing trantime would change sweep to increase speed. i dont have the code in front of me though, so i guess i will figure it out when i can look at it.

03-27-2013, 09:42 AM
Yeah, I don't really remember most of this stuff either - this was code I wrote over 3 years ago... I have three different iterations of the code, and all the date stamps on the files have been lost, so no idea which code corresponds to what I was running in the video.

- Jon

04-03-2013, 11:18 AM
My quad is walking much better now. These posts have been very helpful!

Using "Test Drive" in Pypose calls up Commander.py, and passes it the correct port for communicating over XBEE. The default Arduino sketch created by Pypose/NUKE sets Xspeed and Yspeed using the packets sent by Commander.py. However, it seems that the speed values sent are by default extremely low. I put in a *5 multiplier for Xspeed and Yspeed in the main Arduino sketch. Much better! I also increased Trantime from the default 98 to 131 by changing "#define STD_TRANSITION" in gaits.h. This makes each step longer in time and distance. Finally, I gave the quad some rubber booties cut from a sheet of rubber gasket material.

The idea of accelerating slowly is great. Starting up the amble at full speed is super jerky. I can manually slide from a slow speed to a faster speed in Test drive. But I'd like to tweak the code to do this automatically!

04-03-2013, 12:32 PM

Can you post a new video? I'd love to see the changes.

In terms of implementing acceleration, the way I did it was to set my "currentSpeed" when it starts moving to some fraction (around 20%) of the speed indicated by the joystick, and then once per cycle increase that until it reaches whatever the joystick speed indicates. Of course, you have to check for joystick changes every cycle, and update your current and max speed accordingly.

04-04-2013, 09:33 PM
Here's a new video! Sorry for the unstable camera work...dog was being nosey...
One other arduino sketch weak, changed the line "Rspeed = -(command.walkH)/250.0;" to "Rspeed = -(command.walkH)/50.0;"


Thanks for your help Jon! Did you add your acceleration code in the main arduino sketch, or the nuke.cpp, or somewhere else?

04-04-2013, 10:11 PM
That looks so much better! Nice job...

Roz was autonomous in my video, so it had a main sketch controlling it, including setting the desired and actual speed.