Have you considered using the kangaroo as a servo in servo mode? I did a live hack for it because I find it’s a better alternative rather than querying position and trying to control it through script.

Tevans did this older tutorial: https://synthiam.com/Community/Tutorials/Sabertooth-Kagaroo-DC-motors-as-Servos-16229

and I did this live hack: https://synthiam.com/Community/HackEvents/Dimension-Engineering-Sabertooth-Kangaroo-19484

Hmmmmm... forgive my ignorance but would servo mode be able to achieve continuous rotation as well as a homing ability?  If so, then yes, servo mode may be preferable.  I saw your live hack!  It was very informative!

I’ll have to look into that and get back to you...

Few questions...

1. what are you using for position sensor on the wheels? Encoders or potentiometers?

2. are these two motors used to drive the robot around? Like are they the movement wheels for the robot to get around the room for locomotion?

1.) Encoders

2.) Perhaps this video will help.   The sabertooth is controlling two motors independently.  One raises the periscope and the other handles the rotation.  I tuned each motor individually.  I used a mechanical stop tune on the lifter and a single limit switch tune on the rotary motor.  There is a ball bearing the rides a track within the rotary mechanism that hits the limit switch; registering home with the Kangaroox2.

I have control of the mech but I'm trying to get some insurance to be sure the lifter does not lower unless the rotary is at position line 43 (Home position).  I've had a few dome crashes where for some reason the EZB has lost track of the rotary position and lowered the periscope.  The tolerances are really tight.

This morning I noticed this link in the solution suggestion box.  I am also getting the same error when we get to the split line.  Perhaps this is also a factor.   https://synthiam.com/Community/Questions/Error-On-Line-25-Missing-String-Quotes-4978

Thank you so much DJ!  I'm always impressed when I see your participation with the community!

Hi Douglas,

I haven't really taken the time to study your problem or script. However I think I can help with "one" problem you may be having. There may be others but again I haven't looked that closely.

The one issue that I was having was with that damn "P". The Roo has a feature that mucks things up in the script when it sends the return information for position. THE Roo will return either an upper or lower case "P" depending on if the move is complete or not.  An Upper case means motor has finished it's move and stopped. A Lower Case means that motor is still moving.

Below I have attached the entire script for moving both my arms out of the torso of my B9 robot. It's important that they are fully out before anything moves because of close tolerances. Notice the sections "Find out (and print if wanted) if the P is upper or lower case" and "Defeat the P". This is where the script works it's magic to figure out which is witch and work around this issue.

I hope this helps. Please let us know. I'll study further over the next day or two.

#Move Both ARS's Out of torso
#-----------------------------------------------------------------
$Both_ARS_Extended = 0 #Sets Varable to both ARS still in torso. 0=in, 1=out
ClearVariable("$Get_Lft_Carrage_P") #Clears Variable in case it's in an Array
ClearVariable("$Get_Rt_Carrage_P") #Clears Variable in case it's in an Array

#############################################################
#This Scrit and the action it's attached to will move the ARS DC motors
#and the Wrist Servos.
#Do not use below commands to center DC Elbow motors. They will stay centered when
#when stored in the Torso. They were centered in the "Both Ars In" Script.
#Sleep(50)
#uartWrite(2, 0, "1,P"+$Rt_Elbow_Center, "s100", 0x0d) #Move Rt Elbow Motor
#Sleep(200)
#uartWrite(2, 0, "2,P"+$lFt_Elbow_Center, "s100", 0x0d) #Move Lft Elbow Motor
################################################################
Sleep(100) 

uartWrite(2, 2, "1,p845 s662", 0x0d) #Move Rt ARS Carrage full out
Sleep(50)
uartWrite(2, 2, "2,p845 s662", 0x0d) #Move Lft ARS Carrage full out
Sleep(1250)

# ------------------
# Loop to Read & send ARS position info for Waiting Automation Arm
# Script so it can safely start moving arms when ARS is fully out.
# The following will get the position of the LFt & Rt ARS Kangaroo positions

# --------------------

:Wait_ARS_Loop

# Get Right ARS Roo Position
uartWrite(2, 2, "1, Getp", 0x0d)

:waitFor_Rt_Data
Sleep(30)

