After the OSADL Lugano talk & demo on the portable RTAPI / BeagleBone 3D printer, Alex and me have decided to do another stunt, this time we shoot for the CeBit 2014 fair and the associated Linux conference track: http://www.pro-linux.de/news/1/20441/cebit-2014-call-for-papers-gestartet.html .
my goals for this event are: - we plan to reach a wider audience, and the german CeBit is a good venue for that, in particular towards the german industrial base - we specifically plan to show, and have ready by the time, a second demo which is clearly 'non-CNC', intended to address the wider scope for process automation which I feel entirely feasible once the realtime APIs are a bit more generalized and usable from non-NML clients. This is also a welcome time goal to finish a piece of work to the extent it's 'reliably demoable'. - 'jump the hoop' on a Android-based UI working over the NML successor stack, with the intent of paving the way for post-PC UIs in a wider form. My current plan is to take a typical Arduino-based self-balancing robot kit, rip out the Arduino, replace the RT control by a BB HAL/RTAPI setup, and have the whole thing remote controlled by an Android-based UI (wifi). Ideally we could control the robot by using tablet gestures like tilting. For the hardware, I'm still looking for a kit along these lines: http://www.kickstarter.com/projects/tkjelectronics/balanduino-balancing-robot-kit - happy to take suggestions on something cheap and available now; we would need a few of these (Alex, me, maybe Charles can be dragged into helping with the accelerometer/gyro interfaces which would likely be SPI). Any suggestions welcome. I am specifically looking for a cheap kit, the reason is: in this case several folks might chip in and work on the same hw base; this would not be the case if several people start with parts from the junkbox. Also, the accelerometer and gyro should have separate assemblies (not everything on a single PCB). For the software robot side, I'm assuming for now we can replicate the control algorithm(s) as a HAL setup, including hw interfaces, control loops, Kalman filter etc. After a cursory look I think that is feasible even if unchartered territory as far as HAL comps go. It is unclear atm if motion as it stands will be part of the demo, or if we need to cook up something more specific or adapt the code. For the software control-side, this would amount to a Qt-based application a bit along the lines of gladevcp, plus the zeroMQ and protobuf stacks which should be readily available for that platform. I am betting on Alex's UI skills here but looking at his http://qremote.org/ site and application I think this will work out. -- I'm writing this to tap into the community wisdom and let you know how what follows does fit into the overall plan, maybe somebody has applicable experience with hardware and software of that kind, and recommendations. I am aware this is a rather ambitious plan, but then I'll take grandiose failure over not trying any day. We'll keep a fallback position with the 3D printer 'only' in case this turns out infeasible or not feasible in time, but there's a good chance it will work out, it's still 3 1/2 months to go. The next milestone is the paper deadline Jan 6, 2014 so we better know by then whether it's Plan A or Plan B. -- As for the status of the NML-replacement work, I am right now molding an initial implementation of the Status Tracking Protocol into a library API, since this will be used by several status producers and consumers. Based on that the next step is to replace the EMC_STATUS usage in task and the Python linuxcnc module by this STP library API to get this communication path NML-free. Provided the ship is still afloat, then the other parts like the Tcl NML API, and then onto the queued command interface. Due to changes in my private life I am not as free to work on the theme as I used to, so any help and critical feedback would be welcome - sometimes I do get the impression I am talking against a wall of solid disinterest, maybe some not-invented-here here with rather few exceptions (thanks btw!). Not that this deters me, it's just a bit irritating to see this complete disinterest in a viable longer term evolution path for the project. But then the impression might be wrong, or folks just might have radically different ideas about what 'development' and 'maintenance' actually mean. - Michael ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
