Dr_Goddard

Here's what happened in sequence. code was working on 15.4 code broke on 15.5 with an error "cannot index..." SET FLext TO SHIP:PARTSTAGGED("FL Extendatron")[0]. ^ so I thought, there is only one instance of the "FL Extendatron" and maybe it doesn't need to know the list is just one item. resulted in line: SET FLext TO SHIP:PARTSTAGGED("FL Extendatron"). Which produces the error I posted, so I think you are correct. Now the problem is why won't it process this line? SET FLext TO SHIP:PARTSTAGGED("FL Extendatron")[0]. I'll put the code back and get a new log file with the previous error. - - - Updated - - - Oh krap. I re-installed kOS and pulled up a backup script and everything works now. Herp-derp. Thanks.

Nice job on the DOCS site, very professional. - - - Updated - - - 15.5 and 15.5-2 versions seem to have broken my kOS IR integration script. list:GETMODULE() returns an error saying ...get suffix 'GETMODULE' not found on object list... I'll attach a screenshot of the error. - - - Updated - - - Here's the log file. http://pastebin.com/yUbBgCMu

Craft http://pastebin.com/SsWnDeq6 Installed Mods http://pastebin.com/rh5R3kA6 Deploy Script example http://pastebin.com/ywWtqN1L Seek Script Routine http://pastebin.com/t7jx94k9 Most of what you need to know is in comments in the seek.ks script. - There was an error on line 21 in the seek code. Just comment it out or delete the line if you have that version it was added at one point for debugging and has been driving me crazy until I just noticed it now.

Not at all. I will put up the machine and the code in the AM

I wrote a routine to convey a simple two variable command through a "run" command. It seemed easier than programming all the routines each time. Maybe a bit more intuitive as well for robotics. Each device(or set of devices) is now called by a number and an angle. I'm trying to figure out the best method now for coordinated movements, which are probably going to be proportional. run seek(0,0). run seek(-45,4). run seek(45,5). run seek(30,1). run seek (30,2). run seek (180,3). run corners.

Looking Good. I created a routine to make the joints act like servos. The script to make these movements becomes: run seek(0,0). run seek(-45,4). run seek(45,5). run seek(30,1). run seek (30,2). run seek (180,3). run corners. Hope you like it.

I have discovered there is a benefit to manually editing the .craft files when building robotics. Especially when you want mirrored or coordinated movements. I tried to place all the legs and joints accurately in the VAB, but there is usually a bit of error. If you look at the first video above, you can see the legs extend in an uncoordinated fashion. This is due to less than .02 degrees in positioning error before beginning the acceleration algorithm. In the latest video, I cleaned up the "module" sections of the .craft file so all the legs were the same, and the resulting change in coordination is evident. I'm trying to get my programming to a point where I can demonstrate some more advanced movements. This is a bit difficult since kOS has pretty limited support for keyboard input to programs. I have a plan to fix this, so I'll trot out some better demos soon.

Ok, I got it. After monkeying around with the .craft file for a while I was able to see it was a matter of symmetry. But ONLY SPH symmetry will do it. If you want the rotations to move in opposing directions in a MIRRORED fashion you have to install them as pairs in the SPH editing mode. I used editor extensions to do it in the VAB.

Here is the result of not inverting the axis. One side is rotated clockwise. The other counterclockwise. Notice they end up at different rotations. If you invert the axis on one side, you get rotation all in one direction per the video. But they end up rotated the same number of degrees. I've done a few tests and it comes out the same no matter how you build it. It seems like I need an actual clockwise rotating and counter-clockwise rotating version. The method used is like the device is flipped over to reverse it. I want the rotational scales to count in opposite directions.

Here we go. What I want is for the left and right sides to swing in opposite rotations. It is doable in code, but very complicated. Would prefer not to have to code it every time for every rotation. Problem is, with all the legs stowed. the legs on one side are 180º out of synch with the legs on the other side. So, I am faced with making different checking routines for each side. I think It might be solvable by rebuilding the rover in the spaceplane facility and avoiding symmetry. I'm going to give that a try later today.

It's possible to do both with IR and Kerbal Operating System. Cool cyclic pitch BTW.

