also, this looks intriguing: https://www.sparkfun.com/products/15297

Hi @cshclm and @heidi.h 

I must say, I was delighted to see that you both joined this thread as I was actually about to start using Camelot to manage the collection of camera trap data to support the building of a machine learning / neural net model for Asian elephants, both optical and thermal. I won't go in to too much detail as I'll post an official update in a few days time on Wildlabs, but I wanted to quickly share my reasoning for selecting Camelot as it may be interesting (this was before you both posted);

• I could customise the sighting fields / meta. This one feature is powerful as now I can add "distance to target animal" or whatever I needed, safe in the knowledge that I could build a solid database.
• If I needed to get under the code, I could.
• If I like it, I'd be interested in supporting it or contributing financially too to support your time if I needed a certain section changing or a bespoke tweak - why? It's more time efficient to ask you to make a technical change to achieve what's needed and write this in to the project grant than myself spending 10x the time and not concentrating on the larger picture and delivery of the project itself.
• Because it was open source and because I could include it in a larger library of other open solutions (hardware & software) safe in the knowledge that it would exist regardless of grant based sustainability.

Expanding upon your thoughts and comments above, it made me think how my reasons to use Camelot may be different to a traditional camera trap user, or someone only needed the built in functionality. Could it be that the default, already very good, already well thought out ability to control and customise the software delivers out of the box? It may be a reason as to why you haven't seen a desire to fork or fix anything that needs urgent attention - then again, my desire to use Camelot is different, as I had a private intention specific to my project - and that may be a good path for you to follow if you can attract others willing to contribute for their special projects, that ultimately pays a little salary and feeds back features to the core. A kind of "freemium" model as described by @Robert+Hutchinson but with a price tag for your custom support and time to help projects that need / write in funding to advance the tool for their own needs, but share it on openly by default could be something to explore.

Great thread!

Though I don’t develop open source conservation tech myself (to date!), I’m quite interested in how this space evolves, for software but perhaps even more for the hardware side, given the intrinsic challenges of working with a physical product. My interest extends to the issue of viability: what does it take to make these great initiatives float, and how/who should fund them. As a quick intro, I’m founder (and current president) of the SCB Conservation Technology Working Group, which is keen to promote open source tech development, as Alasdair mentioned.

I enjoyed reading this thread. It was great to see Alasdair’s perspective (which I knew from past discussions) as well as others’. And I found out about Camelot (and your struggles to keep it alive), which I didn’t know before, but I’ll definitely check :-)

Alasdair’s Arribada Initiative is a great experiment, and a very necessary one. This is mostly uncharted territory for open conservation hardware. Last year, I organised a workshop with Andy Hill and Peter Prince (of AudioMoth fame) on roadmapping an open-source acoustic platform. We had a discussion with ~40 participants with interest and experience in wildlife acoustic monitoring and asked them what they’d like to see in an open acoustic platform (e.g. could be an extension of AudioMoth). We also discussed about the concept of open source technology (here, mostly hardware and associated control software) and realised that many of them hadn’t thought about the implications of open source, including the (by default) lack of product warranty and support. If, as an experiment, the Arribada Initiative works, how can we (as a discipline) support more of its services? We have an opinion piece (currently in review) suggesting the value of an intergovernmental entity (or entities), given the benefits would transcend individual projects/organisations (yeah, I know, good luck setting that up!). Interesting discussion, and one we should have collectively.

Two other (related) exciting discussion points:

• I find commercial open source conservation technology to be a very exciting space, plenty of challenges but also opportunities. The example of the company Arduino comes to mind – plenty of cheaper (legal) “copy” products but these guys are still operating. Of course, the context is very different to a hypothetical open-source conservation tech device (think AudioMoth) but would be interesting to look deeper into a few examples within the hardware world.
• Can commercial companies co-exist with cheaper open-source products? Is there a niche for higher-end more expensive company-supported devices when one can buy way cheaper ones? I think there is scope for some degree of niche differentiation that keeps commercial companies alive in this brave new world. What do you think?

Hi jlahoz.

In reply to your questions:

"I find commercial open source conservation technology to be a very exciting space, plenty of challenges but also opportunities. The example of the company Arduino comes to mind – plenty of cheaper (legal) “copy” products but these guys are still operating. Of course, the context is very different to a hypothetical open-source conservation tech device (think AudioMoth) but would be interesting to look deeper into a few examples within the hardware world."

It sounds like there were a lot of people asking questions about financial sustainability of open source hardware for last night's virtual meetup. I've been involved in open source hardware commercially for over 12 years now. I helped LadyAda set up her first assembly line for Adafruit, was a board member of the Open Source Hardware Association, and watched the open source hardware community as it went through it's evolution to what it is today.  

Commercial open source hardware is definitely viable and doesn't necessarily need to be artificially sustained by grant funding. That said, you do need to understand basic principles about business and manufacturing if you are going to survive as a manufacturer. 

