That looks better than mine… !! I was wondering which code base were you using ? I tried and as you can see from my videos it was a bit wonky… I went though the hex_cfg.h and that seemed alright to me.
In my case the servos cut out with a message:
EnableServos: Servo 15 reset due to status: Limp(1)
EnableServos: Servo 12 reset due to status: Limp(1)
EnableServos: Servo 3 reset due to status: Limp(1)
EnableServos: Servo 0 reset due to status: Limp(1)
EnableServos: Servo 15 reset due to status: Limp(1)
EnableServos: Servo 12 reset due to status: Limp(1)
EnableServos: Servo 9 reset due to status: Limp(1)
EnableServos: Servo 5 reset due to status: SafeMode(10)
If you need any help with github I would be happy to help…
That’s great that you got it working and the only real issue was the servo offsets - had feeling.
Yes I noticed that even with one leg. @kurte pushed up a change a couple of days ago that allowed you to use S/W interpolation in place of the timed moves (moveT) since we know this does not work according to the specs. The following commands were added:
A - Toggle LSS speed control
L - Toggle LSS Servo Debug output
F - Set FPS for Interpolation mode
'A" switches between using the moveT command and the S/W interpolation mode that Kurt developed for timed moves. I have tried it with my single leg and it helps immensely with the jitter.
I’m still trying to figure out github Anyway you want to do - you can just upload the file if its easier I am sure Kurt would say the same.
#define cRRCoxaPin 15 //Rear Right leg Hip Horizontal
#define cRRFemurPin 16 //Rear Right leg Hip Vertical
#define cRRTibiaPin 17 //Rear Right leg Knee
#define cRMCoxaPin 12 //Middle Right leg Hip Horizontal
#define cRMFemurPin 13 //Middle Right leg Hip Vertical
#define cRMTibiaPin 14 //Middle Right leg Knee
#define cRFCoxaPin 9 //Front Right leg Hip Horizontal
#define cRFFemurPin 10 //Front Right leg Hip Vertical
#define cRFTibiaPin 11 //Front Right leg Knee
#define cLRCoxaPin 6 //Rear Left leg Hip Horizontal
#define cLRFemurPin 7 //Rear Left leg Hip Vertical
#define cLRTibiaPin 8 //Rear Left leg Knee
#define cLMCoxaPin 3 //Middle Left leg Hip Horizontal
#define cLMFemurPin 4 //Middle Left leg Hip Vertical
#define cLMTibiaPin 5 //Middle Left leg Knee
#define cLFCoxaPin 0 //Front Left leg Hip Horizontal
#define cLFFemurPin 1 //Front Left leg Hip Vertical
#define cLFTibiaPin 2 //Front Left leg Knee
Looking at the code it simply takes it from these defines doesn’t it ? I had configured them like this in the LSS_CONFIG so just changed it here… Will this cause an issue ?
I must mention I am using the Zenta-float…Also couldn’t see any LSS driver in that code base… I guess you are still updating that…
Also I have started to split up the hex_cfg like this as I thought it was getting a bit too huge…
and in the code it would simply include the relevant .h file…
#define MKIII_AX12 //Setup for the PhantomX MKIII AX-12 based hexapod
//#define MKI_AX18 //Setup for the PhantomX MKI symmetric with orientation sensor
#ifdef MXPhoenix
#include 'MxPhoenix.h'
#endif
#ifdef MKIII_AX12
#include 'MKIII_AX12.h'
#endif
#ifdef MKI_AX18
#include 'MKI_AX18.h'
#endif
I thought it would be a bit cleaner this way… shout otherwise…
@zenta - Think I have to ask the same question as @madmax - which sketch are you using - the phoenixUSBJoystick of the float version of the sketch? Not even going to guess.
Thanks. I’m not even sure where to start other than I really hate it or just don’t get it (obviously the last…). I probably messed up my repository since I ended up downloading a zip file because I didn’t manage to fetch and pull the correct files. Github kept telling me it couldn’t be done. And now github desktop tell me the binary file has changed. How can I unsubscribe a repository and start all over again?
I really need to teach myself how the basics work.
Ones I’ve figured an easy way to please Github I can upload an update.
Ok, interesting. I don’t think my version have this function in it. What sketch is this? We really need to work on the same stuff here. First make the original phoenix code to work. Then maybe the float/Zentagaitengine stuff. My impression is that smooth and reliable operation of the servos are the most important part to solve here. Then we can continue on the (IMHO) more interesting part…
You can simply delete the local folder and re-clone the repository. CAUTION: However, make sure you backup the files folder with your changes. There are a few thing that we could do over command line git but I would need to know what status is your git repo in.
Are you comfortable with command line git. Its okay if you don’t… Even simpler is just clone the repository on your local drive somewhere else and it should be good to go… that way you will have your old folder and the newly cloned ones. Also, make sure to say to github that I am going to contribute so it will setup the remotes correctly…
I can help you offline if you would prefer. Let me know and I can walk you through if that speeds you up.
I strongly agree. I find myself using alternating between zenta-float and the LSS_Joystick one but then it gets a bit messy for me… Getting the original Phoenix code to work will be the best approach.
Sorry everyone I slept in… Dogs did try to get me up at 4am, but resisted until 4:30… Then take them out, make coffee and feed them, so now it is getting late at 5am
@madmax - the only issue with changing ids is each of the programs have their own defines. Again no big deal. Do like the idea of breaking up the cfg file.
@zenta - glad you figured out the problem was offsets. I was going to mention you might try my sketch and use the 1 command which sets all of the servos to 0 and see where they end up…
Again at some point maybe we will do some automatic ways to determine this and then store offsets somewhere. Not sure if in servo or in eeprom or…
Git/github: yes can be confusing… Most of the time now the github desktop works pretty well:
I use it on windows and occasionally on mac.
It can automate a lot of the common things. When this is installed when you browse with your browser to a git project you wish to download, LIke lets say:
There is a green button “Code” or such that if you click on gives a drop down which allows you to download a zip file. But it also then has option to “Open with github desktop”, which will open the program and allow you to download. It will ask you options… more on those if you want more…
I use it maybe differently than others, in that I have most all my github projects downloaded to my D: drive and in a directory d:/github/ …
Even if they are libraries I wish to use with Arduino… That way can find them easily… If library I then create a directory symbolic link into my /libraries/ using the command: mklink /D
Note: if you make changes in that project and wish to have them uploaded. If you don’t have write permissions, it will ask you if you like to fork it to your own repository… And if yes… is it for your own usage or to share (or some such question)…
Note: with the above github project I work closely with Mike so I added him as a contributor, so he can upload directly… Otherwise he would upload to his fork, and create a Pull Request, and then I could merge it in… More when you get to that point. Also could add you as well to this project.
Well, that was the confusing part. They all went to the correct position when using the test-sketch at postion 0. Anyway, it’s solved now.
Thanks, I’ll look more into it.
Also thanks @kurte for your tip. I really need to find a good way to organize the files. Kinda don’t like to work directly on the github files in case something mess up. I remember this was a challenge in the old days when I used WinMerge.
I get similar messages all the time, not so many though. Around 3 servos that reset due to status Limp(1).
Like I said I’ll see if I can get my files up again. I did some changes on the cfg file and some other places. I usually comment with //Zenta…
I agree with as well 100%. @kurte and I were working on incorporating the same changes that we made with the Phoenix code to the float/zentagaitengine to see how that would work. But using the Phoenix code as the starting point I think is the best approach. With only 1 leg there is only so much I can test - but not too bad.
The link you posted to the Pheonix code has @kurte’s new S/W interpolation method. It was updated 2 days ago so you may not have pulled down the updated code. Basically same thing as you have with those additional options added.
For expediency you can just upload a zip file here and @kurte and I can do the merge so it doesn’t break the new stuff.
But a quick and dirty approach that I use is fork the repository you want. Once forked, I use github desktop, to clone it the pc. Then you can edit those files to your hearts content and upload it to your fork and then you can issue a PR back to the master. If I try and use the commands I get lost.
Wondering if that was some code @cyberpalin and myself added to the test program to setup an initial offset? Maybe we need to do the same here…
Actually git/github is nice for things like this. Example looking at my LSS_Test_sketches project I know I dont have any sources changed and you can look back at what changed, lets say like in my last update to the project as you can see in the screen shot:
The red parts are the stuff that changed from and green is the new stuff…
When you have changes it will chow in the changes tab… The one it shows is how many files. Currently I have 1 which is a sublime text workspace… I meant to exclude all of those files…
But it allows you look before you leap and you look through the changes and with newer desktop, you can click on some of the changed lines and say something like undo change… You can also discard all of your changed files or specific ones and it will restore them to current ones without your changes…
Plus if things go really screwy we can always revert back to a previous version…
Now for more coffee
P.S. I like your video
This appears to be my sort of normal as well. I know in some cases I simply restart all servos and still get these…
Thanks! Just wondering… for the time being, before you post it to github will it be possible to post the configuration changes here ? Of course, if there are too many then it might be better to wait for the git update…
So many posts so not easy to see if this was addressed (so my apologies if it was), but sounds like given the friction between the rubber feet being dragged along the surface that indeed, that is why they go into overcurrent protection.
Thanks @cbenson… I suspected that. I think it might also be because of the wonky motion that the bot currently has. Once it starts lifting the leg smoothly I am expecting the cut out to stop?
Is the overcurrent protection configurable… ? I know its for safety and the values are calculated according to current tolerances etc. it may sound daft to ask this… but i thought I will ask anyways… Is it in any way because of the settings for the CH command ?
Not configurable at this time. Note there there is both a “soft limit” (if a specific current is detected over a period of time) and a “hard limit” (instantaneous current beyond a different, higher value). The CH & CL commands don’t directly relate to the safety features and honestly cannot recall if the CH or CL modifier value is set higher than the protection value if the servo will go into safety mode, or stop at the max below the limit.
Once it starts lifting the leg smoothly I am expecting the cut out to stop
The IK needs to be done in such a way that the foot doesn’t drag along the surface and instead only rotates slightly. If the servo is in safety mode, it won’t stop and needs to be reset. This is done to ensure that the user takes a look to see what may have happened to cause the issue.
That reminds me. I most certainly think we need the following.
Power on/off switch for the servos. In events when the servos are drawing too much current or hitting each other it is very good to have a cut out switch. Pulling out the XT connector each time…is prone to breaking that board. What specification switch should we get ? I don’t know what is worst case current draw for 18 servos. Any values ?
Teensy reset button. I am sure it is there somewhere but I cant seem to see it working. Is it the switch marked ON/OFF which is a smallish pushbutton switch ?
Interesting question about a power switch. Currently there is no specific hardware which can connect / disconnect the battery. It can be an intermediate board with XT60 IN and OUT (connected by wires in order to access it via the frame) which includes a switch and a fuse, but no design yet. Would not be hard at all to design, so open to opinions. Regarding the current rating of the switch, it would need to be useable on a robot of up to 24 HT1 servos, so ballpark 20A to 30A? In all likelihood a lot lower, but since it’s a modular system, it’s hard to know what all users will do. Not easy to know how many will draw stall current simultaneously and under what situations.
Again I know that this is a Robot shop issue on if they ship kits, how will they equip them. Currently with the board of mine, I did not add anything on it as the Shield is in control of the power to the servos…
At a minimum I would suggest a simple battery wire harness which connects up. Sort of along the line that the Lynxmotion kits shipped with: http://www.lynxmotion.com/p-497-wiring-harness-battery-connector.aspx
But of course these are for different battery types and they are setup to go to screw terminals, like that were on the SSC-32.
On some of my own boards for other servos, some were sort of modeled with the Trossen Arbotix Pro boards which were based off of robotis CM??? boards, where you have an IO pin of the processor that goes through Transistor(s) to turn on or off the servos…
Sorry the teensy actually does not have a reset button… It has a Program button and an On Off. I think there are some hacks to make the on/off to work sort of like a reset.
As for how much current their servos can max out at… Never tested them so hard to say.
But again I assume RobotShop will probably have some standard option for controlling the power.
Both limits are the same system. The “hard limit” simply causes the counter to exceed the limit instantly instead of building up.
The higher the current the faster this counter is incremented. When the current is lower than the soft limit the counter decreases. If the counter exceeds the limit it goes into safe mode (error code: current).
Well, the hard limit will always trigger no matter what. That being said, it is not monitored anywhere near as fast as the control loop (~5 ms period), so it seems reasonable a CH or CL command could trigger a hold/limp before the safety mode is triggered even if a large value is desired.
I’d say for safety aim for 3A x servo (no matter the model). That way even if the worse happens (all of 'em starting spiking roughly at the same time) you should be able to switch it off safely. As Coleman said though, it is unlikely you’ll ever reach that current on many servos, especially in a hexapod setup where for that to happen I imagine you’d need very special conditions/positioning.