$y = UartAvailable(2, 2)
# Sleep(30)
# print("Bytes in buffer:" + $y)
if ($y < 6)
  # Go back and wait for data again because we did not receive the least number of expected bytes.
  goto(waitFor_Rt_Data)
endif

$Get_Rt_Carrage_P = UARTRead(2, 2, $y)
# Sleep(30)
# print("Received:" + $Get_Rt_Carrage_P)
Sleep( 50 )

# -------------------------------
# Find out (and print if wanted) if the P is upper or lower case.
# Upper case means motor has finished move ans stoped.
# Lower Case means that motor is still moving.
$P_or_p = GetCharAt($Get_Rt_Carrage_P, 2) #Assign a variable to either a capitol P or Small case p returned by Kangaroo.
# Print("P_or_p:" + $P_or_p)

# -----------------------------
# # Defeat the P_or_p because it must die!
if ($P_or_p = "p")
  $Rt_Carrage_Position = Split($Get_Rt_Carrage_P, "p",1) #1,pXXXX is returned. Get everything after the Lower case p (P is case senceitive).
ELSEif ($P_or_p = "P")
  $Rt_Carrage_Position = Split($Get_Rt_Carrage_P, "P",1) #1,pXXXX is returned. Get everything after the Upper case P (P is case senceitive).
endif
Sleep(100)

# --------------------------

# Get Lft ARS Roo position
uartWrite(2, 2, "2, Getp", 0x0d)

:waitFor_Lft_Data
Sleep(30)

$y_lft = UartAvailable(2, 2)
# Sleep(30)
# print("Bytes in buffer:" + $y_lft)

if ($y_lft < 6)
  # Go back and wait for data again because we did not receive the least number of expected bytes.
  goto(waitFor_Lft_Data)
endif

$Get_Lft_Carrage_P = UARTRead(2, 2, $y_lft)
# Sleep(30)
# print("Received: " + $Get_Lft_Carrage_P)
Sleep( 50 )

# -------------------------------
# Find out (and print if wanted) if the P is upper or lower case.
# Upper case means motor has finished move and stopped.
# Lower Case means that motor is still moving. We need to know so we can move past this to the rest of the script.

$P_lft_or_p_lft = GetCharAt($Get_Lft_Carrage_P, 2) #Assign a variable to either a capitol P or Small case p returned by Kangaroo.
# Print("P_lft_or_p_lft:" + $P_lft_or_p_lft)

# -----------------------------
# Defeat the P_lft_or_p_lft
if ($P_lft_or_p_lft = "p")
  $Lft_Carrage_Position = Split($Get_Lft_Carrage_P, "p",1) #1,pXXXX is returned. Get everything after the Lower case p (P is case senceitive).
ELSEif ($P_lft_or_p_lft = "P")
  $Lft_Carrage_Position = Split($Get_Lft_Carrage_P, "P",1) #1,pXXXX is returned. Get everything after the Upper case P (P is case senceitive).
endif

  # ------------------------------
  # The following will loop and read both of the actual ARS carrage positions
  # until both carrages are full out past 700 (830 is actuallu full out but
  # this starts the anamation a little early to take away any delay).
Sleep(150)
if ($Rt_Carrage_Position < 700 and $Lft_Carrage_Position < 700)
  Goto (Wait_ARS_Loop)  # Go back and do this again because carrage is not fully out.
ELSEif ($Rt_Carrage_Position >= 700 and $Lft_Carrage_Position >= 700)
  $Both_ARS_Extended = 1 #Rt Carrage fully out. Set this variable so waiting Automation Script knows carrage is fully out.
endif
  # Arms should now be fully out and arms can safely move.

Thank you so much Dave!  I'll take a look this evening.

Ok, a little progress..

I was able to integrate Dave's new script but I'm still getting this error in the console.  I think it has something to do with the EZB receiving "2,P43\r\n" when I only need the number 43.

Good News = taming of the "P or p" Bad News = Line 40 boogers it up.

Start
> Bytes in buffer: 4000
> Received: 2,P43\r\n
> P_or_p:P
> Error on line 40: Missing String Quotes or Invalid Expression at index 0: "
Done (00:00:06.2483586)

Here is my script.... (I notated line 40 near the bottom for easy identification since that is the line throwing it off.)

#Rotary position should be 43   Rotary Home position Kangaroo is shooting for
$GetP = "Getp" # Command to get position from Roo