I think the most basic mistake I often see beginning manufacturers make is moving straight to design and production without marketing. Marketing is the most important part of maintaining a financially sustainable business, no matter open source or not. What usually happens is people often overestimate the demand for their widget and get a large amount made and assembled. They then discover a critical mistake or feature that they overlooked because they didn't work closely enough with potential customers. For the AudioMoth, this seems like it was mitigated by working closely with the acoustic survey community and also verifying demand ahead of time using the Group Gets platform. 

Beyond marketing, it's not enough to design working hardware. The first working version is just the start of an iterative process to either bring the manufacturing cost down or improve the feature set of the device. As the cost comes down, the margins improve and those cost savings can either be passed on to the customer to be more competitive (if there's a lot of price competition), reinvested into the company to improve capabilities (ie: buy an automated pick and place machine or hire employees), or kept as profit.

For FreakLabs and Hackerfarm, we have our own automated assembly line which allows us to manufacture specialty or low-volume production runs, usually up to around 100 boards. Beyond that, we normally send it out to an assembly house in China. We focus on production of custom designs for specific consulting projects but also run a small webshop with some of our mainstay products. 

When we design, we design for both functionality and production. When possible, we normally select parts that are commonly found on motherboards, mobile consumer electronics, or otherwise are commonly found in the wholesale markets in China where many of the other low cost manufacturers source parts for their products. The reason why is that if a part ends up on a motherboard or cellular phone other than the main processor, it's basically a commodity product and the price has already been driven into the ground.

For example, the MCP73831 lithium-ion charging IC from Microchip is about $0.43 in quantities of 100 from Digikey. The equivalent TP4057 lithium-ion charging IC commonly found in consumer tablets and mobile USB chargers is about $0.03. It's also a part commonly found on projects by Adafruit and Sparkfun. All of us have purchasing and shipping agents in China to source and ship parts to us from these wholesale markets. 

The average markup for a design at Arduino, Adafruit, or Sparkfun is usually 4-6x the BOM (Bill of Materials) cost. For example, the BOM cost for an Arduino Uno is around $4.5 and the price at the Arduino webshop is $22 for a markup of ~5x. I would say the minimum markup for a manufacturer would be 3x the BOM cost, not including assembly cost since we all have our own assembly lines. You're pretty close to break even at this point if you factor in shipping, packaging, handling, testing, development expenses, and time. I normally wouldn't do a project below this markup since there are often more productive uses of time. 

I also used to teach manufacturing to industrial designers at MIT Media Lab and my friend bunnie Huang and I would do an annual six week tour in Shenzhen, China where we took students from MIT Media Lab to various factories, had them design and manufacture a product "almost" from scratch, and let them understand the realities of production and how it differs from design. 

If you're interested to hear more about manufacturing and sustainable business models for open source hardware manufacturers in conservation tech, let me know. It's actually very do-able. 

"Can commercial companies co-exist with cheaper open-source products? Is there a niche for higher-end more expensive company-supported devices when one can buy way cheaper ones? I think there is scope for some degree of niche differentiation that keeps commercial companies alive in this brave new world. What do you think?"

Oh of course. Truthfully I don't think it is too difficult to compete with cheaper open source products, especially from low cost "pancake" factories in China. They have the name "pancake" since they crank out designs like pancakes. The most powerful tool a manufacturer has is the ability to write. If you're manufacturing an open source tool and you're a native English speaker, I think theoretically you shouldn't have any problem competing with a low cost Chinese knockoff company. People don't just buy a product, they buy the story behind the product.  If you can write in native English, you have a tremendous advantage over a company that does not have that ability. If someone buys the cheaper product with no documentation, no story, and no recourse if there's a problem, you don't really want them as a customer.

This is where marketing becomes very important. Every company has a "right customer", which is someone who feels like the products are tailor made for them and understands the mission of the company, the purpose, story, and is willing to support the company and products. This is especially true for conservation tech which has a very strong purpose and story. Focusing on these customers and building relationships with them when you find them is one of the most important things you can do. Trying to win sales from people who only want the cheapest price is a losing game. It's much better to focus on blog posts, customer support, documentation, learning materials, case studies, and help them understand how the product makes their life better in some way. There's little chance any knockoff company could compete with that. 

There are a lot more strategies along these lines, but if you're an indie manufacturer without economies of scale, you want to avoid focusing on price as much as possible. Price is something you compete on when you don't have anything else going for your products. If you have a well thought out marketing, pricing, and differentiation strategy, then things should work out quite well.

Anyways these are some thoughts on manufacturing in general and open source hardware in particular. Having open source designs and source code is an advantage rather than a disadvantage but the rest of the business model also needs to be aligned with this. Open source hardware businesses are based on community and this is where the focus should be. This also includes customer support. With this in mind, I think there are plenty of opportunities in conservation technology for sustainable open source businesses because of the passionate community around it...and even more so if you think of parallels to other industries.

For us (FreakLabs and HackerFarm), we also work in developmental infrastructure monitoring with World Bank and open source agriculture technology. There are uses for a lot of conservation tech in those areas (ie: dataloggers, wireless sensor networks, general purpose timers, timelapse/camera traps, etc). This also helps us in designing conservation technology. We know there are crossover markets that could potentially use these products or slight variations of them. Also wildlife conservation fits in thematically with many of our efforts to work with technology in a specific context and purpose. This is why we're really excited to be part of this community. We're looking to contribute in a way that can benefit the community but we have to make sure it will also benefit us. In that way, our contributions and participation can have longevity and be sustainable. 

