Welcome to Synthiam!

Program robots using technologies created from industry experts. ARC is our free-to-use robot programming software that makes features like vision recognition, navigation and artificial intelligence easy.

Get Started
Asked — Edited
Resolved Resolved by irobot58!

Lumpy, Lets Compare Notes On Kangaroo X2 Please

Hey Lumpy (or anyone who can advise). I'm addressing this first to Lumpy because I know he is using and working with the Kangaroo X2 / Sabertooth setup. If anyone has some insight please chime in.

Anyway, as mentioned in other posts I'm working through issues with my Kangaroo X2 / Sabertooth setup where I'm using two DC motors that have pots for feedback and limit switches. I now have both motors responding through serial commands from EZ Builder. I had an issue where I was continually getting error codes at power up and would have to power cycle the unit to get it to respond to serial commands. However I found I had to make sure the Sabertooth/Kangaroo powered down completely when the robot and EZB was switched off and then powered up after the EZB was powered up.

My issue now is trying to get the speed ramping feature of the Kangaroo to work. There are different ways to set up the Kangaroo; Velocity or Position control. I cant get the speed ramping to work when serial commands are sent from EZB in either control setting. However, I can get ramping to work nicely in Velocity but not Position tests when using the "Live Test" section of the Describe software used to set up the Kangaroo. When doing these test I'm attached directly to the Kangaroo with a Serial Adapter from a USB port of my laptop and EZB is not connected.

Without any ramping my motor will jerk to full speed and stop suddenly. I've e been working with Dimension Engineering on this for weeks but it's been painfully slow. The only way I can get help from them is through e-mail and it sometimes takes days for them to respond. Then I'll get a one sentence question or answer like "sounds like you need to make sure to upload your settings and reboot" or please send us a copy of your settings. This must be a newer product with limited users. I've found no community forums and few people posting info on this board.

One other thing. What is the best way to set servo control to work independently on the Sabertooth/Kangaroo's second motor channel? So far the only way I've been able to get it to work is if I start the first motor Chanel with a servo command and don't release it. I am using a second cable attached to a second digital port on EZB and attached to S2 of the kangaroo. I'll call that port when I want motor 2 to respond to a servo command.

I must say it is a great little board and from what I've been able to set up, it works great. I like the idea of being able to send servo commands to control my DC motors. Very precise and quick. If I can get this speed ramping issue figured out it will be an excellent addition to my B9 robot motor control.

#17  
Humm, that's a cool idea. Maybe some day when the team get more time they could look into this. IMHO ramping is an area that really needs to be addressed not only with EZ Robots but with other companies that provide motion control boards. It seems like it's just an after thought or partially implemented. I may be wrong about all this but I haven't found much where this is a concern. With people now building larger and more human like robots I imaging the need to get them to move more naturally is going to be in demand. They all really should address this lack of support to stay ahead. The kangaroo does do adjustable ramping but only in Velocity Mode unless you do involved scripting that most people (like me) don't know how to do. Velocity Mode is good for RC controlled bots and cars that just drive forward, reverse and turn. I need position and speed control. DE says their Kangaroo doesn't do ramping in Position Mode unless you script. WHY?

The only way I was able to get ramping to work on my DC Motors with ARC was to send gradual increased or decreased PWM commands. That actually worked very nicely. That script looks like this:

Code:


PWM(1.D6,10)
$adcSpecified = 185
controlcommand("Move Waist", scriptstart)
Sleep(0250)
PWM(1.D6,20)
Sleep(0250)
PWM(1.D6,30)
Sleep(0250)
PWM(1.D6,50)
Sleep(2250)


To be honest I got smoother ramping with simpler EZ code (as seen above) then I am getting with the Kangaroo script I just made over serial. I'm still not really convinced my new setup using the Sabertooth/Kangaroo is better then what I had with a H-bridge and a pot attached to an ADC port on the EZB. The Sabertooth is more rugged and top quality and the Kangaroo does do all the work that EZB used to do. Added to that, I now only use one Digital port on the EZB and send all info with a serial command. Also, I can now use servo commands but I found if I mix servo commands and serial commands using the same Digital port on EZB everything will lock up and I need to reboot everything. So it's one or the other. With servo commands I have no ramping. It's all or nothing.
United Kingdom
#18  
Dave, I do not use Sabertooth or Kangaroo controllers, so have little knowledge of them, but here are some thoughts.