uartWrite(2, 0, "2, Getp", 0x0d)

:waitForData

$x = UartAvailable(2, 2)
print("Bytes in buffer: " + $x)

if ($x < 6)
  # Go back and wait for data again because we did not receive the least number of expected bytes
  goto(waitForData)
endif

$Get_Rotary_P =UARTRead(2, 0, $x)
print("Received: " + $Get_Rotary_P)

Sleep( 1000 )

# -------------------------------
# Find out (and print if wanted) if the P is upper or lower case.
# Upper case means motor has finished move ans stoped.
# Lower Case means that motor is still moving.
$P_or_p = GetCharAt($Get_Rotary_P, 2) #Assign a variable to either a capitol P or Small case p returned by Kangaroo.
# Print("P_or_p:" + $P_or_p)

# -----------------------------
# # Defeat the P_or_p because it must die!
if ($P_or_p = "p")
  $Periscope_Position = Split($Get_Rotary_P, "p",1) #1,pXXXX is returned. Get everything after the Lower case p (P is case senceitive).
ELSEif ($P_or_p = "P")
  $Periscope_Position = Split($Get_Rotary_P, "P",1) #1,pXXXX is returned. Get everything after the Upper case P (P is case senceitive).
endif
Sleep(100)
Print("P_or_p:" + $P_or_p)
# --------------------------

# This is if/endif is line 40 in the console
if ($Periscope_Position = 43)
  goto(CenterDown)
ELSE
  goto(Centerup)
endif

:CenterDown #If Rotary is at correct position than lifter will lower
uartWrite(2, 0, "1, P798 s600", 0x0d)
Sleep(4000)
uartWrite(2, 0, "1, Powerdown", 0x0d)
Halt()

:Centerup #If Rotry is in the wrong position then lifter will rise
uartWrite(2, 0, "1, P1 s600", 0x0d)
Sleep(4000)
uartWrite(2, 0, "1, Powerdown", 0x0d)
Halt()

What does the hive mind think?

I gotta think about this. I remember having an issue like this. I think it had something to do with the place where the statement is split. I could be wrong but in the mean time try splitting it in one or two characters over. This level of coding is a little hit or miss for me. LOL

$Periscope_Position = Split($Get_Rotary_P, "P",1) 

Hmm, it's real annoying to parse text, which is generally always an issue in situations like this.

I have to say, that r2d2 dome is stunning - like, really really stunning! I'm so glad you shared the video because it made my day

As for the suggestion of turning these kangaroo instances into servos... If you're using encoders, and the kangaroo is also giving position feedback... sounds like you're one step away from becoming a servo. I believe letting the kangaroo handle the positioning will be great.

I do not recommend configuring as a continuous rotation servo, as a continuous rotation servo doesn't have positioning accuracy.

My recommendation is to rewatch that live hack and configure one of your kangaroo instances as a servo. I really do think it'll do what you're looking for and add that extra sense of security nothing buggers up. Then, you will be able to move the components with simple servo commands, or use any servo control

It'll be neat because with the camera, you can have the dome track people or colors and objects, etc... All because it'll use the servo control

I've always wanted to try to try the servo option on the Kangaroo and give it a go with ARC's servo commands. I did try it once a long time ago and couldn't get it to work properly. I think it was back when the V3 EZB was out. I didn't have the patients at the time to keep working on the issue. I need to give it a go again.

Dave - have a look at the live hack. Here's two useful links..

Tevans did this older tutorial: https://synthiam.com/Community/Tutorials/Sabertooth-Kagaroo-DC-motors-as-Servos-16229

and I did this live hack: https://synthiam.com/Community/HackEvents/Dimension-Engineering-Sabertooth-Kangaroo-19484

Thanks DJ. I did see those links in your post earlier in this post. I do intend to check them out.

Thank you for the compliment DJ!  R2 has been an 8 year project and runs on two (soon to be three) EZBv4/2s.  I've never parsed a text.  What's the trick?

I've thought about the servo control route but I don't think I could get it to do this with regular servo commands.  That's why I asked about the continuous servo.

Dave, I'll try your code suggestion too.  Thank you!

I think you still could a regular servo - because with the kangaroo utility, specify that 180 degree position has actually rotated two or three times around.

