I have purchased a SNAM1400 robotic arm. Right now I am using 3 two axis analog joysticks for movement and an Arduino mega for control. And I am using pot, fade(speed control) and the servo node for each axis, been a fun little project so far. I do need advice on how to have one of the axis to follow another axis to keep away from mechanical interference and yet be independent when needed. I gotta say this XOD program made tinkering fun again!
Hello!
Could you elaborate, what do you mean by following an axis? Do you want some inverse kinematics?
P.S> Don’t be shy to include a link to the product so that others better understand its characteristics. https://smallhammer.cc/product/snam1400/
Sounds like an ambitious project. For starters, you will not be able to directly control the servos using the joysticks. Instead, you would be using the joysticks to tell the arduino where you want the gripper to be, making them like helicopter controls. One joystick could be used to position in the horizontal 2-D space. Another would specify height and twist. A 3rd joystick might define angle of the gripper (should the gripper be pointing straight down, or slightly to the left like the picture above). Now you need to work out equations to convert the gripper position in space to servo positions for the arm, taking into account limitations of the arm that will prevent certain positions. Many of those servo positions will be dependent on the position of other servos (i.e. gripper twist will be dependent on angle of the base servo twisting the entire arm; adjusting the angle of the gripper will be dependent on almost all the servos–think of the coordination required to keep the gripper pointing left while the base servo is turning the entire arm). Keep in mind these equations need to be simple enough for the arduino to calculate in real time.
1 Like
hey Guys
Thanks for the replies. nkrkv.Using the photo as a guide that rod from the servo to the (knee joint?) will contact the servo’s arm when the main arm servo goes to move to an over center position if not move with it. I hope I explained it right. Many years ago I did something similar but not on an arm, but I needed mechanical crash avoidance and it was done in Commodore basic.Ok the keyboard was actually not made of stone.I won’t get into the actual electronic components but programing, I would use an IF THEN statement that would adjust the other axis by adding or subtracting a value to make things move out of the way. Then used an OOpic controller but still basic however it had libraries but were called objects.
gweimer you are correct this is an ambitious project and I do realize that I am going to need to think things out one step at a time. I am not going to have this project getting me a beer or pick and placing objects any time soon. Right now I am just working with the 4 servos and not worrying about the head orientation at this time. I do see your point with the calculation and coordination. In the old days I would use multi-dimensional arrays for coordinates capturing, writing to memory and then executing. Oh now a question can arduino do arrays like old systems? If any one has seen a fuel mapping graph for cars arrays are similar. I tried to keep this from being to wordy. Thanks Guys
I have switch out the analog joysticks for pots, just 3 for now. I move and record on pen and paper the analog input values.I have a very, very basic 3 dimensional grid worked out on my scribble pad. And I had an issue with the watch node so I am using the I2C 16x2 LCD node to watch the values. I see there is a node to capture data from a thermometer or another analog device, is there a node that will capture multiple analog inputs on one entry and retrieve in a like wise way. As an example copy entry1-(.5,.5,.5) entry 2-(.5,.3,.2) etc and then play back to move the 3 servos to that co-ordinate?
I would like to thank all those who have made this XOD ide and the nodes. I love it.
Not exactly what you want, but you could use 3 nth-input nodes for the 3 values and feed the same IDX to all three. This would allow you to step through n stored values, feeding them to servo nodes.
Thanks gweimer
I’ll give that a go
Another complication I just thought of while stepping through a set of servo values…you will either need to wait long enough between steps that servos always have enough time to reach new position (even if they have to travel their full range under load), or you need a 4th value to specify how long the current step should be given to complete.
First thought is you can just add another nth-input node to feed times to your counter, but that creates a feed-back loop requiring a defer node, which might cause the counter timer to update too late…might take some experimenting to get this working correctly…
Good point gweimer,since I use the fade node to slow servo speed I will need to have enough time to move to that specific coordinate. On a side note is there an example of using nth-input node I can find. and how to paste a jpeg screen shot.Thanks
Nth-input is pretty basic. If IDX is one, the first input is output. If IDX is two, the second input is output. Since you want to use the values in order, a simple count node can feed IDX. A clock node can be used to pulse the count node, giving enough time between pulses for servos to travel.
I’m able to copy an image and just paste it into a reply. If you are a new user, the admins will need to grant you permission to attach files.
This is the very basic start of it so far. I have been playing with the nth-input node on a separate patch,never thought of the count node. You may need to excuse me for using old terms.Say where the servo nodes there are registers that can hold the value and then read to the servos with a pulse on the upd pin. I think may have started this task backwards, I should have started with collecting the info,storing the info, reading the info and then implementing the info.
Has any one built a line following project the collected the data and was able to have it repeat the path with out the line. this xod is awesome
The fade node in your example does not need the square-wave node pulsing it. Just set UPD to Continuous and adjust the RATE value to get the speed you desire.
If you want to use nth-node to step through values, just replace the joystick nodes with nth-nodes, feeding IDX from count node, with count updated by a clock node.
In order to record a set of values dynamically (instead of just hard-coding the values in your nth-nodes), you will need a way to input values. This could be joysticks & a button to indicate current position should be stored, or it could be POTs on the robot arm (or servos that can be queried for their current position). Then you will need some way to store the values. If you know ahead of time how many steps will be stored (or at least a max # steps), you could use nth-node with gates feeding each input so that you can step through the inputs, or you could use a queue (i.e. gweimer/utils/queue-buffer). You could also use other nodes to write to an SSD or EEPROM (NOTE: EEPROM will burn out after about 100,000 writes, so using it for data like this may result in a short-lived arduino board). If writing to RAM, you will need a way to switch from record mode to playback mode. If writing to non-volatile memory, you could have one program to record and another to play back.
In order to record a path for a line-following robot and play it back, you will either need stepper motors or encoders to accurately record/playback your path. Straight motors or continuous-rotation servos are not going to be accurate enough. It would be hard enough just recording path taken in a maze and repeat the same path with the maze to follow again. Repeating a line path without the line would be a challenge. Maybe record how many “steps” (assuming a stepper motor) were taken every 1/2 or 1/4 second and play that back to approximate the line?
gweimer
I can’t thank you enough for the help. I added a button to the project to stop it at any count for debugging the coordinates. I am including a screen shot with the way I have it now, it is working out quite well for me,had to zoom out quite a bit. Anyone sees a way to improve on this please feel free to comment.
Need a little help with this XODBALL, I have set up a Mega with 7 pots for the 7 servos with LCD displays.
(Please don’t bust me for the state of my bench I do Fab and repair work on the side )
The IC2 displays I am using is 1- 20x4 and 1- 16x2 for 6 lines, I modified the code but could not save under a different title. The problem I am having is extremely erratic servo movements.
When I erase the ConCat and LCD nodes the movements are smooth. I like to have the LCD display so I can write down the coordinates when moved to the desired position and then place the numbers in the previously mention XodBall. I think the I2C lcds may be interfering with the timing of the servo PWM, not sure just guessing. I like the remoteness of the LCDs as I don’t need to have a computer connected but Would the Watch nodes work better than the I2C LCD?
I really like the XOD IDE and every update adds more versatility Keep up the good work.
Is it a problem with all servos or just certain ones? Arduino had a limited number of timers and probably needs at least one for i2c communication. If I remember correctly, each timer can control 3 PWM pins. You may be able to switch problem servos to different pins (if there are any PWM pins left). Alternatives are to use watch nodes instead of LCD or separate PWM controller to offload pulsing from Arduino.
Thanks for the reply gweimer.
It appears to be all the servos are being effected. I just tried different pins as the Mega has 12 pwm pins and 16 analog pins. I have been keeping an eye out for some development with the PCA9685 I2c module or the 16 servo driver board that fits the Uno . I am sure that it will have a library.
Now, I pulled a very amateur move. I used terminal D1 for pwm ! duh, it is a digital or TX terminal. Now it only has the intermittent type motion with the I2C displays, However the watch nodes instead work a lot smoother.
thanks again
I guess it’s an interrupt conflict between the hardware MCU timer used to control servos and I²C used to transfer data to LCDs.
In the patch shown you UPD the LCD’s in a loop (aka continuously). That involves sending plenty of data and servos control might be delayed causing them to wrongly interpret the desired angle.
I hope we’ll address the issue in one of the nearest releases. Meanwhile, try to send LCD UPD pulses explicitly. With a dedicated clock or a pulse-on-change node.
nkrkv
Thanks for the reply, as I mentioned awhile back I am learning XOD one step at a time. When I get stuck this forum with knowledgeable people like yourself and gweimer are a great help. I shall try your suggestions.
thanks again
Hope anybody may be able to help out with this:
I’ve been working on the XOD Temperature Log Example (https://xod.io/docs/guide/sd-log-example/ 2) but ended up with nothing when reading the micros SD card. The card is fomatted but it could not store the temp-log.txt file. I suspect that I’m not using the same microSD card Adapter described in this example that only defines a port for the CS pin on the adapter. The one I’m using has 6 pins, 4 of which have to be connected to Digital pins i.e,. CS, SCK, MOSI and MISO. I can’t find relevant pins on the sd-log node for the SCK, MOSI and MISO pins!!
Moderator note 
not related to this topic. Start a new thread for a new question
A flickr video link to my servo arm. I had to make the gripper with materials that were available ie:servo, part of a hockey stick and a small clamp with a weaker spring put in.
1 Like