|
From: Kyle M. (qDot) <ky...@no...> - 2009-04-06 05:46:03
|
So, I spent this weekend working on libnifalcon and got quite a bit done in the way of internal fixes and stability. But, most importantly, fading lights! Decided to trying a variable duty cycle algorithm using just the USB communications, and it turns out that you can get a smooth ramp for all 3 front panel LEDs with a around a 20ms duty cycle. So, 4.25 bits of color per LED! It actually looks pretty nice, even though there's no internal defuser so you still get the directional issues from the LEDs being point sources. This has been added as FalconColorTest in the falcon_test_cli example. I'd upload a video, but it looks like crap on recorded video. Damn you, Nyquist! However, this brings up more important issues, like the fact that I also kind of changed the way I do all the array passing internally. :) Since I decided to go ahead and use boost::shared_ptr for the pimpl stuff in FalconDevice (I really don't know what the hell I was thinking when I first put all this together, other than just not having written drivers like this before and not sure whether I could force people into using libraries, but, well, experience now tells me that I can, and if they don't like it, they can go write their own. :) ), I also decided to move all of the gross array reference passing to just use boost::array. Unfortunately, this is gonna break... Well, pretty much everything that needed to get positions or set forces. So, as not to completely screw everyone who's actually working with the library, all of this (array passing and fading lights) is off on its own branch for the moment: http://github.com/qdot/libnifalcon/tree/boost-array-params I really don't think this is going to cause too many issues with everyone's libraries (just change what goes into/out of these functions, everything else just looks like an array otherwise), and should hopefully be nearing the possible end of major external-facing function signature changes. I'd like to keep everything outside talking in arrays (versus vector objects from a math library) so that we maintain a level of abstraction between any specific math and just wanting to get data back and forth, especially with the upcoming move from gmtl to eigen inside libnifalcon. I'll also probably be updating the np_nifalcon external binaries and code soon, as I've been getting a few requests for that lately anyways. |