I am not sure which category this question fits, but I had a question on the possible movements of the robot in different directions in a straight line walk.
I have a A H3-R hexapod robot. I am using the powerpod software right now and the beginning of the program says this:
[code]Use Basic Micro ATOM IDE 02.2.1.1
; *** not suitable for IDE 05.3.0.0 (there’s a specific version for this IDE)
; Use Basic Atom 28
; *** not compatible with Basic Atom Pro (new version for BA Pro soon)
;************************************************
;*** Basic Atom with SSC-32 and PS2 DualShock ***
;----------------- 1.36 3DOF-A ------------------
;--------------- PS2 Controller -----------------
;-------------- Round Body (H3-R) ---------------
;********** Bot Board Buzzer support ************
;***** Little Gripper / Pan & Tilt support ******
;**************** Deck support ******************
;************************************************
;** Programmer: Laurent Gay, [email protected] **
;************************************************[/code]
So thats what I am using.
Now, in this program, there are two variables, XSpeed and YSpeed which are both SBYTE. I understood that if you change XSpeed and YSpeed, the speed in X and Y directions changes accordingly, so does the direction of the robot then. For example, when I put YSpeed to be 0 and put XSpeed to be 128 – the robot moves in a straight line in X direction. If I put 128 for both XSpeed and YSpeed, the robot moves in a 45 degree angle to the X axis.
My question is about the resolution of this angle direction. If I keep YSpeed at 128 and keep changing the XSpeed, in my opinion the angle of direction should keep changing… but what I find is that it is constant at 45 degrees.
How do I change this angle? Are XSpeed and YSpeed variables not the ones that effect this angle?
By changing the values of XSpeed I meant different values like I used - 16, 64,96,118 – they all give me the same 45 degree movement. At 0 obviously it moves in a straight line only in the Y direction.
The values should change the angle. I’m wondering exactly where you are setting the values. You probably know where the values normally get set by the program.
You’re using the PS2 build. There is also an autonomous build.
There are a set of values to be sent by a terminal program in one of the sticky threads. You might try that out for a while. You can capture some “good” XSpeed and YSpeed values.
I don’t see why your values wouldn’t work, other then the off chance of the re-clearing of your values.
If you DO have the PS2, you can run it and capture some values of XSpeed and YSpeed to get you familiar with them.
It’s late, let me give it some more thought! I’m sure we can help you figure it out!
Sure, You can take your time to reply… perhaps tomorrow morning… Thanks.
well, so I am not using PS2. Right now, I am changing the values in the program itself - changing the variables everytime and then downloading it on to the atom.
I change the values of Xspeed and Yspeed variables in the program. I have tried with
YSpeed = 128
and XSpeed = 16,64,96,118 – they all give me a resolution of 45 degrees.
My program is actually making the robot go straight first, XSpeed = 128 and YSpeed = 0, and then it takes a turn to change the values as mentioned above.
With those values above, the robot goes straight and then takes a 135degree left turn. So the resolution is still 45 degree. Only once when I put XSpeed and YSpeed both 128, did the Robot make a 45degree left turn. I am confused because all the values of XSpeed = 16, 64, 96, 118 --all of them give the same 135 degree turn.
According to bit calculations, the resolution should be less than a degree because the maximum that can be handled by XSPeed and YSpeed is 128. So technically, keeping one variable as 128, and then going from 0 to 128 in the other variable should cover a 0 to 45 degree turn, which means a resolution of 0.35 degrees? Tell me if my logic is wrong - either way, I am only seeing 45 degree turns, the resolution should be less than that atleast.
You’ve modified in this area of the code no doubt:
[code] for Index = 3 to 6
if DualShock(Index) > (128 + DeadZone) then
DualShock(Index) = DualShock(Index) - DeadZone/2
elseif DualShock(Index) < (128 - DeadZone)
DualShock(Index) = DualShock(Index) + DeadZone/2
else
DualShock(Index) = 128
endif
next
YSpeed = DualShock(3) - 128 ; Right Stick Horizontal
XSpeed = DualShock(4) - 128 ; Right Stick Vertical
[/code]
You’ll probably want to plug in your YSPeed & XSpeed assignments in place of the last two lines, right? You might want to post your modified section of code.
Actually, I think you might mean “granularity”, not “resolution”. No matter. Yes, you should be able to set the direction vector finer then 45 degrees!
Above is the section of code that generates angles. Some versions of Atom (you don’t say which one you have) handle things a little differently (minor bugs), and may give you bad values. Is this where you are reporting your course (angle)? Or are you simply observing the 'bots movements? I’d get the values generated here, and see if they are proper! Otherwise, the problem could actually lie somewhere else.
* [4] XSpeed (translation) Range -120 (Forward) to 120 (Backward)
* [3] YSpeed (translation) Range 120 (Right) to -120 (Left)
Some useful ranges of variables above. Should be in your code.
[code]for Index = 3 to 6
if DualShock(Index) > (128 + DeadZone) then
DualShock(Index) = DualShock(Index) - DeadZone/2
elseif DualShock(Index) < (128 - DeadZone)
DualShock(Index) = DualShock(Index) + DeadZone/2
else
DualShock(Index) = 128
endif
next
if (counterStraight < 50) then
YSpeed = 0
XSpeed = 128
Endif
if (counterStraight > 50) then
YSpeed = 128
XSpeed = 96
Endif[/code]
My changed code is at the bottom of this starting from the ‘if’ statement. I am trying to make the robot go straight and then take a turn at an angle. This angle changes, but the resolution is always approximately 45degrees no matter what the values are.
Are you sure the variable range is -120 to 120? Because it says they are SBYTE and the manual specifies the range as -127 to 128.
I am measuring the movement of my robot with an internal GPS system in my lab. So not really looking at the DAngle variable.
GPS! That’s pretty impressive! I always had a hard time getting GPS signals in my office, unless I put the receiver right up against the window, and then it would only work sporadically.
The 120 limits are comments from the original code. I notice that you have two 128 settings in your conditional statements (if’s). But by now, you’ve probably tried a lot of smaller values as well.
It would really simplify the problem if you had a verification that you could control the 'bot with a com cable (different build) or PS2.
Another thought
If you haven’t modified the code around the ;Ps2Query, then it typically just loops there until it gets something from the PS2! But you said you could get some motion, so that contradicts that theory. You will get a little leg movement when you power up.
Also, I suggest you examine or change to an “Autonomous” build:
;************************************************
;************ Basic Atom with SSC-32 ************
;----------------- 2.43 3DOF-A ------------------
;----------------- Autonomous -------------------
;-------------- Round Body (H3-R) ---------------
;********** Bot Board Buzzer support ************
;***** Little Gripper / Pan & Tilt support ******
;**************** Deck support ******************
;************************************************
;** Programmer: Laurent Gay, [email protected] **
;************************************************
Or at least study it. Without the PS2 being received (you can fix that in code), the program should just spin there waiting!
Actually I haven’t tried with both less than 120, will do so.
Sorry, I shouldn’t have used the term “GPS”. We have a Vicon system in the lab, infra red cameras which capture images off of certain tags we put on the robot. vicon.com/
I’ll do more tests and try the autonomous one too and see if it makes a difference. Thanks.
Interesting system. A bit costly for my lab, 'tho. I had played around with the idea of using IR/ultrasonic system to triangulate the location of a 'bot. But I’ve already too many projects!
I was unable to find the range as -120 to 120 anywhere in my code, but it is making more sense with this range so I will stick to it. Although, I don’t get how - since the variables are SBYTE which can handle -127 to 128.
Also, I had some values in my axes as I was measuring angles on Matlab. So I corrected those too.
The resolution or granularity of the angles is not as fine as the code says, since there are a lot of factors involved when the robot is changing its direction(like how tight the screws are, battery, uneven surfaces)… but its good enough for my work.
Maybe you could elaborate on what you had to change?
The values -120 to 120 don’t appear as parameters, but as comments, as I recall. And you’re perfectly correct in the range of SBYTE! Past that, I don’t have any answers.
Engineering designs are always a product of several factors, and all of these contribute to the overall resolution and accuracy of a system.
so earlier, I was using variable X to be 128 and changing the value of Y. I tried few values like 128, 118, 96, 64 etc. With Y = 128, I would get a 45degree turn as expected, but with any other value, less than 128, I would get a 135degree turn. (The granularity would still be 45degrees or close to that). I am not sure why this was happening.
Anyway, so now I changed the range – X = 120 and changing the values of Y = 1, 2, 5, 10, 20… and I get the change in angle accordingly.
Also, another thng I was doing wrong before in measuring the angle was that I was measuring it out of the graph of the track that the robot makes. On matlab graphs, the axes increments for X axis and Y axis were not the same. So I made it the same and the graphs came out right.
I think both the reasons effected my measurements.
Well I’m glad that limiting the range did the trick. I don’t know exactly why, but I’ll try and find an answer. Most likely, a variable is overflowing somewhere.
And it’s interesting to hear that another small bug contributed to the problem! That’s often the case, more then one problem combine to make a very tough problem to solve! The best approach, of course, is to break up the problem as much as possible.
Nice exercise! And I’d enjoy hearing more about your project as it progresses.
I have absolutely no idea what you are doing in the code, and please don’t try to explain it to me… But if a variable has a range of 120 it might be because it’s divisible by 360°.