I guess that your main problem is not getting the position feedback so the script does not know when to start ramping down as it approaches the target position. The lack of serial comms (read) on the V3 is a real problem sometimes, but it should be solved when the V4 arrives, as it has bi-directional comms. You really need a thing called analogue PID (proportional-integral-derivative) controller see

en.wikipedia.org/wiki/PID_controller

With a controller like this using PID the motor would move very smoothly from start position to (accurately) the target position thanks to the on board PID algorithm. I use the Motor Mind 3 controllers with great success on the EZ:1 robot using serial PID control, the robot accurately moves from one location to another. Serial mode uses encoders but the mode you need is analogue (using positional feedback resistor). Here is a link to the Motor Mind 3

www.solutions-cubed.com/content/Downloads/MotionMind3Docs/MOTM3DS_6.pdf

One thing to note, I found that PID is quite complicated and very difficult to set up properly, it may be worth waiting for the V4 as PID may be a steep learning curve for you. Once you get the V4 with bi-directional comms you could roll out a simple script like

1) Extract start position value from end position value = travel_v - [example if start_pos = 500 : end_pos = 2600 then travel_v = 2100]
2) If travel_v < (min position to ramp) then goto move - what this means is that if the travel_value is to small its does not need up/down ramping
3) Calculate (say 10%) of travel_v - [2100/100*10 = 210]
4) Add this value to start_pos = pos_2 - [500+210 = 710]
5) Slow ramp-up motor until current_pos = pos_2 [710] - slow ramp_up speed from start position to position 2 (end of ramp-up)
6} Calculate pos_3 (say 90%) of travel_v - [2100/100*90 = 1890]
7) Motor full speed until current_pos = pos_3 - set motor at full speed until reaching 10% before end position
8) Slow ramp-down motor until current_pos = end_pos - slow ramp_down for position 1890 to position 2100 (end position)
9) Target position attained

In the above example the first 10% of travel is slow ramp-up with the next 80% of travel being full speed and the last 10% being slow ramp-down. The ramp up/down percentage (10% in the example) may need to be changed to suit the particular motor setup that you have.

I hope I have interpreted your problem correctly and this has been of some help.

Tony
#19  
@Tony,

Thanks so much for sharing your thoughts here. You've confirmed what I thought the problem may be. I really have been hampered by not having two way serial communication between EZB and the Kangaroo. That and the lack of good documents or active Kangaroo community forums and my lack of C++ script writing knowledge has made this a true struggle with slow progress.

Also thanks for the tip and link to the PID board. I don't think I'm up for another steep learning curve just yet so I think I'll wait for my Pre-ordered V4 EZB. Hopefully it will be here in a matter of weeks. That sounds like the natural solution. Your outline of a script will help a lot when I get back to this point.

I the mean time I'll keep plugging away. Heck, even a blind squirrel finds an acorn once in a while. :)
United Kingdom
#20  
I haven't had chance to check this topic for a while (and even now I've just quickly skimmed over it), glad the script got you going:)

On the servo commands and no ramping, you could use scripts to simulate ramping by moving the position step by step with sleep between... Something like;

Code:


Servo(D1, 10)
Sleep(10)
Servo(D1, 11)
Sleep(10)
Servo(D1, 12)
Sleep(10)
# and so on
Servo(D1, 20)
Sleep(5)
Servo(D1,25)
Sleep(5)
Servo(D1,30)
# and so on


Or if the ServoUp and ServoDown commands work with it;

Code:


$new_position = 90
$steps = 1

:loop
If(GetServo(D1) < $new_position)
ServoUp(D1, $steps)
Sleep(10)
Else
Halt()
EndIf
Goto(loop)


The above would need more work, using Tony's algorithm and some error checking along with some code to make sure that moving the servo up by $steps wont push it over the $new_position - something like IF(GetServo(D1) + $steps > $new_position).

