a_t48

17 ms·

1. 331.▲
   by a_t48 2y ago

   I'm not opposed to cold outreach, we've done that plenty, though without much success. I'm opposed at the scale where I need to have "warming tools" for my email address. It's very possible that it makes me a b
2. 332.▲
   by a_t48 2y ago

   I'm in the position of needing to do a lot of outreach to find our first customers. If this is actually what I have to do, I refuse. I'm sure there's some good advice in here, but most of it seems gross. I don't want to
3. 333.▲
   by a_t48 2y ago

   I agree. :) We don't specify an OS version, we allow arbitrary process boundaries, we use plain old CMake. Our perception story isn't great, yet. We have some tooling which could make certain GPU workflows easier, but have only pr
4. 334.▲
   by a_t48 2y ago

   This looks cool, interested to see where it goes in the future. Going to be a pest for a minute - have you considered a stack other than ROS2?
5. 335.▲
   by a_t48 2y ago

   Ah, I didn't read carefully - https://stanfordhealthcare.org/medical-conditions/sexual-and... . is my source, this was for acute infections. Regardless, it's still more than an order of magnitude of difference
6. 336.▲
   by a_t48 2y ago

   Yeah you’re right, I’m not sure why I wrote it that way.
7. 337.▲
   by a_t48 2y ago

   GPIO - I have a small "robot" running off of a Pi5, this will speed up compile times.
8. 338.▲
   by a_t48 2y ago

   Receptive PIV sex has 2% transmission rate, PIA is 20%. Cis men don't have a vagina, so...
9. 339.▲
   by a_t48 2y ago

   OTOH the OS can very much get in the way. If you're using ROS for instance, it's easy to fall into apt package dependency hell - upgrading CUDA means upgrading the OS, which means upgrading ROS, which means upgrading all deps incl
10. 340.▲
    by a_t48 2y ago

    My goal is determinism specifically around message timings/execution in replay. We don't currently advertise runtime determinism, we also don't promise fixes for determinism in your code. For message timing, the algorithm sho
11. 341.▲
    by a_t48 2y ago

    Nice release - deterministic replay isn't easy - I still need to go back and pull our implementation forward to match the new features in the core framework. I'm not sure if you've seen Basis, but we're somewhat "co
12. 342.▲
    by a_t48 2y ago

    Very interested in this - I have a SNES flash cart, I wonder if there's a good basic library to handle printing to the screen and such.
13. 343.▲
    by a_t48 2y ago

    Thanks for the reminder to make the concepts section of my site easier to read. :)
14. 344.▲
    by a_t48 2y ago

    Same :) I started down the rabbit hole of abstracting CUDA for our robotics framework, but it’s not really something I want to maintain right now.
15. 345.▲
    by a_t48 2y ago

    Im going to have to give your CUDA wrapper a look later. :)
16. 346.▲
    by a_t48 2y ago

    You don't have to actually copypaste. You can use CMake and FetchContent/CPM. You can specify custom build commands or inline declare a project for anything small that you pull in that doesn't use CMake (you can call add_libr
17. 347.▲
    by a_t48 2y ago

    I believe HSMs can model this, but don't quote me. :)
18. 348.▲
    by a_t48 2y ago

    In a past job I implemented these with heavy use of C++ operator overrides. Not the prettiest option, but it stopped the six id/index types I was using from accidentally getting misused. Something like - ObjectId, Resource Id, User Id,
19. 349.▲
    by a_t48 2y ago

    I agree the situation is nutty.
20. 350.▲
    by a_t48 2y ago

    Regardless of the danger or not of getting in a strangers car (and in comparison to getting into a known person's car), children are taught to not do it.
21. 351.▲
    by a_t48 2y ago

    Please, we drill into kids heads to not get into cars with strangers.
22. 352.▲
    by a_t48 2y ago

    Did they consider iceoryx2? From the outside, it feels like it fits the bill.
23. 353.▲
    by a_t48 2y ago

    I saw these guys present at Actuate a few months ago. Really cool stuff.
24. 354.▲
    by a_t48 2y ago

    See https://docs.basisrobotics.tech/guide-tools/launch-files#pro... - our launch file documentation needs some work, and I think it's probably good if I put the nodelet/codelet/process stuff in the main
25. 355.▲
    by a_t48 2y ago

    We're single process! Multi-process is opt in (it's useful to toss your telemetry and other non-critical code in a separate process so a crash doesn't take down everything), our units are libraries by default. When you make a
26. 356.▲
    by a_t48 2y ago

    Only a little crazy - you'd have to use ros1msg or write a ROS2 message plugin. And then link together basis+Gazebo or write a bridge (bridges aren't too hard - see https://github.com/basis-robotics/basis&#x2F
27. 357.▲
    by a_t48 2y ago

    I'd like to very much encourage protobuf as the serializer, but supporting others both gives users the freedom to pick their own tradeoffs, and makes it 10x easier to transition from ROS or another framework. We do support JSON output
28. 358.▲
    by a_t48 2y ago

    We will eventually have a binary distribution. I chose not to for this release because it's not the workflow I want to encourage, and due to the management overhead of having to create packages for every combination of hardware/OS
29. 359.▲
    by a_t48 2y ago

    We do have https://docs.basisrobotics.tech/guide-getting-started/enviro... and https://github.com/basis-robotics/basis-examples/tree/main/c... but I want to improve our first time
30. 360.▲
    by a_t48 2y ago

    Swarm robots: yeah, this is a really cool, but somewhat specialized for now use case. Would love to support it. Message definitions: ros1msg does make this a little painful. Protobuf at least lets you have differing schema versions, and wil