Over the last few days, I’ve been playing around with Texas Instruments’ SensorTag device, working out how to connect it to AutoCAD and make use of the data coming in from it to manipulate the current view.
As mentioned in this previous post, the SensorTag is a $25 device containing a number of sensors – an accelerometer, a gyroscope, a magnetometer, a thermometer, a hygrometer and a barometer – that communicates to a monitoring system (whether an iOS or Android mobile device or a Windows or Linux PC) via Bluetooth 4.0.
So what is it I expected to do with this device? Well, I liked the idea of connecting one or more of the spatial sensors to AutoCAD, so that when you move the device, things happen in your model. My initial focus is on navigation – as you move the device around your view onto your 3D model changes. We’ll see if, over time, it makes sense to make use of other sensors to drive the model (or other) changes inside AutoCAD. The same mechanism could almost certainly be implemented using a smartphone rather than a SensorTag, for that matter – at least as long as we’re just using data from the accelerometer – but I’m interested in the idea of this being made to work with a cheap, commodity (and therefore easily dedicated) device.
When I first got my SensorTag, the first thing I did – aside from building the thing and getting the Android app working to get a sense of the data coming from it – was to go out and buy a cheap USB Bluetooth 4.0 dongle (as neither of my current PCs are equipped with a built-in Bluetooth 4.0 chipset). After some frustration – and reading the SensorTag forum – I gave up: it turns out you really need to get the TI version of this device (their CC2540 dongle) which has a driver with the ability to map a COM port for communication between the PC and the SensorTag.
On a side note, it seems Linux doesn’t have the same requirement, so at some point I’ll plug the Trust dongle into my Raspberry Pi and try to get that working.
So back to getting the SensorTag talking to my PC… I knew I needed a CC2540 dongle – and a CC Debugger to be able to flash the CC2540 device – so I started looking at my options for getting those in a bundle (the dongle and the debugger cost $49 each if bought separately).
The first possibility was the CC2541 Mini Development Kit, which – for $99 – includes a dongle, a debugger and a “keyfob” device with a few basic components (LEDs, a buzzer, two buttons and an accelerometer).
The second, the CC2541 Bluetooth Smart Remote Control Kit – for $50 more at $149 – was ultimately more interesting to me: aside from the dongle and the debugger you get a Smart Remote Control which contains a gyroscope, an accelerometer and a whole lot of buttons (it’s a remote control, after all).
I figured that even connecting to the SensorTag didn’t prove interesting, I could probably get the Smart Remote working with AutoCAD. And, failing that, I could pair my Smart Remote with my Windows 8 machine via the Trust USB dongle and use it as an air mouse. Which should be very handy during Kinect demos, in particular. :-)
The kit ended up being delivered really quickly – and with free worldwide shipping, too! – so I had almost no time to think about the project before diving into the details. At least for once I didn’t have to sit around twiddling my thumbs, waiting for the postman. ;-)
In general, the approach for getting your custom software to communicate with the SensorTag is fairly straightforward: you will probably end up installing various bits of software from TI (and frankly it’s pretty clear from these tools that they’re fundamentally a hardware rather than a software company), the most important of which is probably BTool as this does the work of configuring the driver to map a COM port to be used for communication between the master (the PC) and the slave (the SensorTag). Once things are configured and working, you should be able to talk to the device by reading from and writing to the COM port.
I used the C# project at this post as a starting point, fooling around with it to chain together sequences of commands, to connect and turn everything on with a single click:
I then worked on understanding the visualization code on the second tab, to determine how the input data might be used to control the view inside AutoCAD:
Judging from the behaviour of the 3D visualization, it seemed enough to make use of the accelerometer data: no need for the gyroscope or magnetometer data for now, at least.
As with the sample app, in my prototype I followed the approach of firing up a thread just to listen for data coming in from the SensorTag: this can then be set somewhere where the UI thread can pick it up and use it to adjust the view.
On the AutoCAD side of things, I used the fairly standard approach of having a jig that doesn’t do very much other than keep turning (forcing the message loop to process by setting the system cursor position inside the Sampler() function) and use that to adjust the view when there’s data that we care about.
Because the accelerometer measures weight changes along three axes – and isn’t a perfect indicator or orientation in 3D space – over time the view will get slightly out of sync with reality. I address this by letting the user reset to the initial view whenever they hit the Enter key, and the orientation gets adjusted relatively from that point onwards.
I won’t share the code, as yet, as it’s very much a work in progress (and without meaning this in a negative way, the project I used as a foundation looks as though it was put together by a very good hardware engineer ;-). I’ll need to spend some time refactoring the code before I’m comfortable posting it.
Here’s a video of the application in action:
The latency seems pretty acceptable. I initially pushed it down to the minimum value of 10ms between reports for the accelerometer, but found that, over time, the backed up messages affected performance. Adjusting this upwards to the – still plenty quick enough – value of 20ms made the system work much more predictably.
I will say that the lifespan I had from my first CR2032 battery was much shorter than expected (less than a week, as opposed to the “years” that had been suggested on the web), but that could also be due to the thrashing I’ve been giving it, as well as the possibility it was left enabled sending out high-frequency reports over an extended period (it’s sometimes hard to know when the device is paired and active). I’ve since stocked up on these batteries so I can get through to the end of AU, at least.
Thanks again to my friend Simos Kozanidis for the gift of the SensorTag I used to connect to AutoCAD. If you ever fancy a career change, Simos, you might consider asking Texas Instruments if they need any local salesmen. ;-)
