For those that wants to start with the Thor robot, realize that:
* When the cooling fans are working, it is noisy. Interesting to realize when you are like me, doing everything at night. The neighborhoods may complain at 4 AM!
* The number of wires, 7 stepper motors each 4 wires. Then the 2 wires for every fan (I need probably 4 fans). Then the wiring for sensors and robot hand. That is a lot of wires to cram into your housing.
* Cutting the axis to the correct length. I have a Dremel but the axis material is very strong. Because I live in an apartment I may get a fire hazard when I cut it with the Dremel via sparks. Realize that even though it is 5 mm thick, hand sawing it takes 15 minutes each.
* Assembling, reassembling, reassembling, reassembling, reassembling, reassembling, reassembling. It is amazing how many times I had to get all the parts at the correct place and operating.
Don't let that stop you from creating your own, the making it is what makes the fun of it.
24v 40x40 cooling fans are in! I also ordered 24V 30x30 cooling fans to seen if they are useful. But they came without labeling what the voltage it supports. So I will have to do the smoke-test :-)
Next is cutting holes in the already 3D printed parts. Probably something for the weekend.
I finally started to reassemble the Thor robot now that I can efficiently control the stepper motors. But heating is a main problem, even if the stepper motors are outside the robot. So I ordered some more smaller 4x4 cm and even 3x3 cm ventilators.
I will have to cut additional holes into the plastic to insert the ventilators. They were not part of the original 3D print.
I was looking to electronics counters to measure the performance of the robot motion, but it turns out that the Saleae logic analyzer software can also do this. It was a bit hidden in the UI.
I need to know how many steps are needed for the robot to rotate an angle. Not that obvious when you are using 3D printed material that has no tolerance at all.
The whole idea is to make the robot as fast and accurate as possible. And the only way to do this is to build the software around the limitations of the hardware. There are no pre-created libraries that will do the job.
I have been thinking how to proceed next in the Thor code development. Thinking how to let the robot operate in a reliable way without need of some feedback mechanism. Feed-back mechanism may improve accuracy but it also takes up space, uses power, needs additional wiring and additional processor cycles that could have been used to move the robot.
Completely mapped Enable, direction and step control for the Thor robot designed for high speed control. The Arduino methods are too slow for what I have in mind and I wanted to control and change direction of every stepper-motor simultaneously.
C++ compiler issues forces me to adapt my coding style to what the compiler makes out of it. It seems that not everything in the C++ compiler for the Arduino Due is implemented as you would expect. It is probably more mature for the Arduino Mega/Uno.
Finding examples for the Arduino Due is also harder to find. The interrupt mechanism is different and the way to set or reset a PIO register is also different.
It seems that inside classes the C++ does not like "MyClass* myClass=new MyClass()" on the Arduino Due. Dynamic memory allocation seems not to function nicely.
So the redesign will use only static created classes and use #defines to allocate memory in chucks during complilation time.
I seem to have hit a stone brick wall in memory allocation for my project. I seem not to get a reliable byte array. I should have 96 KB of static memory, but everything suggests that the compiler somehow messes it up and I seem to overwrite programming memory when I use it.
Verified over and over again and I do nothing wrong if this was Windows C++.
The Thor board Ultratronics v1.0 uses an Arduino Due processor.
The Arduino Due processor has an interesting protection that prevents you to write wrong data to wrong GIOP pins. I do not understand it yet but as a safety feature to prevent accidental activation of the motors by a computer bug, this could be very interesting.
Tested the motor stepper controls at speed of 32 Khz and no smoke to see on all 7 motors at the same time and have still about 92% CPU time left. We are at a stage where we can now implement programmable motion.
First steps will be with predefined test patterns.
X axis step is hooked to D35 --> which is the mapped to PC3.
Now for the Due we set the signal to high through the command REG_PIOC_SODR = PIO_PC3;
And we clear that bit with the command REG_PIOC_CODR = PIO_PC3;
The difference between the stepper pulse seems to be 40 ns. For 7 steppers this would mean 7 x 40 ns = 0.28 µS (53 times faster than digitalWrite(X_AXIS_STEP, level)
This Arduino Due is driving my crazy. All I want to do is set a pin to high and 2 µS later to low. But its processor Atmel SAM3X8E ARM Cortex-M3 CPU appears to have a write protection mechanism.
The Atmel SAM3X8E documentation is not very clearly explained how to us it.
The Standard Arduino function digitalWrite(X_AXIS_STEP, level) is too slow. I lose 7 x 2.xµS = 15 µS accumulated for 7 stepper motors.
And the standard Arduino Uno family works differently to set bits directly.
Success! The core code to drive the stepper motors is functioning. The key is to drive 7 stepper-motors simultaneously at a predictable and continuous speed.
The interrupt driven code for a Arduino Due is different than for an Arduino Mega.
Hahah, silly me. If you ever wonder why your stepper motors do not turn and your stepper driver does not get enough voltage to trigger the pulse, that is because you forgot to set the GIOP to output!
Finally more free time for myself coming. And I have my logic analyzer to see what I am doing. Time to do some more coding of the core code that moves the motors.
Firsts steps will be to see if I can easily move all 7 motors at one go (this is why I bought a 16 channel logic analyzer). Particular interested is to see how the timer interrupt creates predictable and continuous timing pulses. This will become important if you move large loads (smooth acceleration/deceleration)
Back from holiday and ready to continue toying with electronics.
And when I was away I received an official Saleae Logic Pro 16 (Red) package This was a nice welcome home present. It is very expensive compared to a $10 clone but one should not forget that the cheap clone is using Saleae software which is the equivalent of pirating.
I think the device is worth it, it is a solid metal casing and it does weight a lot. It also comes with quality wires, and quality hooks. And on top of that a big bag to carry it.
The story how I get it ordered is one hilarious piece of story no one will believe that it ever happened.
It seems that Hobbytronics can't reproduce the issues I have with the USB hots controller. And they don't see anythign wrong in theri code. If anyone else could reproduce the issue then please be my guest.
All you need to do is to hook up it to an single Arduino I2C connection and let it ruin in a closed loop to request the PS3 status. (Use the debugging led in order to see it is still running or got frozen). The freeze can take many minutes.
Caught it! The USB PS3 host controller freezes and everything suggests a firmware issue.
Last week I did not have the tools to visualize the issue with hardware tools, only through Serial communication debugging. So I ordered a logic analyzer and I built my own cheap DSO138 oscilloscope to actually see and measure the issue.
From electrical point, there is nothing specially to see when that happens when it freezes the Arduino. I2C communication just stops. I expect the Arduino standard I2C communication not to have a time-out mechanism and it waits indefinitely.
A watchdog timer can of course fix this issue but I want to fix this issue for ocne and for good.
The €10 Seleae logic analyzer (Chinese clone) is a big help in determining I2C issues. The SDO138 oscilloscope (self build €38 including acrylic casing) seems not to be fast enough to identify high frequency noise in the data. But the I2C data is clearly visible.
Olaf Baeyens
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
For those that wants to start with the Thor robot, realize that:
* When the cooling fans are working, it is noisy. Interesting to realize when you are like me, doing everything at night. The neighborhoods may complain at 4 AM!
* The number of wires, 7 stepper motors each 4 wires. Then the 2 wires for every fan (I need probably 4 fans). Then the wiring for sensors and robot hand. That is a lot of wires to cram into your housing.
* Cutting the axis to the correct length. I have a Dremel but the axis material is very strong. Because I live in an apartment I may get a fire hazard when I cut it with the Dremel via sparks. Realize that even though it is 5 mm thick, hand sawing it takes 15 minutes each.
* Assembling, reassembling, reassembling, reassembling, reassembling, reassembling, reassembling. It is amazing how many times I had to get all the parts at the correct place and operating.
Don't let that stop you from creating your own, the making it is what makes the fun of it.
Are you sure? yes | no
24v 40x40 cooling fans are in! I also ordered 24V 30x30 cooling fans to seen if they are useful. But they came without labeling what the voltage it supports. So I will have to do the smoke-test :-)
Next is cutting holes in the already 3D printed parts. Probably something for the weekend.
Are you sure? yes | no
I finally started to reassemble the Thor robot now that I can efficiently control the stepper motors. But heating is a main problem, even if the stepper motors are outside the robot. So I ordered some more smaller 4x4 cm and even 3x3 cm ventilators.
I will have to cut additional holes into the plastic to insert the ventilators. They were not part of the original 3D print.
Are you sure? yes | no
I was looking to electronics counters to measure the performance of the robot motion, but it turns out that the Saleae logic analyzer software can also do this. It was a bit hidden in the UI.
I need to know how many steps are needed for the robot to rotate an angle. Not that obvious when you are using 3D printed material that has no tolerance at all.
The whole idea is to make the robot as fast and accurate as possible. And the only way to do this is to build the software around the limitations of the hardware. There are no pre-created libraries that will do the job.
Are you sure? yes | no
I have been thinking how to proceed next in the Thor code development. Thinking how to let the robot operate in a reliable way without need of some feedback mechanism. Feed-back mechanism may improve accuracy but it also takes up space, uses power, needs additional wiring and additional processor cycles that could have been used to move the robot.
Are you sure? yes | no
Completely mapped Enable, direction and step control for the Thor robot designed for high speed control. The Arduino methods are too slow for what I have in mind and I wanted to control and change direction of every stepper-motor simultaneously.
C++ compiler issues forces me to adapt my coding style to what the compiler makes out of it. It seems that not everything in the C++ compiler for the Arduino Due is implemented as you would expect. It is probably more mature for the Arduino Mega/Uno.
Finding examples for the Arduino Due is also harder to find. The interrupt mechanism is different and the way to set or reset a PIO register is also different.
Are you sure? yes | no
It seems that inside classes the C++ does not like "MyClass* myClass=new MyClass()" on the Arduino Due. Dynamic memory allocation seems not to function nicely.
So the redesign will use only static created classes and use #defines to allocate memory in chucks during complilation time.
Are you sure? yes | no
Finally success, but I still do not completely understand why. I have all 96 KB now (tested up till 90 KB)
Are you sure? yes | no
I seem to have hit a stone brick wall in memory allocation for my project. I seem not to get a reliable byte array. I should have 96 KB of static memory, but everything suggests that the compiler somehow messes it up and I seem to overwrite programming memory when I use it.
Verified over and over again and I do nothing wrong if this was Windows C++.
The Thor board Ultratronics v1.0 uses an Arduino Due processor.
So I need a redesign in what I wanted to do.
Are you sure? yes | no
The Arduino Due processor has an interesting protection that prevents you to write wrong data to wrong GIOP pins. I do not understand it yet but as a safety feature to prevent accidental activation of the motors by a computer bug, this could be very interesting.
Are you sure? yes | no
Tested the motor stepper controls at speed of 32 Khz and no smoke to see on all 7 motors at the same time and have still about 92% CPU time left. We are at a stage where we can now implement programmable motion.
First steps will be with predefined test patterns.
Are you sure? yes | no
I got it!
X axis step is hooked to D35 --> which is the mapped to PC3.
Now for the Due we set the signal to high through the command REG_PIOC_SODR = PIO_PC3;
And we clear that bit with the command REG_PIOC_CODR = PIO_PC3;
The difference between the stepper pulse seems to be 40 ns. For 7 steppers this would mean 7 x 40 ns = 0.28 µS (53 times faster than digitalWrite(X_AXIS_STEP, level)
Are you sure? yes | no
This Arduino Due is driving my crazy. All I want to do is set a pin to high and 2 µS later to low. But its processor Atmel SAM3X8E ARM Cortex-M3 CPU appears to have a write protection mechanism.
The Atmel SAM3X8E documentation is not very clearly explained how to us it.
The Standard Arduino function digitalWrite(X_AXIS_STEP, level) is too slow. I lose 7 x 2.xµS = 15 µS accumulated for 7 stepper motors.
And the standard Arduino Uno family works differently to set bits directly.
Are you sure? yes | no
Success! The core code to drive the stepper motors is functioning. The key is to drive 7 stepper-motors simultaneously at a predictable and continuous speed.
The interrupt driven code for a Arduino Due is different than for an Arduino Mega.
Next stage will be to extend the code
Are you sure? yes | no
Hahah, silly me. If you ever wonder why your stepper motors do not turn and your stepper driver does not get enough voltage to trigger the pulse, that is because you forgot to set the GIOP to output!
Are you sure? yes | no
Finally more free time for myself coming. And I have my logic analyzer to see what I am doing. Time to do some more coding of the core code that moves the motors.
Firsts steps will be to see if I can easily move all 7 motors at one go (this is why I bought a 16 channel logic analyzer). Particular interested is to see how the timer interrupt creates predictable and continuous timing pulses. This will become important if you move large loads (smooth acceleration/deceleration)
Are you sure? yes | no
Back from holiday and ready to continue toying with electronics.
And when I was away I received an official Saleae Logic Pro 16 (Red) package This was a nice welcome home present. It is very expensive compared to a $10 clone but one should not forget that the cheap clone is using Saleae software which is the equivalent of pirating.
I think the device is worth it, it is a solid metal casing and it does weight a lot. It also comes with quality wires, and quality hooks. And on top of that a big bag to carry it.
The story how I get it ordered is one hilarious piece of story no one will believe that it ever happened.
Are you sure? yes | no
It seems that Hobbytronics can't reproduce the issues I have with the USB hots controller. And they don't see anythign wrong in theri code. If anyone else could reproduce the issue then please be my guest.
All you need to do is to hook up it to an single Arduino I2C connection and let it ruin in a closed loop to request the PS3 status. (Use the debugging led in order to see it is still running or got frozen). The freeze can take many minutes.
Are you sure? yes | no
Caught it! The USB PS3 host controller freezes and everything suggests a firmware issue.
Last week I did not have the tools to visualize the issue with hardware tools, only through Serial communication debugging. So I ordered a logic analyzer and I built my own cheap DSO138 oscilloscope to actually see and measure the issue.
From electrical point, there is nothing specially to see when that happens when it freezes the Arduino. I2C communication just stops. I expect the Arduino standard I2C communication not to have a time-out mechanism and it waits indefinitely.
A watchdog timer can of course fix this issue but I want to fix this issue for ocne and for good.
Are you sure? yes | no
The €10 Seleae logic analyzer (Chinese clone) is a big help in determining I2C issues. The SDO138 oscilloscope (self build €38 including acrylic casing) seems not to be fast enough to identify high frequency noise in the data. But the I2C data is clearly visible.
Are you sure? yes | no