It may be simpler than that, I will admit I didn't put much thought in to this one but the concept is the point I am trying to get across and hopefully I have done so:)
#21  
@Rich, Your best guess without much thought is a whole lot better then my hours of slight progress. I did get ramping to work like this on other applications with PWM commands. I didn't think about trying it on servo commands. Thanks once again!
United Kingdom
#22  
@Dave, with my algorithm I need to add the following, because of the lag time it takes for the EZ-B to read the position (back from the Kangaroo), it is likely that the actual position will "over shoot" when the equality checks (10% in the example) are being made, especially when the motor is on full speed (like when going to pos_3) etc. So the check should not be for equality, it should be ">" (more than), this will allow for any over shoot.

Dave, when the V4 is available, I will write this algorithm into an EZ-B script for you, if that will help.

Tony
#23  
Thanks Tony... that will help me as well. I just picked up a couple of kangaroo boards myself...
#24  
@Tony, Once more you've proved what a great guy you are. I couldnt get most of this stuff to work the way I want to without people like you offering help. I intend to learn this type of programing soon so I dont have to relay on good people like you so much. In the mean time I will gladly accept your offer of help. When the V4 arrives I'll contact you. Fit it in as your scheduel allows. Many thanks! :D

@Richard, When you start to install your Kanagroo please contact me if you like. I'll gladly share what I've learned so you dont have to struggle through what I have. It's a good PID board but documentation sucks and it seems to me that what they do have is geared towards the more advanced among us.
#26  
I just ordered C# for Dummies and C++ for Dummies off of Amazon. Free 2 day shipping so it should be here by the weekend. I really want to understand what I'm asking here and hopefully lend a hand. I know it's a complex language and will take some time to learn but at least this will give me a base and a start. Hopefully I'll be able to at least write a simple cammand to send over serial and know what I'm trying to do. ;)
#27  
If you buckle down C shouldn't be too difficult... I use EasyC for my vex stuff, but it's not C... it does spit out C pseudo code so one can see how C works as a language... However, EasyC is really just a graphical language that has almost no C programming for the user. Robot C is another Vex controller (among others) language that is nearly full blown C... That I wouldn't mind learning... I do agree with you C is worth learning.. I would learn C for no other reason than to establish a serial connection between my EZB and the Vex controller .... Maybe I should I should learn it, then...;)
#28  
interesting and informative thread, Dave I need hep with this
#29  
Hey Reed, good to hear from you. I'll be glad to help as much as I can but I'm at work right now and have a busy evening ahead of me. I'll try to get back to you on this as soon as I can. This is all thread and lots has changed since then. Good news is that the kangaroo now has built-in ramping. You do have to access the controls through the software which means you need cables connected in the proper way to your computer. It's all a little confusing and frustrating at first but once you get the hang of it it's really an awesome and easy to adjust set up. Getting into the software and making adjustments is the best way to get the best results. You will also need a good feedback device attached to your kangaroo and your motor. Pots are okay but I really suggest encoders. Once you have a kangaroo properly tuned and your ramp settings adjusted the ez script to move your motor is very easy. Just a few lines and some sleep commands and you're good to go. By the way I connect my kangaroo 2 my EZB through the serial port. That's the only way you can get feedback to the kangaroo from your encoder. I can send you any commands you will need to put in your script. Good luck and have fun. I'll talk to you later.
PRO
USA
#30  
David, at the beginning of this post, you mentioned: I had an issue where I was continually getting error codes at power up and would have to power cycle the unit to get it to respond to serial commands. However I found I had to make sure the Sabertooth/Kangaroo powered down completely when the robot and EZB was switched off and then powered up after the EZB was powered up.
I seem to be having that issues as well.  How did you resolve it?  How did you get the Sabertooth/Kangaroo to power down completely, and how did you make sure the Sabertooth/Kangaroo powered up AFTER the EZB was powered up?
#31  
This was an issue to me because my robot had a battery attached in line that kept power feeding the even after the robot's main  power switch was turned off. At that time my robot pugged into the wall and was powered through a AC to DC converter. I used that battery only for a place to dump the regeneration power created by the Sabertooth. If not used the regen power would have kicked out and possibly damaged the power supply. 

I solved that issue by placing a relay between the battery and the sabretooth that was controlled by the EZB and ARC. When the robot was powered up the relay would be in the NO position keeping the dump battery disconnected from the Sabertooth. ARC would then run a script that would close the relay and connect the two. When The robot was powered down the Relay would naturally open and disconnect the dump battery and let the Sabertooth/Roo power down.  

