Bounty for complete EV3 C/C++ API

[HaWe]

+1
700 EUR reached (= 945 US-$)
now first we'll need a programmer who is willing and able to do the coding and who initiates the crowdfunding project -
and then of course some more prospective customers...

[mightor]

The risks for the developer are very large:

• Without some kind of escrow system in place, there is no guarantee for the money in the end. What if 80% of the requirements are covered, does that still mean nothing is transferred to the developer?
• The specifications are not SMART, this will inevitably lead to conflict, unless some kind of arbitration process is in place.
• 6 months of support with a money back guarantee is insane, especially considering the massive list of requirements. 30 days is standard in the software development business.
• What constitutes a bug and what's a design feature?
• Who fiats the final design?
• What constitutes adequate documentation? Does that include example code?
• How will testing be done by the developer for all these different Windows platforms? Who will provide the licenses needed to do this testing?
• Which WiFi dongles and other devices should be supported and how will this be tested by the developer?
• What is the time frame? Two weeks? 6 months?

There's probably more, but that's all I can think of off the top of my head. I hate to be a party pooper, but if you want a professional developer (ie someone who's getting paid to do this) to take the bait, you have to approach it like a software development project.

= Xander

[HaWe]

good that you yourself threw this into the ring -
I actually think you ARE a party pooper.

Let people decide if theY'll do something - and maybe what - if the start up capital ist collected , and then see if or when or what and to which conditions.
My wish list is finally not the Holy Bible, I only granted a bounty for my requirements, pipijndevos did it for his.
The programmer who once starts his personal crowd funding project is the one who holds the reins.

[mightor]

My years of project experience with fuzzy requirements, unclear deadlines and possibly conflicting interests have taught me many a wise lesson.

I am just trying to make sure that whoever decided to make a go of this, knows what they're getting themselves into. Things have a tendency to go funny when money is involved, regardless of amounts.

= Xander

[HaWe]

yes, sure, I do respect your practical knowledge and experience.
As a customer I only can formulate wishes and aim for a purchase price.
Different customers can formulate different wishes and aim for a different purchase price.

But as I wrote, it's not up to us to start the project. There must be a programmer who says "I offer the following features and do it for the following price and conditions -
Who wants to join? "

The money should be managed on a kind of escrow account so that the programmer can be sure that he gets paid for his work 100%, and the buyer can be sure that he will recover his money in case of non-delivery or significant deficiencies.

That's IMO exactly the (only) way it could or would work.

[holler]

If single shot mode is a mode that can be set like other sensor modes, then setSensorMode(port, mode) should work, if you know the mode number... otherwise I'm not sure.

Sending single I2C commands on the EV3 is broken. The (ev3-linux-i2c-)driver has a bug there which repeats I2C commands even if it should not. So theoretical it works, practical you need to fix the driver before.

Regards,

Alexander Holler

[holler]

In regard to the topic of this thread, I only can support Xander.

It's an unrealistic thread and should die. Nobody sane would consider to go for that bounty:

1. It's highly unlikely to be able to collect the mentioned money
2. The amount of money doesn't make sense compared with the amount of necessary time.
3. Just writing an API doesn't work as you have to change the existing firmware a lot.
4. The one who would do the firmware changes and write the API would end up with beeing responsible for the changed firmware too, regardless if he would like it or not. That means he would receive questions after questions, from firmware specific questions up/down to questions for generic help of all kind. E.g. how to install the firmware, how to use Linux or even how to write C or C++. That means the poor developer would end up as a first level supporter too.

So just go the usual way. Write and post tutorials and/or changes to the firmware or existing APIs and maybe ask for donations for already done work, if you want. Asing questions is ok too, but don't ask others to do work you aren't able to pay for, especially with such highly silly requirements as can be found in this thread. Nobody has an interest in realizing your ideas or building your robot just for your satisfaction and without any adequate reward. Don't forget, everybody needs food and a place to live and bakers usually don't give away bread for free.

Alexander Holler

[HaWe]

3. Just writing an API doesn't work as you have to change the existing firmware a lot.

that's a surprising standpoint - no one ever mentioned or suspected that there would be any need to do this.
we (at least me) assumed its just wraps around any low level C functions like reading or shifting registers to have something like NXC or motor or button control functions which already exist e.g. in John Hansens BCC/C API - and finally one could develop on top of what already exists.

But it's not just my ideas or my wishes, others have the same requirements - it must be easy enough for pupils and home programmers, just like NQC or NXC was.
Anything which requires programming skills like professional Linux programmers or computer scientists have is illusory and unsuitable.

If it turned out to be so complicated as you wrote then of course we'll have to abandon our hopes to get native C for the EV3 with a convenient API and IDE like NXC for the VM once was before. Sadly a big step backwards for the "C" or "C-like" hobby programmers compared to the NXT.

[holler]

3. Just writing an API doesn't work as you have to change the existing firmware a lot.

that's a surprising standpoint - no one ever mentioned or suspected that there would be any need to do this.

It isn't if you still want to be compatible with lms (that means if you still want to use EV3-G too, without changing the firmware). If so, you not only have to fix existing bugs in the ev3-linux-drivers, but you also have to fix and enhance lms2012.

But it's not just my ideas or my wishes, others have the same requirements - it must be easy enough for pupils and home programmers, just like NQC or NXC was.
Anything which requires programming skills like professional Linux programmers or computer scientists have is illusory and unsuitable.

That is what EV3-G is meant for and I believe LEGO did a good job with it (even if they could have done it much better, at least in regard to downwards compatibility or in regard to using native Linux programs). If you want to use professional tools, you have to learn to use them. But if you don't want to learn C/C++ (or Python, Perl or whatever, if someone will ever write an EV3-API for those languages) and how to use Linux, just go with EV3-G.

Alexander Holler

[HaWe]

But if you don't want to learn C/C++ (...) and how to use Linux, just go with EV3-G.

Did you miss something? This thread is not about EV3-G, it's about a complete API for something simple, text-based, C-like, just like NXC.

it must be easy enough for pupils and home programmers, just like NQC or NXC was.
Anything which requires programming skills like professional Linux programmers or computer scientists have is illusory and unsuitable.

So I don't see your point, or are you just trolling again?