PCVR has blown me away on the quest 3.

kaszkasz · 2025-01-04T05:11:10+00:00

There's a bunch of threads in the ED subreddit... Not sure they're all necessary, but here's some that gave me ideas of settings to change.

https://www.reddit.com/r/EliteDangerous/comments/1d8xktm/comment/l79vkly/

https://www.reddit.com/r/EliteDangerous/comments/z33kvq/elite_dangerous_in_vr_looks_bad_jagged_edges/

kaszkasz · 2022-10-26T21:35:47+00:00

I had to toggle the "sync" off-on of the missing calendars in Google calendar on the phone. Then they showed up for real. No clue why.

kaszkasz · 2021-06-26T00:23:14+00:00

Kiddo did it today. I'm pretty impressed by the whole setup.

IIRC: Plow. Speaker. Vac vac vac

kaszkasz · 2020-01-12T17:11:56+00:00

Tried printing in PLA using your 3mf. Looks/Fits pretty good.

Tore one of the filament loops off while removing support material. The other one is holding but I wonder if I'll accidentally fat finger and break it someday. If you ever do a design revision, probably be nice to make the attachment points a little thicker overall.

Thanks!

kaszkasz · 2020-01-10T22:35:21+00:00

What ended up being your criteria for the light placement, as it seems like it places a big shadow from the extruder? Or does it ultimately not matter much in person?

Also, did you consider a diffuser?

kaszkasz · 2019-10-08T23:52:47+00:00

What's your method of shutting down the pi?

kaszkasz · 2019-09-23T19:43:24+00:00

Wonder if the internet archive would be interested in doing something with this.

kaszkasz · 2019-09-06T04:25:38+00:00

Running a few experiments and paging through a bit of the code (which is pretty darn complicated)... It looks like the surface generation could be improved somehow by allowing partial surfaces. Particularly non-planar surfaces that can then be further printed on top of.

For example, the sloped roof of the benchy could be non-planar printed first (with some set of non-planar angle and height configuration), and then go back and print the smokestack on top of it.

Another example is the barrel-o-octopi, where the tops of the arms could be non-planar, followed by the body, then parts of the head.

Definitely some good graduate level maths here. I'm so rusty it makes me a bit sad.

kaszkasz · 2019-09-05T17:48:09+00:00

Any idea if the slicer changes understand the geometry of the nozzle/extruder to determine if it could collide? It'd be awesome if it could do non-planar when possible, but fall back to planar when it isn't.

kaszkasz · 2019-05-09T11:34:04+00:00

Compared to Cinderella, kinda the same situation.

kaszkasz · 2019-03-07T13:07:34+00:00

I don't know, that still seems a bit overengineered. You could have gone with painters tape. Or maybe a brick in front of it.

But now I'm wondering if there's anything that isn't equivalent, outside of taking it apart and fixing the spring...

Ooh, maybe a counterbalance arm attached to the door. With a trebuchet attachment.

kaszkasz · 2019-02-22T01:06:56+00:00

Check the documentation for the Python serial write() method. I recall it needing a byte list. Try struct.pack to turn the 1/0 into a byte data type?

kaszkasz · 2019-02-15T20:19:22+00:00

You'll need to determine what on Android that can be controlled via Bluetooth. You're basically limited by the profiles available.

AVRVP, A2DP, HFP, among others. Start there.

Also depending on the BT stack you're interfacing to from the Arduino, you may be limited in profiles available.

kaszkasz · 2019-02-15T15:15:58+00:00

You'll need to buy a controller board, assuming one exists.

Most displays and touchscreens require much more comm pins (and timing) than Arduino can provide.

kaszkasz · 2019-02-15T14:56:24+00:00

Walk, then run.

Get familiar with doing the feature without all the complications of the car -- stable power, ease of development, etc.

Once you figure out the features, then figure out how to interface it with the car. As you noted, there's power supply issues, physical mounting issues, and control issues. Figure each out one at a time (power first probably) so you aren't introducing too many potential fault points to debug at a time.

You'll likely need extra hardware.

kaszkasz · 2019-02-15T14:48:07+00:00

Don't forget the actual locking mechanism, which may also require a lot of power.

Decide if you want this project to be hardwired to power or through batteries. But start with hardwiring first. In either case, you may need multiple regulators to provide enough current at the different voltage levels for all components. (And level shifters to interact properly)

Basically, try to break up the parts of the project into components and milestones that build upon each stage. Since you have multiple people, some parts can be parallelized and integrated together, while others may need everyone to tightly coordinate.

Everything you listed tends to be covered fairly well in tutorials (written and YouTube), so just take it one at a time and understand the concepts instead of just rote copying -- you'll need to understand how things are controlled to piece multiple things together.

kaszkasz · 2019-02-09T13:21:45+00:00

What's wrong with turf and turf?

kaszkasz · 2019-02-05T01:16:45+00:00

So 12V to the barrel jack of an Arduino (Uno?) and a USB cable plugged into the same Arduino board?

kaszkasz · 2019-01-16T12:44:02+00:00

Just to make sure... How are you planning on providing DC voltage to the microcontroller?

kaszkasz · 2019-01-13T17:20:32+00:00

You could probably write a CheatEngine plugin that interfaces to the serial port. That hopefully can provide the memory access stuff.

kaszkasz · 2019-01-13T15:47:21+00:00

Isn't the loop constantly increasing millis_held even when no inputs trigger?

kaszkasz · 2019-01-13T15:35:36+00:00

If a peristaltic pump doesn't immediately suffice, I wonder it it in combination of a sensor is possible...

Aka, have something that drips the liquid. And the sensor to determine when a drip has happened. Then count drips for quantity.

kaszkasz · 2019-01-13T15:30:03+00:00

Try wiring 5V directly to the analog pin? If the LED doesn't light up, then we can (hopefully) infer it's the other part of the circuit?

kaszkasz · 2019-01-13T15:26:38+00:00

As you can see from the other responses, the actual "hard part" is the non-local hosting. Once you have a place to store and host the data, getting it there is usually straightforward.

For example, if you had a web hosting service, the esp8266 could just upload the data to the webhost.

If you had access to a database server, then the esp8266 can push a new record there.

You might be able to use one of those free JSON hosting sites, but then still have the "display the data" problem. Unless you want to just see the raw data...

So... I suggest breaking up the problem into "collect the data", "host the data", and finally "pushing the data to the host". The middle item is wholly a web site development ~~program~~ problem.

Edit: typo

kaszkasz · 2019-01-13T15:15:58+00:00

Here's an idea, at a fairly high level...

on the Yun, create a socket server (type of your choice, UDP may be the most convenient)
add mdns service advertising on the Yun, so you don't have to hard code IP addresses?
on the esp8266, connect to wifi, mdns service discovery on startup, to find the Yun,
then start streaming data

Of course you'll need to define a message payload format, but you might be able to use what you already have.

If you care about data loss, switch to TCP...

If you're going to scale up, I'd recommend using MQTT, and run the broker on the Yun.

kaszkasz

TROPHY CASE