Author
Topic: SOR community project? (Read 26400 times)

Projects designed to make money will be less sucessful than open-source projects. Just look at Arduino for an example.

These projects should not be designed to make money - just to contribute to the robotics community. Selling stuff is still okay, but everything should be open source. If the project is sucessful enough, people who appreciate it can donate.

GNU GPL might be a good idea... so no one could do that. I don't plan on making money off of this. I think of it sort of as the linux of robots. I'll sell stuff at cost if there's demand, but mostly things will be free in my book. (Schematics, code, everything you would need to build your own should be free. I'm not going to sell pre-made stuff).

earlier today i was talking to some people in the chat.we were talking about how some of the modules don't really need I2C and how this is just complicating things.i can understand how I2C can be useful for some of the most advanced things like gyro modules etcbut is it really that useful for a simple motor driver circuit? i mean... it is a lot easier to program a motor controller to go forward but it will most likely be a bitch to program into I2C let alone get it working...

i mean, i would rather plug my motor controller into some pins and just turn the pin high than have to set upa whole i2c program on another microcontroller unit. not to mention the cost that it is putting down on the modules. i know that the i2c doesn't add that much cost but still... an extra $2-$4 would make a bug difference for the consumer.

i2c is fine for modules that do more than one thing like hazzers scanning servo module but for a simple little moduleis it really worth going through all that effort?do you guys think we would be able to make some of the modules without I2C or am i going nuts?

Personally I agree with you. However: I believe one of the goals of the project is to make it so that all modules can be connected and controlled in the same way. So a bit like having a USB hub and you keep adding things to it by just plugging them in - no need to know which pins are the UART or +5v vs Motor supply etc. So easier for the newbie but the downside is that it makes the cost of each module more expensive.

Smash, a motor controller is a smart device. It takes care of the PWM, encoder counting, acceleration, slowing down and so on while the main microcontroller is free to work on the more important things.

Of course, for a very simple robot this is a bit overkill, but people can use the motor drivers directly on a protoboard, just like the $50 robot tutorial. I did it a couple of times and it works.

But time comes for any roboticist that he/she would want to build a more complex robot, capable of mapping, smooth movement, inverse kinematics and so on. I2C modules specifically take care of bits of the most complex parts of the code, better than multithreading. The only disadvantages are added cost and a bit more complex code. Cost we can't eliminate, but we can make the programming a lot easier with libraries of functions.

Smash, a motor controller is a smart device. It takes care of the PWM, encoder counting, acceleration, slowing down and so on while the main microcontroller is free to work on the more important things.

This is where the problems are happening. The motor controller smash was looking at making was just going to be an L298 on a board. To make it I2C compliant he was going to add an mcu to it. whereas he might aswell just connect it straight to the master without I2C.

What you are describing is to make a motion controller board that is closed loop. i.e. incorporating encoders so it creates a full system which is capable of running its own movement algorithms by command.

This platform will be really flexible. We won't restrict someone to using just our modules for their robot's functionality, if they only want to use 1 of them. If they don't want to use a fancy I2C DC motor controller with nice control algorithms etc, then they don't need to, they can make their own little motor driver circuit and control it directly from the MCU.

I2C takes only 2 pins from the MCU. There will be plenty of pins left over for other things.

Before hearing about the community project, I had the idea of building my robot around I2C for on simple reason:extensibility. A clean an simple interface (I2C) between components allows you to modify your robot without having to redesign the complete thing each and every time. You can add sensors, change the MCU, ... without interfering with the rest of the design (think about pin assignment, timer counters, interrupts, ....). With I2C you add very little constraint:a I2C bus, a minimal API to access the bus, the "standard" connector. That should be it. The MCU, chassis, power, ... is up to you.If you want to use a peripheral directly (direct pin access), do it ! But it shouldn't be part of the OSCAR system IMO. Or else we will end up with a bunch of semi compatible boards and beginners will be lost. Of course I2C won't solve this problemcompletely but it provides a good way to isolate subsystems.

Smash, about your example of a simple motor driver: a semi-complex robot will probably require more than just a driver. i.e. a completemotor controller (with feedback loop and PID). In this case, dedicating a microcontroller to this task is a very good idea IMO.

Bottom line: OSCAR must impose I2C communication between boards. But for simple sensors or drivers, we shouldn't impose anything.

i see your point chelmi, i agree that it would be easier to code a change of hardware on the user end with I2C buti was just saying that it is going to be hard to set up the I2C software.i will put I2C availability onto my board, but also the option to control it by hooking it up to pins on the microcontroller.

i was just saying that it is going to be hard to set up the I2C software.

Why? there is already tons of code available for most microcontroller to setup and control I2C. And this is a one time cost: once you have this base layer you never have to touch it again (unless you use a different MCU). After that, it's just read/write to a specific register at a specific address.

In my opinion it's way simpler that having to configure pins, jungle with timers, interrupts,... for each peripheral...