It's kind of like using one of those 1000 degree winch servos. The output shaft rotates many more times between the 1-180 degree position command. You see, the command of what position to be in (i.e. 165 or 135, etc) is really not a degree. It sort of works out to a degree with a regular PWM servo, but it doesn't need to be. Take Robotis Dynamixel servos for instance. they go from 1-1023, which can be 180 degrees... where 1 is 1 degree and 1023 is 180 degrees.

So in your case, ARC's 180 degree would really have been 1000 degrees or something on the output. Does that make sense?

I know it's a different way to do it - but once you accomplish it and it clicks. Then suddenly it'll open up doors to many more servo-like motor configurations you can do with the kangaroo+sabertooth. It means less code (well, practically no code)

The disco mode is awesome! I love it. It blows my mind.

Thank you DJ!  I'll save this DEScribe profile and create a new one to try it out.   First out, I can see and advantage to simp serial because I can use the home command to essentially reset the encoder output which keeps me from having to basically unravel the animation to get the rotary back to the home position.  Unless, of course, there is a way to reset from the home position within a servo command.  Right now I have the rotary going to position 6000 and homing (which wipes out the 6000) then it goes -6000 and homes before it drops.   Doing it by servo would be simple because I can just sleep and then have it reverse to the starting point for this animation.   Now, if I want it to go to position 6000 and drop without traveling back to origin, that's where I would need to reset the servo position so I could start another animation without having to unravel the first.  Does that make sense and is it possible?

Dave, thank you for the compliment!

Please keep us posted on your adventure. I'm very curious to see how it works out for you.

I'm just tossing this around in my head; my concern (like you) is getting the motor back to "Home" or a certain exact spot. We need the arm (or in your case, a periscope) to safely retracted into the body of the robot. With the Roo in "Position and Speed mode" it uses the encoder to first Home to know exactly where the motor is positioned. We then can park the appendage in the exactly position once the animation is completed. With servo control, theoretically, once set up in the proper position, we can return the servo back exactly to that spot. When we again restart the animation and the servo hasn't settled or moved, ARC will assume it knows it's position on the next start up and all will be well. The problem is "what if" the servo has moved when powered down? How do you get it back to the exact parked position before sending it out on it animation adventure? The servo will park where it started out and may not now be in alignment with the hole it needs to enter. Disaster and destruction will ensue as everything gets sucked in. One thing I tried was to install a limit switch to let ARC know the arm is centered. If not it would not retract. However then I had a arm sticking out that I needed to manually retract.

I'm very interested in how you overcome this. I really want to start using ARC's servo commands instead of Simple Serial. So much simpler.

Dave,

You hit the nail on the head.  The animation mounting system that I created is modular and allows the user to mount hardware magnetically onto a plate that is also the seat for R2’s dome.  The periscope you see is magnetically seated on the plate and can be literally pulled off for maintenance and traveling to philanthropic venues and conventions.  So this module’s motor system is absolutely going to shift during transport.

Unless ARC can use a limit switch to reassign home servo position, I don’t know how else it can be accomplished outside of    simp serial.

Heres a link to my YouTube channel so you can see the Warp Core Base Plate I created for the Warp Core Dome System.

https://youtube.com/user/Warpcell

The kangaroo handles the positioning - and the kangaroo also has input for limit switching. The idea of the kangaroo was to make anything a servo. They did a wonderful job at the design. So you would connect the limit switches to the kangaroo, not the ezb. And it would calibrate itself on startup to know the position.

from: https://www.dimensionengineering.com/datasheets/KangarooManual.pdf

Hi D.J.,

The rotary motor has a single limit switch that I use to register the home position when sought out by the home command.  Are you saying there is a way to use servo commands to seek out and find the home switch?  For example, when I send a movement command in serial (2, p3000 s2000) to the Roo, it takes a few revolutions to get there and the Roo ignores the limit switch every time it hits it.  Yet, if I send the home command (2, Home) the rotary moves until it hits the switch and at that point Home is re-established and the p3000 is cleared as the home is now P0 no matter how many revolutions it took to get there.

Presently, if I tune the Roo with the limit switch in servo mode, the switch will register as position 180.  This effectively limits the rotary to a single rotation.  A mechanical stop tune may be better but I would need to literally grab the periscope at certain points during the tune to establish the end points of the rotation because currently there are none.  A Teach Tune is not possible due to the gear ratios within the rotary mech.

