[Kevin] wrote in to tell us about the robotics development platform he’s been working on for the last few years. He calls his device the DyIO, and looks like an extremely easy way to get a robot up and running quickly.
Because the DyIO stands for Dynamic Input & Output, [Kevin] thought it was important to put 24 separate IO pins in his build. These pins can serve as 24 digital inputs or outputs, a few analog inputs and PWM outs, or even DC motor controls.
What’s really interesting is the SDK that [Kevin] and his team chose to build. With this SDK, you can program the DyIO in Java or just about any other language you would want. Already, [Kevin] and his team have built a few interesting projects around the DyIO, like a hexapod robot and animatronic pokemon. While we’re sure something awesome beyond imagination is waiting to be built with the DyIO platform, you can check out these already-completed builds after the break.
[youtube=http://www.youtube.com/watch?v=GKUSfpVwS3E&w=470]
[youtube=http://www.youtube.com/watch?v=g_3gD6SjZqk&w=470]
Can’t seem to access the site to check out the board.
do de doo, check hackaday…. 0_0 holy crap! my stuff’s on hackaday sweet!
trying to get the site back up. sorry!
we’re back!
As a robotics engineering student from WPI where the DyIO is used in core robotics courses, I feel compelled to say that this system has caused more headaches than anything else I have encountered.
The SDK continuously changes without any warning at Kevin’s will and undoes weeks of hard work. Additionally the hardware is a pain to interface with or debug with official support being a far afterthought. Lastly, the DyIO itself is incredibly overpriced for what it offers at $149.00 compared to other cheaper microcontroller options on the market that could be extended to match the IO capabilities listed above and already have vastly superior support communities.
I will end by saying that your mileage may vary but on behalf of the students that have used this platform since its infancy, it still has a very long way to go.
Could you please be a little more specific? We have pushed out SDK updates and firmware updates over the life of the device but we never broken an interface or removed a feature. I’m not sure how this counts as “continuously changing” When a problem is brought to our attention, we fix it and this results in an update. We recommend keeping the SDK and the firmware up to date.
If you have specific concerns then please contact me through the website, we would really appreciate your feedback.
I’m also a robotics engineering student at WPI, and as Max said, the DyIO has been exceedingly difficult to work with. Sorry, but this really isn’t worth $150.
Inside it’s a PIC24 (or 32, can’t remember) and an ATMega 644P with supporting stuff, a few FETs that burn out somewhat easily, and a USB-to-serial converter.
This is not the hardware you want to use if you are a fan of interrupts or otherwise not waiting for data.
The reason for this is that the program you write does not run on the DyIO itself, but rather a computer attached to it by either USB or a yet-to-be-released wireless connection.
Don’t expect to be able to do things like fast line following, because the latency in the USB-to-serial connection dictates otherwise, and there’s no way around it. ANY sensor reading or writing suffers from this delay. It can be minimized by using listeners in Java, but there’s only so much that can be done.
It draws power from the USB connection too, despite having a battery connected.
Mounting isn’t with screws as there aren’t any mount points on the case for it.
I have experienced the “DC Motor Output” channels flat-out stop working from one code run to another, and then have it never work on a replacement DyIO.
Pins are numbered, but signal/power/ground are not marked on the case, which means you have to look it up every time you forget.
So far there’s only a Java API, with a minimum of documentation. The wiki has so-so examples, but seeing the word “Bowler” every third word in a description is irksome.
One group in my robotics class went through six of these due to the FETs, or other problems that were solved by saying “eh, try putting a new one in” because WPI bought more than a hundred of these.
Yes, We are using a PIC32 for communications and real-time tasks and an ATMega 644p for IO. The ATMega is being used like a fancy port expander and being run at 5v.
We have received feedback and are cleaning up our documentation and making the examples more easy to use. We’ve recently cleaned up our whole wiki and I recommend you take a look.
We recommend using the PID Controller. A lot of these problems can be solved by using a control loop, For example, using the PID controller with light sensors as inputs and the drive servos as outputs to do line following works remarkably well. Expect this to be written up in the wiki soon.
As for the FETs, I recommend not switching the rails while the device is powered. The switches should be thought of as jumpers and they’re small and recessed for this reason. It won’t fail right away but if you’re drawing current and you switch then there is an increased likelihood of failure. So, disconnect the battery or turn off your bench supply before changing the rails from sensors to motors.
If you short the power rail to ground then you’ll damage the channel.
and keeping in mind that the signal always faces inward (Its the industry standard servo pinout with power in the center).
One problem i’ve run into is when I have long cables (or loose cables) and am running servos the power rail dips sometimes (This also happens when the batteries are low). The DyIO will detect this and disable servos and motors and push up an async packet that you can listen for in your code. If you don’t have the listener set up then pay attention to the center LED, it will flash purple.
If it flashes purple and the motors or servos stop working then check your battery, power cabling, etc.
Dont want to be rude, but that seems like an (even more over-priced) Arduino running firmata and simple serial calls wrapped in sintatic sugar to call it a SDK.
You raise a good point, we are aware of firmata and its is a commendable effort. However, we prefer our RPC & Namespace mechanism. One of our design goals was to allow for the capabilities of a device to be queried and to abstract specific feature sets behind common interfaces. For example, the configurable multi-channel PID controller interface on the DyIO is the same one that is used on advanced robotics controllers being used in grad research. We often use the DyIOs to test our software since the interface is the same.
And “Syntactic Sugar” implies that everything lives on the computer. The DyIO is not only basic IO manipulation, There are several realtime tasks that run on the device from controlling the velocity of servos to the Integrated 8 channel PID controller. These run in hard-realtime on the device and have been used to make an auto-tracking ultrasonic sensors and even line following require no computer intervention.
Many of these things can be implemented my yourself on a microcontroller and if you choose to go this route i wish you well, but the point of the DyIO is encapsulating a subset of features that you can use from a higher level language without worrying about embedded code.
[Not actually] new arduino mega clone with extra XML? No thanks!
We don’t use XML. the packet format is all binary, check our wiki for details.
http://www.youtube.com/v/?version=3&feature=player_embedded
I am a terrible programmer so I am a fan of the NRConsole’s quick start capabilities. I designed a Hexapod inspired by the Lynxmotion kits a few years ago but never got around to picking a micro-controller and programming it. With the DyIO and NRConsole I had my Hexapod standing up in about 5 minutes.
product burn…. isn’t publicity a bitch..
they Dyio is the worst controller i have ever used. I am a WPI student and Kevin came in to our class to teach us how to use it and explained how to write code. He stressed the importance of comments but if you look at their SDK it has no comments that make any sense. For most things i had to either figure it out of go ask Kevin how to do it because the documentation was so poor.
WPI purchased about 200 DYIO at a huge expense and were so displeased with the product that they are no longer using them to teach classes. The DYIO is a huge wast of money.