Cameras
-
It seems that the Duet Wifi is a "Octoprint killer", aside from the camera - Duet Wifi can only handle IP cameras at the moment that can provide static jpegs from an HTTP request. What about UART/SPI cameras, connected directly to the ESP8266? That way the main CPU stays free to do motion control, and the (otherwise largely idle during prints) ESP chip can handle the camera? I think a 1hz update rate would be OK, though 30hz would be livin' the dream.
Is the ESP8266's SPI available on a header somewhere? If not, could we add that to the pre-order boards?
Links:
http://www.ladyada.net/wiki/tutorials/products/camera/index.html
http://johan.kanflo.com/building-a-low-cost-wifi-camera/ -
I would be wary of interfering with the ESP8266's SPI link with the SAM - its designed to be as high speed as possible and adding headers into the mix could impact on the speed available.
Another (better?) option could be to modify the DuetWebInterface to deal better with IP cameras that output a video stream and embed this stream in the browser window in a better way.
Tony
-
The SPI pins on the ESP8266 are already dedicated to communication with the main processor on the Duet WiFi, and in any case SPI signals don't travel very far at all. However, the UART pins on the ESP8266 are currently used only during programming. So in principle it would be possible to connect the Adafruit camera to the ESP8266, if you didn't mind having to disconnect it whenever you want to upgrade the WiFi firmware or the DuetWebControl files.
There are already pads for a 3-pin header to break out the TX, RX and ground pins. To make it easy to connect the camera, ideally we would add a 4th pin to provide +5V to power it.
I am wondering what the maximum frame rate of the camera would be, given that the jpeg image has to be transmitted over a serial link at a maximum of 115200 baud.
-
Aren't there two SPIs on the ESP8266? What GPIOs are currently used (and for what) in the present implementation?
EDIT: looks like one of the SPIs is used for the flash chip. Does the firmware fit into ESP8266 RAM, or is the flash actively used during operation?
Perhaps use I2C instead?
-
I kinda like the fact that there is no setup for a camera (besides the stills), and heres why.
I would like to be able to monitor the print from outside of my home, but I don't necessarily want to open the duet (and full control) to the outside world. With a Pi I can set up a wireless camera system using motion, and if I really want control over the printer (say to stop a print if it goes awry) I could rig up the Pi to have an estop command to run an Estop routine (stop print, home machine, cycle/cut power since you can set up macros when a pin goes high or low on the duet?), and then setup the Pi so I can access a web page from anywhere to view/stop the print. It would take the load off the duet (for the camera) and help protect the control of the machine from unauthorized use, since its still constrained to your local network.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
-
For my desires a dedicated Pi would work really great, but I can see why you would want it all in one. I was just adding another viewpoint into the convo in case you/someone else hadn't of thought of it like I have.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
ITs not the cost, its the adding a header into the SPI circuit which may degrade the speed achievable even if nothing is plugged in. The UART would not be an issue from that perspective, however it would be rather slow.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
ITs not the cost, its the adding a header into the SPI circuit which may degrade the speed achievable even if nothing is plugged in. The UART would not be an issue from that perspective, however it would be rather slow.
Yes, I know about the length/speed relationship on SPI - I've done board/firmware design with SPI in the past. That's why I asked about the second SPI block on the ESP chip, and whether it was available. If it is not, then I'd suggest i2c.
-
The second SPI block on the ESP8266 is used to read the code from the flash memory chip. So it's not free, and although I understand that it can be shared, adding 1m or so of cable to it would not be a good idea (and adding a camera to my delta would need more than 1m of cable to the electronics).
I2C is also intended for very short distances. It relies on pullup resistors, so adding more than a small amount of capacitance on the bus degrades its maximum speed.
So UART is the most practical option. The highest resolution supported by the Adafruit camera is 640x480. So I took one of my photos of my delta printer looking down on the effector and resampled it to 640x480. The file size was then 100Kbytes. If we can use 115200 baud (the maximum supported by the Adafruit camera) without dropping characters - which isn't necessarily the case - then it will take about 10 seconds to upload an image, if the camera uses about the same Jpeg quality/compression compromise.
A 640x480 image is actually rather large to fit in the existing slot in DWC, so an miage with lower resolution might be acceptable.
-
While i get the intent to make a self contained solution, I think video might be a step too far. If the ESP can server SPI video well if there is a spare SPI port then how about using a second ESP for the video?
-
While i get the intent to make a self contained solution, I think video might be a step too far. If the ESP can server SPI video well if there is a spare SPI port then how about using a second ESP for the video?
Which brings us back to this solution http://johan.kanflo.com/building-a-low-cost-wifi-camera/ that Tim linked to in his original post.
-
yes, that would work - but effectively we are making an IP cam. I suppose we can add a bit if we allow trigger via UART so we could get good timelapse recording.
-
I don't think a second ESP is a good solution, that's buying more hardware when you have a perfectly good ESP sitting there doing very little during a print.
It seems as though with resistor pull ups, you can have 200pF of cable capacitance on I2C. That'd be around 15 feet with this cable, for instance:
https://www.wireandcabletogo.com/uploads/file/bel9841.pdf
I've done both SPI and I2C over the types of distances we're talking here (a meter or so). While I agree the high speed SPI would likely be affected, a slower bus should be fine. I think interfering with the UART isn't a good idea, since that makes it harder to do ESP firmware updates.
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
-
Hmm, I hope I don't come across as rude, but why would a 3D printer need a built-in camera? Seems like too many systems tacked onto the wrong hardware. I've found that any PC with a webcam works well, and is more versatile. I only see drawbacks to trying to add a webcam to the 3d printer controller.
-
Lots of reasons - time-lapse, remote monitoring, etc. It is a really popular feature, otherwise Octoprint wouldn't have it.
Why tie up a PC, and spend the energy running the PC, when there's hardware on the controller that is sitting nearly idle?
What is the drawback to adding a webcam to a 3D print controller, exactly? Its maybe 5 cents to add a header to the board, free to do the routing, and even if Tony/David don't want to spent time writing code for now, at least it can be added later.
-
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
Which ones would you want on a header?
-
I understand the use of a camera, but it is nearly entirely separate from the other functions of the control board. The web interface is not publicly exposed, so it doesn't really make sense.
I'm all for adding features to a controller board, but I fear that some people are losing sight of the important aspects: reliability, accuracy, fundamental features of a motion control system. A webcam serves no purpose whatsoever. Why does a webcam need to be tied into the system that controls stepper motors? It doesn't, and shouldn't be.
-
I have some sympathy with bot's view. A streaming remote view of the printer might have some value, and I can already get that from the £20 wireless IP camera that I purchased recently. But I don't think a static image refreshed every few seconds adds much to the web interface.
We're getting very close to the point at which we need to freeze the hardware design. Any changes we make at this point should be for the sole purpose of addressing issues that arise during the beta test phase. That said, I am not against adding a 5V pin to the ESP comms header, or adding the 3 spare ESP GPIO pins to that header if there is room for them.
-
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
Which ones would you want on a header?
Any that are unused, for future proofing - at least enough for i2c. All the SAM's pins are used/brought out to either do things or sit on an expansion header, so why not do the same on the ESP?
@bot:
I understand the use of a camera, but it is nearly entirely separate from the other functions of the control board. The web interface is not publicly exposed, so it doesn't really make sense.
The web interface can be publicly exposed if you forward the port on your router, but even if you don't do that, being able to watch the print from within the LAN is useful. Personally my printers are in a closet (in the same room as me), with a closed door for noise reasons. Having a video stream lets me watch for print failures easily while sitting at my desk. I can even bring it up on a laptop if I walk to another room to work.
@bot:
I'm all for adding features to a controller board, but I fear that some people are losing sight of the important aspects: reliability, accuracy, fundamental features of a motion control system.
No one is losing sight of anything, all I'm suggesting is that the pins are brought out to a header so at least it can be developed later if people need it. Things are very close to a hardware design lock, at that point there's no more "oh I wish for xyz". At least by bringing the pins to a header it can be developed in software at a later time. It would take about 5 minutes in KiCAD, that isn't a significant diversion in resources.
@bot:
A webcam serves no purpose whatsoever. Why does a webcam need to be tied into the system that controls stepper motors? It doesn't, and shouldn't be.
I have outlined my personal use for a webcam above, but if nothing else having webcam functionality will be an attractive feature on the Duet Wifi to help it stand out further amongst its competitors. In my opinion there is no reason not to do it, the hardware is sitting there nearly idle otherwise. It doesn't take away from the stepper motor control, since that's all handled on the SAM.