That would be super awesome if a servo command can take the place of the serial commands.  However, the Roo does not currently calibrate at setup.  It only calibrates during the initial Tune.  Currently, I have launch commands upon connection that start the baud rate, start the motors, raise the lifter, home the rotary, all before lowering the periscope into the dome; all done in simple serial.

Does that make sense?

Thank you,

Doug

Oh, so the rotary motor has a limit switch that you're not able to use because you want multiple rotations of the output?

If so, we'll have to not call it a limit switch. If that's the case, then yeah we can't use it at all.

So I'm not sure how the "servo mode" works with the kangaroo when using an encoder and the shaft is moved without power on. How does it recalibrate itself. I did read that it can recognize rubber stoppers because the current is monitored.

That’s a good question.  The Roo has serial commands to initialize and home which has to be done whenever the system power cycles.  There are no commands for that in servo mode, that I know of.   In any case, here’s a video I made to explain it.    The other advantage reason I need the condition is to ensure the periscope doesn’t rotate prior to being raised.   That can cause a real mess.

First I gotta say wow. What a beautiful work of craftsmanship and engineering.

You are working on the same problems I was when I built my B9 robot arm. If the arm retracted into the torso without being completely centered then it would hit the arm hole and stall. Thank God the Kangaroo detects the stall (or runaway) and stops. However I found damage can still happen to the structure or motors.

The only solution I could come up with was to add a center switch that was monitored by an ADC port on the EZB. I had the main animation script wait and check that switch ADC voltage first before the arm was allowed to retract. If after sending the command to center and retract and that switch was not closed it would not retract.

A few things I didn't like about that solution; *One, I had to come up with a second animation script that would start up automatically (using If/Else If commands) upon failure that trys to re-center the arm and close that switch.  *Two, there was a pause while the script checked that script.  *Three, the animation took longer then wanted if centering failed.  *Four, If the arm couldn't ultimately find center I had to park the arm manually with ARC movement controls.

I wish I was in the position and had time to work on this here on my robot along with you. However I'm currently neck deep in another project I can't stop. However finding a solution to this issue or better way to command a Roo may help make my current project more elegant. I'll stay tuned. Please keep us up to date. I'll help if I can and learn from you along the way.

Thank you so much Dave!   I really appreciate the information you shared.  The Roos Getp command is specifically there for a conditional script.  Perhaps DJ can help us get the position registered to be digested by ARC.  I’ve added an extra home command to my scripts but it’s a poor substitute for an if/elseif scenario because the lowering script still assumes the rotary is in the roper position with no way to verify it.

The servo feature of the kangaroo is meant to create the protocol for ARC to integrate with. I'm not quite sure how to do it otherwise, because the ascii GetP commands don't relate to servos at all.

Have you loaded the kangaroo software and read the manual? Let me ask questions because i think there's a lot of information in this thread that I'm missing. I'll ask more questions per each response.

1) When you power-on the robot and query GetP, what does GetP return? Is it a 0? I'm not asking about your initialization script or anything. Just when you apply power to the kangaroo, what does GetP return

Cool!

2,E1\r\n       If requested after initializing baud rate but before homing

2,P43\r\n     if requested after initialization of baud rate and after homing

And here’s what the manual says it is....

Get position. (Getp) : Returns the channel number, followed by a comma, followed by a capital P if the move is completed or a lowercase p if the move is still going on, followed by the position in units (plain text) followed by a return and a newline

Ignore . Bad idea.

I and a friend have figured it all out!    I’ll post the code tomorrow.   We were able to isolate the data we needed and even add tolerances. We now have it successfully working.  He is also going to help me streamline a function command of sorts.

Thanks! Next questions...

2. Does "homing" use a limit switch or something? How do you know what physical position "home" is? Is that simply using the encoder or is there a switch of some sort that you use?

3. Can you send a command that moves the rotation into a specific degree? If it starts at 0, and home is 43, can you say "Go to 519"? Or do you tell it to move, keep monitoring the position yourself, and then tell it to stop?

Well, here's the solution!  This has been working great and hasn't missed a beat.  cool

Dave, this could easily be adapted for your application!  Once we emptied the UART we could consistently cut out the data we needed from the returned Getp data.  It kept building up in the system.  Also, the "/r/n" at the end of the data (2,P43/r/n) is only considered 2 characters.