Hope that answers your questions :)

Akiba 

Can I get notifications for a group? I want to get an email each time a new topic is added to 'Drones' without having to keep coming back.

I think there might be room for improvement in the forum layout, and information shown.

Having only 5 threads per page restricts the number of active discussions that can be held simultaneously before one of them loses visibility by being pushed to the next page.  Increasing this number, or adding an 'infinite scroll' feature found in other forum software like Discourse might help to facilitate more discussion.

Additionally, knowing which user was the last to respond to a thread would also be quite useful.  This would allow users to quickly identify when admins, core contributers, or the original author have added to the discussion.

and love your work MichalSmielak! Looks like a very nice design indeed. 

Hi Akiba,

Sure thing. An open source camera trap reference design or SoC that meets commerical specifications is, in my eyes, one of the key missing elements in the world of camera traps due to the complexity of achieving comparable performance as that of a Bushnell / Reconyx. Nobody has cracked it yet, and if you're game, that would offer real value to the camera trapping community. I'd be keen to support a move in this direction.

I  supported an experimental programme of work a few years back that multiplexed the SD card, meaning anyone with an existing generic camera trap would use the modified SD and the camera would happily keep the bus, writing data / photos, but the bus would be switched on init so the previous data could be read by a third party radio or device, meaning cheap trail cameras could be modified and used and extended. A flat ribbon cable escaped the enclosure in this instance. I was also going to try and run busybox (think WiFi-SD cards) for wireless transfer but the prob was power as the SD card only received power during writes and the objective was 0 hacks - just a modified SD in a standard camera. Could still go down the firmware route, but it gets heavy supporting various different makes. A reference open design and injection moulded case would be the real answer.

Cheers,

Al

Hi Alasdair.

I think an open source camera trap design is very possible. We've looked into the Sunplus chipsets but it seems very difficult to get a reference design and reference software. The SPCA1x28 series is a low end chipset that is very inexpensive, using an 8-bit 8032 processor and handling all the images in hardware. The low cost is likely why so many trail cam manufacturers use them, but the processor is based on an Intel 8051 instruction set circa 1981 and looks closely guarded by Sunplus. What seems to be happening is that companies are selling vanilla circuit boards with standard features and the trailcam manufacturers are using the standard features available in their trailcams with no modification of firmware. On the (Sun)plus side, having an 8-bit controller with 5MP cams means it's possible to idle at very low power and then turn on and trigger the cams quickly. 

We've looked at using an Allwinner chipset which is used in a lot of action cams and dashcams and modifying it into a trailcam. It's possible to run Linux and they support SD card interfaces and various cameras. It's also possible to buy just the chip so it's not tied to a platform like Raspberry Pi. This is useful because it's possible to make minimalist boards with just what's needed and also optimize it for power. An issue is that since it will be running a pretty heavy processor, it will be difficult to power optimize. Rough estimates are that at idle but full clock speed, the chip will consume around 90 mA. The Raspberry Pi Zero idles at around 80 mA for reference. Ideally, it'd be nice to get it around 1 mA.

We've also checked out using an ST32 ARM Cortex M4 chip with a parallel camera interface. These are pretty beefy processors but not Linux class like the Allwinner which is an ARM Cortex A7 class chip. Since the ST32F407 chip can run closer to bare metal (ie: no OS layer in the way), its possible to put it in very low power modes and then have it wake up. One issue though is that it doesn't have an SDRAM interface so it will cost a lot to have enough SRAM to buffer more than one image. 

Another possibility we were looking at was to have an FPGA running with custom logic and have it controlled by something like an Arduino or an ARM Cortex M3. There is already ArduinoCAM devices but the FPGA code is not open source. This is also a potentially interesting possibility because it would offer a low power device which could be in sleep mode except for the PIR sensor and quickly ramp up to take pictures. 

Whether we go with the Allwinner, Sunplus, ST, FPGA, or some other chip, it will probably be a big undertaking since hardware will need to be developed for the chip and system. The software will probably take the most time since custom drivers will likely need to be written as well as application software to handle the main functionality. I'm currently assuming that it will be a year-long project. But if it takes a year to come up with a design that can be useful in so many applications, it may be a small price to pay. 

Let me know if you're interested to discuss it more. I will probably move this part of the thread to a separate thread since I think it's diverged from the OP topic. 

Akiba 

FYI, the open source camera trap part of this thread has moved here:

https://www.wildlabs.net/community/thread/694

That also sounds like a good idea :)

Hi Tessa. 

Thanks and also thanks for being so generous with your work :)

Regarding the format, how do you all think if we have a single document and a wiki? I could handle the single document if David wanted to do the wiki. One potential issue would be synchronization, but since many wikis keep a change list, perhaps we can schedule periodic document updates based on the wiki changelists. We can also maintain a document changelist in case the changes need to go in the other direction.

Any comments or suggestions?

Akiba