Lazarus
Programming => General => Topic started by: krolikbest on April 22, 2018, 01:34:47 pm
-
Hi,
this thread is for those who are interested in such subjects from the edges ;)
so this is my latest project (not completed, long way ahead). In this project few (will be five) atmega8s are to controll servomotors reading encoders, generating step/dir, checking ranges for servos and are sendig datas to or reading from RPi3 trough i2c. On RPi3 is program written in Lazarus which is responsible for collecting datas from atmegas, sending next steps, checking errors from atmegas, interact with user. With this you can move servomotors, make a whole move script, set up individual ranges for servos etc
Here is the movie, I point out this is very raw material!
https://www.youtube.com/watch?v=xpOWehtW7ns
Martin
-
I want to see that robotic arm finished. ;D
-
Hi
I want too ;)
-
Next step:
https://youtu.be/wCBY1a52TEk (https://youtu.be/wCBY1a52TEk)
There I haven't done learning algorithm still but it is in some progress. Of course it is written in Lazarus. On RPi 3 there is installed Laz 1.7 and directly there I write and run the main program. Writing it somewhere outside RPi is without a sense because of using wiringPi.
Btw I'm strongly thinking about using rs485 instead of i2c as a connection between RPi and atmegas. It works but....
-
Some things that struck me during the video:
- there is a lot of moment and shaking (hitting hard blocks?). Or maybe a larger gear for more smooth movement?
- What kind of feedback do you get back from the system?
- If you develop a position (setting coordinates on all controls), how exact is the final position?
I'm still waiting for an order at work to build a robot to insert/remove bottles from a machine, so I keep tabs. From what I see, we use a similar driver module.
-
Some things that struck me during the video:
a). there is a lot of moment and shaking (hitting hard blocks?). Or maybe a larger gear for more smooth movement?
b). What kind of feedback do you get back from the system?
c). If you develop a position (setting coordinates on all controls), how exact is the final position?
ad a). larger gear surely will help but most important is to make in atmegas slowing down ramp. piece of cake ;)
ad b). encoder's positions after move, few errors which I programmed in atmegas, so still in separate thread RasPi "is talking" with atmegas trough i2c
ad c). goog question, and moreover: reproducibility. Because it is made from wood I do not expect rigidity like from steel but it should be +/- small difference for a some time of work. The most important is reading encoders correctly. That's point :)
-
I'm envious very well done any reading material for us mare mortals about the algorithms required you can propose?
-
I would like to try two ways of learning algorithms,
first: moving separately every servo to some point in space and saving this position for all servos, (in progress - coded in Lazarus :), should work in two weeks). In this way you could practically do many such points that make a move path.
second: more complicated - IK (inverse kinematics). Possible to make, (i did something similar in Lazarus already) but .... ;)
-
ad a). larger gear surely will help but most important is to make in atmegas slowing down ramp. piece of cake ;)
ad b). encoder's positions after move, few errors which I programmed in atmegas, so still in separate thread RasPi "is talking" with atmegas trough i2c
ad c). goog question, and moreover: reproducibility. Because it is made from wood I do not expect rigidity like from steel but it should be +/- small difference for a some time of work. The most important is reading encoders correctly. That's point :)
Thanks for your replies. Yes, if you get feedback or are carefully calibrated you can tune on/off to be a curve instead of abrupt.
Probably our robot will be aluminium. and I'll probably using dspice33's (using C or, less likely Mikropascal).If I need more, they'll probably be linked over CAN, with a W5500 ethernet chip to communicate with PC (or RPI for the mobile, demonstration setup)
These (dspic33epxxxMU806/810/814) are the standard chips we use, and they are very suitable for this, with 14 two pin motor peripherals and 16 single pin and two encoders and DSP functionality to do realtime analysis (like FFT), though I have no experience with the DSP part yet. Till now I just use the single pin peripherals as a signal generation for external motor drivers like yours. But till this project most of our motorcontrol was ad-hoc and not design-in, so this will be different.
The robot will be an vertical axis that can turn 90 degrees and on top of this something that can extend (linear actuator?) and some gripping device on the point of that. So it can pick up a bottle from some store area, rotate 90 degrees, extend in the machine, and drop it. Precision is course, 5mm or so. Reliability is more important.
-
Thanks for your replies. Yes, if you get feedback or are carefully calibrated you can tune on/off to be a curve instead of abrupt.
Probably our robot will be aluminium. and I'll probably using dspice33's (using C or, less likely Mikropascal).If I need more, they'll probably be linked over CAN, with a W5500 ethernet chip to communicate with PC (or RPI for the mobile, demonstration setup)
These (dspic33epxxxMU806/810/814) are the standard chips we use, and they are very suitable for this, with 14 two pin motor peripherals and 16 single pin and two encoders and DSP functionality to do realtime analysis (like FFT), though I have no experience with the DSP part yet. Till now I just use the single pin peripherals as a signal generation for external motor drivers like yours. But till this project most of our motorcontrol was ad-hoc and not design-in, so this will be different.
The robot will be an vertical axis that can turn 90 degrees and on top of this something that can extend (linear actuator?) and some gripping device on the point of that. So it can pick up a bottle from some store area, rotate 90 degrees, extend in the machine, and drop it. Precision is course, 5mm or so. Reliability is more important.
Aluminium is good choice. Stable, doesn't shake.
I feel I have to learn Mikropascal. Atmegas were programmed in Bascom, but I would like to make step forward and use not only 8-bit uC. Someone have interesting HOW TO BEGIN with Mikropascal?
btw I envy this task.
-
@krolikbest:
You know you also can use FreePascal to program for AVR and ARM Embedded (e.g. STM32).
http://wiki.freepascal.org/AVR_Programming
http://wiki.freepascal.org/TARGET_Embedded#ARM_Embedded
-
thanks for an answer, i've read it but maybe someone has antyhing done with fpc for avr and could share experience ? anyway i'll try and public some simple video "howto".
-
thanks for an answer, i've read it but maybe someone has antyhing done with fpc for avr and could share experience ? anyway i'll try and public some simple video "howto".
The AVR support in FPC trunk has come a long way in the last couple of years. Since the support is relatively new there isn't yet a lot of work published. There is however quite a few tutorials in German on the wiki (http://wiki.freepascal.org/AVR_Embedded_Tutorial/de) (use Google translate if required) and also an English basic introduction (http://wiki.freepascal.org/AVR_Programming).
-
This is my last progress in robotic arm: https://www.youtube.com/watch?v=2Y7HZ5EpOA0& (https://www.youtube.com/watch?v=2Y7HZ5EpOA0&)
btw, during writing a code in Laz 1.7 on Raspberry (OS Raspbian) i had such a case: i put on a form ToolBar with few buttons and separators. Then i put on a form a standard button and after compilation i got sigsegv. So i removed this additional button from a form and compiled OK. Than I put once again this button and again sigsegv. I put second standard button on a form and that compiled OK. Odd? In summary i had to get rid of ToolBar . Then never again I've got error.
In windows or ubuntu I do not have such problem with ToolBar.
Martin
-
Awesome :D
-
Thanks, but the deeper in the forest, the harder way.. :) In next week I'm going to improve serial reading from uC via i2c. Still dissatisfied.
-
You might be interested in these applications:
http://blog.rectorsquid.com/linkage-mechanism-designer-and-simulator/
http://blog.rectorsquid.com/sample-linkage-mechanisms-2/
http://woodgears.ca/gear_cutting/template.html
http://woodgears.ca/gear/index.html
-
Thanks Avra, useful gear planning. Especially with export to hpgl and dxf. this two formats I have in my program for milling machine.
-
Thanks Avra, useful gear planning. Especially with export to hpgl and dxf. this two formats I have in my program for milling machine.
Actually your project spectacular and I would like to know more details about your project;
* Which controller do you using? Servo driver or PLC? or maybe some circuit designed by yourself.
* Is lazarus using as main development tool? or do you using as supervisory software?
-
Probably our robot will be aluminium.
Last week I got the word, that even if we are going to deliver that machine, the robot will be externally bought. :crying.
The only project to look forward to is trying to improve a basic microstepping motor. (read back position via quadrature and adjust rate to make it even smoother)
This week I also got a sample of dspic33CH, the first dual-core (*) uc I've used.
(*) not dual core with shared memory like PCs. It is more two separate cores connected via register based mailslots. You can also assign pins to either core or slave. Mostly meant to have a tight kind of motor feedback on the slave (which is rumoured to be extremely fast. 100 MHz/Mips and nearly any instruction is 1 cycle, except branch and read-write-modify are 2), and the "rest" +communications on the 90Mhz/Mips master (which takes 4 cycle hit for a branch, so also a bit less efficient)
-
Probably our robot will be aluminium.
Last week I got the word, that even if we are going to deliver that machine, the robot will be externally bought. :crying.
so? create a company and have them buy it from you :P
-
so? create a company and have them buy it from you :P
One of the main reasons is that these companies that are customer don't buy robots from firms without experience. So that would also hit my "company". Worse, the objects to handle are red-hot. (literally, as in just fabricated glass bottles). Maybe not the best to begin with.
-
so? create a company and have them buy it from you :P
One of the main reasons is that these companies that are customer don't buy robots from firms without experience. So that would also hit my "company". Worse, the objects to handle are red-hot. (literally, as in just fabricated glass bottles). Maybe not the best to begin with.
Just to be clear, I did not mean to go to your company's customer directly, I mend your company (current employer) buy it externally from you. I did not in any way suggested to undercut your employer.
-
Actually your project spectacular and I would like to know more details about your project;
* Which controller do you using? Servo driver or PLC? or maybe some circuit designed by yourself.
* Is lazarus using as main development tool? or do you using as supervisory software?
Hi,
1.steppers are connected to stepper controllers M545 (all from China)
2.as a servo controller is atmega8. so one atmega for one stepper. atmega is responsible for:
- step/dir generator
- quadrature encoder reader
- some other works
- i2c communication with RPi
lazarus is used for writing the main program on RPi. Its task is to send datas i.e. velocity, distance (encoder pulses), checking errors from atmegas, interact with user. There is no "magic" libs to control servos.
TODO:
- inverse kinematic - maybe sometime
- moving robotic arm directly from a program though i don't know what is the point. I do it because my children want :)
-
Looks like the same stepper we use. In 25600 (25*1024) mode (because of the large number of divisors)
-
One stepper (current=6A) is connected with HSD86 (China as well). I expected that it should work most stable but with this controller I cannot set current. It sets up the current in some different way (there isn't dip switch) and in the end this stepper makes sometimes surprises (undesirable). Consider to change with M545 or MDC860.
-
We have some problems that even with 25600 granularity the angular speed (as in 360 degrees/25600) is not constant enough. The various microsteps are not entirely equidistant which frustrates fourier filtering of results etc.
It is however probably the motor, not the stepper. A plan to tackle this by controlling the motor directly and calibrating it is in the works, probably a project for fall.
-
@Marcov:
Wouldn't be a servo motor more suitable if you have high requirements for position and speed?
-
@Marcov:
Wouldn't be a servo motor more suitable if you have high requirements for position and speed?
Afaik there is some closed loop control stepper too nowadays. Maybe the one we use has such possibilities.
It might not even the controlling of the motor, it might be that the signals for 1/(n*200) th of a rotation are emitted at the precise moment regardless of the motor's feed. This might also be possible using some interpolation of the derivative of the motion. I haven't seen the details of the plan yet.
-
With microstepping I don't have good experience, as the holding torque partially persists. Thats why I asked.
Once I made a torque compensation for a permanent magnet synchron motor. I got the speed constant, but vibrations increased, because the constant torque needs changing current amplitudes which creates additional oscillating radial forces between rotor and stator.