While Apple doesn’t expose a Bluetooth entitlement in Xcode’s Capabilities pane for Mac apps, one does in fact exist, and it was enough to get the usual IOBluetooth calls working as well. With the .usb entitlement we were able to get all of our USB connectivity code up and running in the Sandbox. The shared process in which device communication happensįortunately, we were able to overcome limitations in all of these areas.The device communication layer underneath RobotKit.There were three areas I had concerns about: In fact, the biggest challenge of the project turned out to be working around the limitations of the Mac App Sandbox, which we spent months working on. A Sandboxing StoryĪs soon as we started the project, I knew shipping Robotary in the Mac App Store would be difficult. This makes it really easy to deploy in schools and labs. Moreover, because Robotary is completely independent of LEGO’s proprietary drivers, it ships with zero external dependencies as I mentioned above. This approach is safer than a driver running in kernelspace as one mistake doesn’t have the potential to crash the entire system. It’s built on top of IOKit and runs entirely in userspace, isolated in separate processes. RobotKit runs on top of a device communication layer we wrote ourselves. RobotKit includes support for interfacing with on-device buttons, LEDs, motors, sensors, and screens, and we’ll continue to evolve RobotKit as we add support for new hardware. lower enum case names) to make the move to Swift 3 as frictionless as possible. Thinking ahead, we designed it with many Swift 3 API guidelines in mind (e.g. On top of the Swift Standard Library, Robotary ships with RobotKit, a framework we designed for safely talking to robotic hardware from Swift. To make installation painless, Robotary is available both inside and outside of the App Store as a single app bundle – more on this later. All of these tools and frameworks are compiled directly into Robotary, so users don’t have to have any external tools installed (including Xcode). What’s more, we built SourceKit directly into Robotary, so syntax highlighting and code completion are driven by the compiler, and our debugger is based on LLDB. By supporting the standard version of Swift instead of a derivative, users get to use the exact same language constructs and APIs they are already familiar with. Robotary ships with the standard version of Swift 2.2.1 and its Standard Library (and we’ll have support for Swift 3 later this year). Inside Lookįrom the start, we knew Swift’s speed, safety, and expressiveness make it a great choice for programming robots ( Brad Larson agrees). Instead of regurgitating features from Robotary’s website, I wanted to explain its inner workings. We thought we could do better, so we wrote Robotary. Unfortunately, they’re not very well-maintained (NXC was never updated for the EV3) and aren’t based on standards (NXC stands for Not Exactly C). On the other side of the spectrum, domain-specific programming languages such as NXC have evolved over the years. They also come with proprietary drivers, take up almost a gigabyte of disk space, and seem to have compatibility issues with each year’s macOS release. Today, there are two means of programming consumer robotics.īlock-based GUI tools (often based on LabVIEW) ship with LEGO Mindstorms but don’t scale well when it comes time to write more sophisticated software. We’re getting started with support for two generations of LEGO Mindstorms robotics sets, with support for more hardware along the way. It’s designed to be so easy-to-use you can teach a week-long summer camp with it, and it’s also designed to be powerful enough to facilitate more complicated projects. Robotary is a robotics studio for macOS that lets entry-level programmers and experts alike program consumer robotics sets with Swift. Today, we’re announcing the first fruits of almost 9 months of work.
0 Comments
Leave a Reply. |