Hey Sirkut, I am making a six legged "athlete" style rover. i'm using rotatrons at the base of each leg, allowing me to stow/unstow, and perhaps eventually insect walk. using the new Kos code to control the parts by addressing them directly. One problem. Rotatrons on opposite sides move in opposite directions, so when they are stowed by rotating them in the VAB they are 180° out of sync at launch. reversing the direction on one side fixes the problem, but then the legs all rotate in the same direction rather than opposing directions.I don't know right now if I can describe it better, as I'm pushing a 101° fever. I think I want to be able to adjust the mid-point for rotation. I'll post a video later.

Awesome! Thanks Sirkut, we are back in action. Installed the wrong tablet driver last week and the cursor would sometimes fly off the screen. That was it!

Problem since install of KOS 0.15.1, Toolbar for servo control will not appear. I reverted to older KOS, problem remains. Disabled all but IR mod. Problem remains. Deleted persistence file... problem remains. Cleaned, re-installed IR and modulemanager... problem remains. I haven't tried a complete reinstall. but that is next. log file: http://youtu.be/peZt5IwRFaM

It's entirely possible I am just stupid... when I launch my KOS and IR robot I can't access IR in-game controls. Editor still works. Edit: yes, it was me being stupid. The window was appearing out of range.

Took a longer look at the code and method. It's very good, I can see how this will be a boon. I'm really intrigued with the possibilities offered by the laser distance device. Obviously we could use it as a proximity sensor. I wonder if a small array could give us an effective horizon detection and perhaps a bit of forward vision... Will the device measure the distance between parts on the same craft? P

Done that. But the laser distance check would be a handy shortcut.

Hah! I have it. I don't know how well it will work, but a form of proportional control could solve the problem of limited action groups, when controlling IR with Kos. Imagine you have to control 6 legs independently. you need 6 action groups for up, 6 for down, and 6 for neutral. That's 18 just to control up and down, and you only have 17 if you steal action groups from canned actions for gear and stage etc. Your Kerbals aren't going anywhere today. But imagine I slice the actions up into little timed on/off segments. Now I just need to invoke down as a single action on all the legs, 50% of the time for example. I counter that with an action group up on each of the legs that can be varied in length. Then I add a single action for neutral for all the legs (with programming that limits the impulses for the other actions). Now I've accomplished the same control with just 8 action groups. I can do the same thing for cyclical movements of the six legs to make it crawl like a bug. Since neutral is common, this added action will only take 7 action groups. I have 2 left!!!

Hey Sirkut, still plugging away here. Awesome work on the robotic arm dev. I'll be looking forward to giving it a try. Meanwhile, I've been working on my Nasa Athlete rover model. It occurred to me that now with the in editor positioning working, it might be possible to create movement routines within the ship editor, in a manner similar to the way industrial robots are trained. I haven't thought it through much to be honest, but imagine if you set the robotics to position A and save, then set to position B and save, and within the game you could invoke posA and posB with hotkeys or action groups. Most robotics make use of canned operations, unlike free manipulator arms. Something to think about maybe?

Closed loop would be nice. What is really needed is a few touch sensors, just like micro-switches... so you could tell when your robotic device has made contact with something. As it is, we can only move blindly, or interact through a reaction like sensing when the device is stopped by an object, or when it's tipping over. My latest challenge is to develop a PID for my Nasa Athlete model. It turns out steering and driving around is a cinch. But making it level itself on hills will be a real challenge. Oh, and wheels! When is someone going to make some wheels that mount on a vertical pinion? I'm going to have to model some myself I think. Cheers! Good work guys!

LOL. What don't you get about springs? Thank-you for your advice. I think I did all that stuff, but in fewer words. Here's a model I'm working with. http://imgur.com/SXNm7Af

It is my intention to make springs, shock absorbers, and freely rotating hinges and joints to complement robotics and add part variety. Wish me luck! I know practically nothing about programming or mods, but I learn quick.

If you eat your cake, you won't have it any more. I am thinking about how to make a telescopic damping strut. It would accomplish much of what a strut does, but could be arranged with a hinge at each end, and still be flexible enough to allow for movement. Kind of like a Macpherson strut suspension in a car.

The legs actually run on fuel and oxidizer. It saves electricity and is remarkably efficient. ?! TBH it just needed something to look right. Imagine it's not a real machine, and we are just pretending to land on the Mun.

Works fine on the Mun. It was pretty hairy for a second, but the levelling soon caught up, and with just a short slide and a little hop, here we are. Thanks to k-OS and IR!