AirPrint or Rasberry Pi

[RI0]

Could we add AirPrint so we do not have to connect to the bot with a cable?
It would be easier for iPads or Android Tablets. RoboPaint should work on a tablet if we could install it or find a way to run it?

I am getting a Raspberry Pi soon - do you think RoboPaint could be installed on the Pi and access to RoboPaint could be done from an iPad through a web server on the Pi - if the Pi was connected to the WaterColor Bot by USB?

http://www.lynsayshepherd.com/blog/2013/01/14/wireless-printingairprint-server-via-the-raspberry-pi/

http://webcache.googleusercontent.com/search?q=cache:iRWhdHqzOiYJ:rohankapoor.com/2012/06/configuring-the-raspberry-pi-as-an-airprint-server/+&cd=3&hl=en&ct=clnk&client=safari

[techninja]

Sooo, here's a little history lesson for you:

• Back in Februrary of 2013, right after @makersylvia returned from Evil Mad Scientist Laboratories, I had her prototype bot in front of me and I wanted to try to get it to paint something.
• Being a web developer I decided to test the waters of the JavaScript ecosystem and see if I could get the bot to move around using a JS interface and pad my CV with knowledge of API design by wrapping everything up with its own web server.
• By March 2013, I had built a whole application capable of drawing SVGs in a web browser via a web app (usable on any web browser) that talked to that same server connected to the robot.
• The Web app was called "WaterColorBot", and the server that hosted it all and talked to the bot was called CNCServer (as I intended the project to have a greater breadth of use than just controlling the WaterColorBot.
• By April 2013, I had most of the editing and printing capability found in RoboPaint in an iPad accessible version, hosted from a RaspberryPi. It was this version of the software, in conjunction with an incredible native iPad app that @robotgrrl built for us using the API that @makersylvia brought with her to the White House Science Fair.
• Somewhere before the release of the WaterColorBot to the public, it was decided that installing the low-level CNCServer was a pain in the butt, so we needed an easy to install version of the program for everyone to use, so RoboPaint was born.
• All the previous functionality was removed from CNCServer, and most of the functionality was rolled into RoboPaint. We've come a long way since then, though one thing we never really got back was the ability to do things remotely via tablet.

Some notes on the status of such a thing now:

• I'm not terribly familiar with AirPrint, but some kind of print server has always been discussed, though never fully prioritized.
• We're working on remote server capability that would allow a copy of RoboPaint on the same WiFi network as an embedded computer running CNCServer connected to the bot to control it fully, though there's still some kinks to be worked out, and though it's in this milestone, is likely to be pushed out further as it's not a common use case yet, and we'd need to fully document setup of the server and common use cases/setups.
• A native app to encompass the standard SVG load and print would be possible with the current APIs, though tricky, and it's certainly not planned.
• Currently if you visit http://localhost:4242 on a computer running RoboPaint, you'll see a very simplistic test interface for CNCServer. We could bring back more of the functionality it used to have, and this could likely use most of the exact same code currently in use by RoboPaint (it's still a web app after all) , but the team has never discussed limitations or full available options something like this may have.

If there's interest from more of our users I'm sure we could get something going, of course as long as we still have bugs and basic features to write, and only one part time developer (me!)... this is likely to take the back-burner for a while.

[RobotGrrl]

From what I understand, if you were to use AirPrint, you would not have any ability to adjust how you wanted the painting executed. ie, no adjustments over the strokes and fill type. It would "just print". If you could edit the settings, you would not be able to see a live preview. Seems to me that this would not be very ideal.

Having an interface to connect to the bot without a cable would be good. As techninja mentioned, there are some ways to do this that are currently in development.

[techninja]

@RobotGrrl is here! We missed you! You may not realize it, but it was your invite to RoboGames 2012 that got Sylvia inspired to make a robot herself, the WaterColorBot. Not to mention all your inpiring hard work with RoboBrrd.

FWIW @makersylvia will be showing off the latest WaterColorBot v2 at RoboGames2015 in the painting artbot competition again. Everyone who can make it should attend, and possibly even discuss this or other issues.

To the matter at hand: Yes, we can do some kind of tablet implementation, and other methods of remote printing. The tech is all there and ready, but the specific AirPrint tech sounds both tricky to get into, and far too "hands-off" for the kind of thing that WaterColorBot actually is, which is ensuring that everything is setup by hand and ready before printing. Imagine having to fill the inkwells and place the single page of paper into a copy paper printer for every single page. Printing from another room suddenly becomes a bit silly.

A situation that might work: A touch screen raspberry PI that lives at the WaterColorBot. SVGs with print settings and requirements are streamed to the bot over WiFi and queued. As it becomes ready to print, an audible tone/sound file is played (or even the origin user is alerted?) and they come over and ready the bot, replace brush, colorset, etc, then press the "print" button, and it shows them on the screen what they'll be printing as it does it.

This is all 100% within the realm of possibility with current standards, and even sounds quite fun! Too bad I'm still only one guy volunteering on weekends :weary:.

[RI0]

I got a MakerBot in 2013 and I tried to find a way to be able to move STL or X3G files to it wirelessly.

I wanted to download files from Thingiverse and print them using an iPad that was on wifi. I really wanted to create things on an app and send it to the MakerBot. It never happened.

My MakerBot only reads X3G files so it was difficult to find a way to do it from a device. It was hard to find a way to convert the STL to X3G on a device. I asked Thingiverse to create a standard X3G file that could be downloaded in addition to the other formats. I think I received a thank you for the suggestion.

The only solution that I found to make any of this work without a cable was to make a wireless SD card work backwards. I can copy files from my computer to the SD card in the MakerBot and then when I walk over to the MakerBot I can select the file from the menu. It works most of the time but not always. It is actually OK this way because I can check the MakerBot is ready before I say GO and I think it would be better to be able to check it before it starts painting.

I also looked at AirDrop but I could not figure out a way to make the MakerBot be a place where AirDrop files could be sent. I think it would have to be an Apple MakerBot. I talked with a Genius about it once when I was changing my iPhone battery I asked if he could create my idea for an AirDrop SD card or AirDrop Memory Stick but it must not have been very interesting.

AirPrint would probably not be the best way to send SVG files to a Robot but maybe AirDrop or some similar wireless file transfer could work.

I like the idea of using a Raspberry Pi as a RoboPaint controller to get the files and make the robot stop and start. Maybe it could be created as an option that could be purchased separately. I would like a Start Button and a Panic Button ( see https://github.com/evil-mad/robopaint/issues/124 ). I think it might be cheaper and more fun to have some real buttons than to have a touch screen. Touchscreen things could be done from a tablet, phone, or computer using RoboPaint or a simple App.

The Paint Server might also be a good test for automatic software updates ( https://github.com/evil-mad/robopaint/issues/163 ) since the hardware would be the same and it would probably not be used for anything else.

Perhaps a free version could also be available for people who already have a Pi. They would not get the buttons or the special case to attach it to the Robot.

It should be able to be connected ( through USB ) to the old WaterColorBot or the new one and maybe even the EggBot.

My sister and I would be happy to help with this project.

[techninja]

Makerbot now has a "wireless system" that connects with the MB. It's likely they have a similar ecosystem as we've described, with a high-level Linux embedded system (or desktop computer) driving a lower level driver board and some internal webservers allowing for tablet access/APIs.

I can't speak to the possibility of hardware button interactions for this setup we describe (as they can be quite limiting as far as input options), but the idea in general is pretty sounds and reasonably well described, and having a touch screen our buttons would likely be mostly interchangeable.

The connection map would be:

(Optional buttons)
  ---[via GPIO]--->
    Raspberry Pi (or other Embedded Linux Dev Board)
  ---[via standard USB cable]--->
EBB on WaterColorBot/Eggbot. 

I'm not sure about where you (or your sister) stand on the gamut of abilities (Design, management, development, etc), but if you wish this project to come to fruition, unfortunately I cannot lead it, only guide it. As Lead developer on this project I'm still working hard to simply "drive the bus" for the majority of "passengers" (our users). If it was clear that a large percentage of our users would be interested in such a project, we'd likely want to work on it officially, but we have no such information.

It being an open source project, and myself being as open to ideas and discussion as possible, means that you won't actually need me directly to make something like this work. As with any of the suggestions here on this "forum" of issues, for big features, the first thing you need is a plan of attack, and likely someone to assign to the individual pieces. Unfortunately I can't help directly much beyond that (with the exception of providing useful direction), at least until we can A: complete all bugs/general improvements, and B: release a feature complete version 1 as originally imagined.

I'm going to start a new issue to create a list of questions for our less interactive WCB users that hopefully we can get into the hands of hardware users and poll them about how they use their bot, or how they might want to use it. If we get lots of feedback about a use case like this, I'd say it's likely to become a higher priority.

[rogerfachini]

@RI0 This sounds like an interesting side-project. I could help with it after the FRC season is over (day or so now), and as long as @techninja doesn't need me for any major work on RP itself.

[techninja]

@rogerfachini You'd likely have to own, live, and breathe this to get the first parts done within 6-8 months. While possible, I'd probably want to get feedback from #207 before we go whole-hog. There's a very decent chance this project is what people are looking for, so I certainly wouldn't write it off completely.

[docprofsky]

I talked to MakerBot about their new printers. They have something similar to a BeagleBone Black in there.

[RI0]

Do you think it makes more sense to look into the Beagle or the Pi?

BeagleBone Black http://beagleboard.org

Capes http://elinux.org/Beagleboard:BeagleBone_Capes

Raspberry Pi 2 http://www.raspberrypi.org/raspberry-pi-2-on-sale/

Mathematica http://www.wolfram.com/raspberry-pi/

Which one do you think would be easier to use as the base for a prototype? Both have interesting aspects with the capes or other software that might create other opportunities.

[techninja]

I'd suggest the cheapest option that works well. Even the very early Raspberry Pi has plenty of power to run CNCServer. Not to mention it has a great community and lots of support and tutorials for setting something like this up. The original beagleboard ran Angstrom instead of Debian so package management was always a little wonky, constantly cross-compiling on faster machines. Not to mention it's always been a more expensive board.

I'd say it shouldn't matter, though we may only supply one set of supported instructions, with linux, and source code you can almost always find a way.

[docprofsky]

Ideally it would be a Linux (and maybe Windows and Mac OS X) program that would connect to the WaterColorBot and send commands to it. Since this should not need to be using any GPIO or hardware specific features the program should be runnable on any Linux computer that has the necessary libraries for it. Besides the inability to specify advanced settings using the AirPrint interface everything that is not a vector will not be drawn.

[RI0]

If we use a Pi as a secondary controller, what do you think about this for a screen? https://www.kickstarter.com/projects/1372954669/e-paper-display-hat-for-the-raspberry-pi?ref=category