A much better solution is to simply buy a Sabertooth 2x32 Sabertooth. the Sabertooth 2x32 can is shipped and configured to allow it's power outputs as a voltage clamp to operate from a power supply without a parallel battery. A much more elegant solution.
PRO
USA
#32  
I guess my issue is something else then. I am just using batteries at this point. Have the EZ-B on a separate power line than the sabortooth/kangaroo.
So what is happening is, after I got the kangaroo "trained" with the limits (used teach mode), I created EZ-B scripts to set the max/min for both motors, set the initial speed, and set the initial position (which is the end/home position). Then I created a script to shutdown the robot, moving motors to the start/home position. Then I powered off the EZ-B and sabortooth. Then I turned them back on, ran the startup script, did some moving of the arms, and then called the shutdown script. Then power off. And repeated. This all worked fine. Then I powered off once more, left it off of several minutes, then powered back on, ran the startup script. Then when I attempted to move the arms, nothing happened, and the LED on the Kangaroo now flashed 3 times.
Don't understand why it worked a couple of times, and then quit working. When I re-power up, and run the startup script, all seems fine, no flashing LED, no errors from the script. But as soon as I try moving an arm, the LED starts flashing 3 times.
#33  
What device are you using for feedback? 3 flashes is a control error. From the manual:

Quote:

Control error, channel disabled. Check to make sure your feedback sources are working and the system matches how it was set up during the tune.
If you are using an encoder? You probably know this but you need to home the motor each time you restart.

If you are sitting on a limit switch on start up you will have issues. 

How are you sending your commands? Simple Serial through the Uart or servo commands? Some of my motors I have controlled by the Kangaroo I have attached to EZB's digital ports and control using servo commands. I have had issues with them nor responding if they are out of position on startup. However I don't get an error code so this is probably not your issue.
PRO
USA
#34  
I am using a gear motor with encoder. Using EZB digital ports and servo commands to send commands. Now that you mention it, I believe it might be a homing issue. The motor does seem to start to move just a bit, then quit. I believe I saw a setting in Describe control software where you can set the Origin and homing positions. I’ll take a look at that tomorrow and see what I can set/try.
#35  
If you are using digital pins with servo commands I don't know of any way to home manually. When using servo commands I set the Min/Max settings and position and speed for these Sabertooth/Roo controlled DC motors in my INT script. It seems that the motor first moves on it's own to a limit switch the first time I send a servo command then moves to it's command position. Sometimes if the motor is in the center of it's travel it wont do it on it's own. I have to send a position manually then it will find a limit switch and then proceed to the position.
PRO
USA
#36  
I think I finally got this figured out. When the Kangaroo is programmed using the Teach Mode of Auto-tune, it assumes that the start position is in the middle. So when it first powers up, it reads the PWM setting from the EZ-robot, then calculates how much/direction it needs to move the motor to get it to the PWM setting. In other words, if the PWM is at say 50 (of 1-180), it would be 40 units short of center, so the Kangaroo moves the motor 40 units backwards from center. If at power up, the motor is actually at PWM position 20, when the Kangaroo powers up, it again assumes it is at center, figures it needs to move 70 units backwards (to get from 90 to 20), and then the motor hits the limit of travel, and the Kangaroo errors.
Turns out, there is a setting called Origin which can be set via the Describe software. That Origin is the line count of the encoder, and is set to 0 when you do the Teach Mode (line count goes from negative to positive, with zero being center of travel). Using the Describe software to set the Origin to the min or max line count (shown on the position tab of Describe), will make the Kangaroo assume the start position at power up is that min or max value of the Origin.
In my case, the min line count was -1375, max was 1375. I set the Origin to be 1375, and updated Kangaroo with the new settings. Then I did a power off/on, and now everything works like I need it. I make sure my motor is at the start position (1375) on power up, and the PWM setting on EZ-robot is 1, and then there is no initial homing of the motor. Of course, I must make sure when powering down, the EZ-robot moves the motors back to the initial start positions, before I turn the power off, but that is something that has to be done anyway. Only issue will be if the power is ever cut off before returning to start positions, then everything gets out of sync. But that’s another problem, for another day.