The following code reads the rotary motor position for authorization to lower the periscope.  It has a tolerance of 1 line in either direction otherwise it will raise the periscope to prevent it from crashing into R2's dome.

DJ, thank you for starting the trouble shoot.

#------------------------------------------------------------
$GetP = "Getp" # Command to get position from Roo
$Periscope_Home = 43 #Rotary position resulting from sent home command
$Periscope_Tol = 1 #Tolerance in either direction for proper clearance when lowered

#Rotary is channel 2
#Lifter is channel 1

UARTReadAvailable(2, 0) # Empty UART
uartWrite(2, 0, "2, Getp", 0x0d)
#Print( "A" ) 
#Sleep( 1000 )
#print("B")
:waitForData
$x = UartAvailable(2, 0)
#print("Bytes in buffer: " + $x)

if ($x < 7)
  # Go back and wait for data again because we did not receive the least number of expected bytes
  goto(waitForData)
endif

$GetP = UARTRead(2, 0, 5)
print("Received: " + $GetP)

# Spit required data from returned string while removing first and last junk characters 
$chan = Split($GetP, ",", 0)
$contents = Split($GetP, ",", 1) #Temp value
$len = Length($contents) 
$Periscope_State = SubString($contents, 0, 1) #P is stopped
$Periscope_Position = SubString($contents, 1, $len-1)

print("Position: " + $Periscope_Position)
print("State: " + $Periscope_State)

Sleep( 1000 )

# Send script to proper subscript depending on if position is above or below center using ABS to negate
if (Abs($Periscope_Position - $Periscope_Home) <= $Periscope_Tol AND $Periscope_State = "P")
  goto (CenterDown)
ELSE
  goto (Centerup)
endif

:CenterDown #If Rotary is at correct position than lifter will lower
print("CenterDown") 
uartWrite(2, 0, "1, P798 s600", 0x0d)
Sleep(4000)
uartWrite(2, 0, "1, Powerdown", 0x0d)
Halt()

:Centerup #If Rotary is in the wrong position then lifter will rise
print("Centerup") 
uartWrite(2, 0, "1, P1 s600", 0x0d)
Sleep(4000)
uartWrite(2, 0, "1, Powerdown", 0x0d)
Halt()

Brilliant! Nicely cleaned up compared to my script. I will defiantly edit this for my script and use it.

Thanks for all your work and sharing this!

Do you have any thoughts on how to proceed if the periscope does not lower because it didn't line up? Perhaps you could have the script check it the periscope successfully lowered or stopped? If not try the parking sequence again?  Of course you don't want the thing to be spinning around if it has only partially retracted into the body.

Have fun and thanks again!!

Oh yes!  This is just the base code.   I can change the motor channel and reverse engineer it for all sorts of conditions.  I’ll be modifying it to check the lifter position prior to rotation.  For example, I can add a rotary home command and then a rotary position check prior to lowering the lifter.   The same technique can be modified to have the rotary check the lifter position prior to rotating.  This will avoid internal crashes within the dome.

The fun is just beginning!

Outstanding. I agree, loads of fun. It's amazing how a small script like this if done right can help you throughout your whole project.Please keep us up to date on what's happening. I love this stuff.

Dave,

Are you on astromech.net?   Would like to exchange emails for future collaboration if you like.  I don’t see a way on this site to send you a private message.  If you want to see some robotic hobbyists strung out on Star Wars, astromech is a free community working directly with Disney through our 501c3.  We supply the droids for a great many of their events and projects.  You are welcome to join.  I am Warpcell on the site.

Hay @dbickert, somehow I missed your last post.

Yes I am on astromech.net but I haven't signed on for many years. I cant even remember my ID. I think it's simply "dschulpius". Lots of other stuff has captured my interests. Back then I was dreaming what my next robot build would be. Turns out the B9 robot building universe was and still is capitalizing my time and money. LOL. I'd love to one day build a full sized R2 or even a Robby the Robot from Forbidden Planet.

It would be great to swap ideas with you ay any time. My email that I share freely is dschulpius@gmail.com. Looking forward to hooking up.

When I get my next free moment that is not in demand I'll look you up on astromech.net.

Yes.  You are correct with your astromech ID.  I was able to find that call sign on a member search.  I'll send you an email.

Thanks again!