|
|
Post by faljse on Aug 3, 2016 9:44:37 GMT -7
Hi!
First i'd like to thank you for creating and releasing the open-dobot firmware;
Dobot would be completely unusable without it.
I got a few questions regarding your firmware/hardware modifications:
The system will be remotely controlled by students, so i need a way to re-calibrate the dobot without
any user interaction (to account for missed steps/stalls).
- Is this possible by switching to ramps, mpu6050 and an interrupter?
I am currently porting the client applications to java;
Basic movement is working and i'm going to implement MoveWithSpeed() and its dependencies next.
Do you think it would be a good idea to move this code into the firmware?
(Would reduce code duplication and communication overhead)
Kind regards,
faljse
|
|
|
|
Post by Max on Aug 3, 2016 13:45:34 GMT -7
Yes, it possible to re-calibrate dobot when on ramps. However, as it is accelerometer data that is read from mpu6050 units, when the angles are read the robot must have rested for some time (I think 500ms would be enough, you can find the minimum experimentally) for the reading to be accurate. The simplest setup would be two mpu6050 on the arms and an interrupter at the base. Mpu6050 would give you XZ plane and interrupter - Y axis.
They had the whole team working on the proprietary firmware in an attempt to have it all in firmware on Arduino, and yet they have released a completely unusable version first. They had to sacrifice the command rate later and put everyone through the "upgrade" process (250k to 9.6k version). That tells at least one thing - Arduino is not fit for the task and what they have now is too fragile and hard to change brcause of realtime constraints and pretty slow microcontroller.
So, I don't think it is a good idea to move that stuff to the firmware unless you switch to something way faster (e.g. BeagleBone Black).
There is no overhead in comms - it's just comms. There is also no bottleneck in comms, it can perfectly cope with the rate that FPGA sets (50 commands/s).
Besides, having the implementation in a high-level and garbage-collected language and the way open-dobot is designed is way more flexible as you don't deal with the complexities of realtime constraints and memory leaks (well, to certain level).
I don't see why you need to reimplement everything in Java. Wouldn't it be simpler to just create a Websocket interface to the SDK implemented in Python? That was the plan, but I simply don't have time to actually implement that.
|
|
|
|
Post by faljse on Aug 5, 2016 23:57:34 GMT -7
Now that i did go through most of the source code i have to agree, that it might not be easy porting it to the arduino  I also don't like duplicating the client code, but it reduces complexity for this project (and i don't know python). MoveWithSpeed() already works, next step is to get an interrupter and work on calibration. I haven't decided yet if i need to switch to ramps; front/rear calibration on reset seems to work fine for me. Are there other advantages of ramps? |
|
|
|
Post by Max on Aug 6, 2016 0:24:52 GMT -7
Without changes to firmware the advantage of ramps is that you can read accelerometers at any time after initialization.
With fpga board accelerometers (both in fpga board version 1.0 and 1.1) sit on SPI bus. After initialization Arduino becomes SPI slave and it doesn't seem to be possible to make it master again without reset. To read accelerometers Arduino must be master as accelerometers are slaves.
It should still be possible to read accelerometers that sit on I2C bus (e.g. mpu6050), but it is not implemented in fpga firmware version.
|
|
|
|
Post by faljse on Aug 6, 2016 0:45:43 GMT -7
Btw the angle sensors on my dobot look like SCA100T: (http://www.mouser.com/pdfdocs/sca100t_inclinometer_datasheet_8261800b2_0.PDF)
Supporting those sensors would enable a ramps version without requiring to mount mpu6050.
Are there other use cases you could think of?
|
|
|
|
Post by Max on Aug 16, 2016 13:29:12 GMT -7
I have thrm too, but I use mpu6050 myself with ramps. This makes it easier to support ramps firmware (only one type of accelerometers).
I have no plans to support sca100t in ramps version. They are supported in fpga version of firmware though, but because of the arduino limitation it's not possible to read accelerometers after initialization (arduino cannot switch back to spi master)
|
|
