You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ASSEMBLY.md
+20-24Lines changed: 20 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,25 +2,17 @@ Blot instructions
2
2
---
3
3
Below is a list of all parts needed to construct your Blot. Keep in mind that the colors shown below are not representative of the actual color of the components. The components are colored differently to ease differentiation when going through these instructions.
|[Eccentric<br>Spacer](https://www.amazon.com/Micro-Traders-Eccentric-Aluminium-Extrusion/dp/B09CYK9P43/)|5 |<imgsrc="https://cloud-agax6w6e0-hack-club-bot.vercel.app/8image0055.png"alt="aaa"width="100"/>||Motor Leg |2 |<imgsrc="https://cloud-dxz9fnfpj-hack-club-bot.vercel.app/3image0065.png"alt="aaa"width="100"/>
@@ -210,4 +206,4 @@ Create another belt bearing assembly and ensure the belt is behind it.
210
206
Here comes the hardest part: routing the belt. Ensure it goes around the shafts of both motors, and runs between the belt bearings within the carriage.
211
207
212
208
---
213
-
At the belt clip, bend the belt around on itself (with the teeth facing outwards) in order to hold it tight.
209
+
At the belt clip, bend the belt around on itself (with the teeth facing outwards) in order to hold it tight.
I was finding it difficult to debug with the cobs encoded messages coming up from the device so started using cobs encoding to send messages but using new line (`0x0A`) delimiters to differentiate messages being sent back.
33
+
34
+
I was finding it difficult to debug with the cobs encoded messages coming up from the device so started using cobs encoding to send messages but using new line (`0x0A`) delimiters to differentiate messages being sent back.
34
35
35
36
The print function is useful for debugging arrays.
So far this has worked pretty well for me, but Shawn is still reporting some issues so we need to run more tests.
92
93
93
-
Moving on to some other parts of the project. I wrote up a [doc describing an engagement model](https://github.com/hackclub/haxidraw/blob/main/ENGAGEMENT.md) for gettine the machine.
94
+
Moving on to some other parts of the project. I wrote up a [doc describing an engagement model](https://github.com/hackclub/haxidraw/blob/main/ENGAGEMENT.md) for gettine the machine.
94
95
95
96
Part of that model involves submitting pieces to a virtual gallery space. I decided an interesting space could be a infinite maze which gets randomly populated with submitted art work. I made a quick implementation of the maze which ended up being a classic raycasting project. Right now it's very Wolfenstein.
96
97
@@ -104,40 +105,39 @@ Here is the draft interface:
104
105
105
106
<imgwidth="1113"alt="Screen Shot 2023-05-26 at 10 44 05 AM"src="https://github.com/hackclub/haxidraw/assets/27078897/ca30829b-d886-4253-8fa9-216b2684c198">
106
107
107
-
I created two ways to make drawings. One is using the Turtle class which lets you create drawings programmatically, and two is by dropping an SVG into the editor which will automatically be converted into a Turtle. You can then use affine transformations (scale, rotate, translate) to position it properly.
108
+
I created two ways to make drawings. One is using the Turtle class which lets you create drawings programmatically, and two is by dropping an SVG into the editor which will automatically be converted into a Turtle. You can then use affine transformations (scale, rotate, translate) to position it properly.
108
109
109
110
In the bottom right corner the editor has a little console. This was somewhat interesting to implement. I wanted it to have access to the functions in the top-level scope of the most recently run script. So you can define functions in the editor and then run them on command in the command line. I did this by rewriting the script a bit before running it.
One design consideration when making the editor is that when a user calls the `runMachine()` function it should run the drawing which is currently visible.
139
139
140
-
Moving on to the firmware. It took a bit of patience to implement COBS properly. Though implementing it in JavaScript recently I willfully ignored doing so for the embedded instead opting to use newline delimiters for the communication stream. The ASCII for newline is `0x0A` otherwise known as 10. 10 periodically does show up in bytesteam encodings, which was giving me some trouble. This is what COBS is for, to give you a known unique character which will occur only at the end of your messages. The challenge in implementing it is my Arduino print statements (my primary debugging technique) no longer worked because the other end of my serial communication connection in the browser was then expecting 0 delimited messages.
140
+
Moving on to the firmware. It took a bit of patience to implement COBS properly. Though implementing it in JavaScript recently I willfully ignored doing so for the embedded instead opting to use newline delimiters for the communication stream. The ASCII for newline is `0x0A` otherwise known as 10. 10 periodically does show up in bytesteam encodings, which was giving me some trouble. This is what COBS is for, to give you a known unique character which will occur only at the end of your messages. The challenge in implementing it is my Arduino print statements (my primary debugging technique) no longer worked because the other end of my serial communication connection in the browser was then expecting 0 delimited messages.
141
141
142
142
The solution is pretty straightforward though. Just implement the encoding and decoding incrementally. So first verify I can encode and decode messages just in JS. Then send encoded messages to the firmware but expect to receive back newline delimited messages so I can read the print statements. Then when I know everything else works encode the messages coming back up and decode them in JS.
143
143
@@ -161,9 +161,9 @@ I acquired some Gelly Roll Sakura pens which I used to make some of our most int
161
161
I made the JS controls function asyncronously by adding a number ID to each message and sending back acknowledgements. This allows us to write code like such:
162
162
163
163
```js
164
-
constport=awaitcreateWebSerialPort(rawPort);
165
-
constbytes=floatsToBytes([x, y ]);
166
-
awaitport.send("go", bytes);
164
+
constport=awaitcreateWebSerialPort(rawPort)
165
+
constbytes=floatsToBytes([x, y])
166
+
awaitport.send('go', bytes)
167
167
```
168
168
169
169
in which the machine actually executes and finishes the command before the await resolves.
@@ -227,21 +227,21 @@ It looks like we'll be using the single control board designed for the drawing m
227
227
- We should still be able to interface with the machine in high-level languages as a virtual object.
228
228
- The motor control should be good
229
229
230
-
These two goals and our approaches to addressing them are heavily influenced by the work we did the Modular Things project. For the first goal we need to define a communication interface. Almost like a REST API for the machine (if you're coming from the web dev world).
230
+
These two goals and our approaches to addressing them are heavily influenced by the work we did the Modular Things project. For the first goal we need to define a communication interface. Almost like a REST API for the machine (if you're coming from the web dev world).
231
231
232
232
Motor control is a tricky topic. Historically most digital fabrication machines have been built around [GRBL](https://github.com/grbl/grbl) recently [Klipper3D](https://www.klipper3d.org/) has risen in popularity.
233
233
234
-
The basic problem is about figuring out how to turn multiple motors who's collective motion results in the movement of the machine in a controlled manner. In the case of our machine we have two motors which are coupled together through a belt.
234
+
The basic problem is about figuring out how to turn multiple motors who's collective motion results in the movement of the machine in a controlled manner. In the case of our machine we have two motors which are coupled together through a belt.
235
235
236
236
In short I managed to write a fairly low quality motion controller (but a functional one) which has constant speed. Preferably we would set maximum accelerations and the planner would figure out the appropriate speeds based on the path it needs to take. But we'll build up to that in the coming weeks. We are sending out machines to testers and developers now so we need to have a nice interface for people to develop devices.
237
237
238
238
Something like this:
239
239
240
240
```js
241
-
import { createHaxidraw } from "createHaxidraw.js";
241
+
import { createHaxidraw } from 'createHaxidraw.js'
242
242
243
-
await haxidraw.servo(-90);
244
-
await haxidraw.moveTo(x, y);
243
+
await haxidraw.servo(-90)
244
+
await haxidraw.moveTo(x, y)
245
245
```
246
246
247
247
This is a virtual machine which communicates with the actual machine through the serial port.
0 commit comments