Member Since: January 12, 2009

Country: United States




Spoken Languages

French, English

Programming Languages

C/C++, Java, Delphi, ASM, Python, Bash,…


POBOT - Sophia Antipolis Robotics Club (http://www.pobot.org)


embedded software, electronics, sensor networks, IA


robotics, electronics, music

  • I think that the 100 ohm is not enough to limit the LED current to the nominal 20mA specified in the component datasheet when powering the sensor with 5V.

    This value is correct for a 3V3 supply, and has been obviously selected for this configuration of use, but it is definitely too low for 5V. The resulting current is (5 - 1.2) / 100 = 38mA. Even if under the absolute maximum (50mA) it is prejudicial to the LED lifetime.

    Conclusion : either mention that the board is designed for a 3V3 usage (hence not for an Arduino) or change the resistor. Apart if your goal is to have customers buy more units after having fried their first batch ;)

  • Here it is.

    The new electronics is operational, with its 6 dSPIN sitting in the base. It will be extended in a near future with a control panel (LCD + buttons + LEDs) installed on the empty façade, to be able to select the operating mode, demos,…

  • Hello,

    I could read quite scaring things about BEMF produced by motors during deceleration phases going up through the power lines and frying other components around. Some posts suggest adding a Schotky diode on each dSPIN power line to block them.

    The original poster was using a DC/DC for producing the supply voltage, and he had 3 of them fried because of reverse voltages above max specs.

    In a configuration where the motor supply is produced by a basic high current rectifier bridge filtered by a big capacitor (50V/10 000uF), do I need to pay attention to this ? I would be very annoyed seeing the 5 other dSPINs used in my configuration being killed one after the other ;-)

    Any advice ?

  • Not yet for the full configuration, but I made these ones during the preliminary experiments :

    A video of the fully equipped arm is planned as soon as I will have the electronics fit in the base, and also the power supply section be rebuilt.

    After having wired the boards using the HE10 sockets, I came to the conclusion that it was not a very brilliant idea. I should have used instead male headers as for breadboard based experiments, mated with female ones and a couple of standoffs, all this arranged on a stripped prototyping board in a bus like configuration. This would have eliminated all the ribbon cables and most of the centre patch board, and also have reduced the overall footprint. It’s a pity this idea didn’t pop up earlier while soldering all this spaghetti plate :)

  • Back again.

    I finally completed the hookup of the 6 dSPINs to the robotic arm. The first tests of daisy-chaining and synchronised moves are quite promising.

    Some posts with pictures on our Facebook page.

    It’s written in French, but the pictures are self-explanatory (and the demo IHM is in English)

  • I’m getting pretty good progress with daisy-chaining. Here is a short video showing synchronized control of two steppers.

    For the moment, I’ve not tried to synchronize the clocks, all boards running their own default internal one. This has to be assessed in depth but it seems at a first glance to be precise enough for my needs (see the 2 other similar videos to have an idea of the project).

    All this is under the control of a RasPi, using a Python lib I’ve created for interfacing with dSPINs, both in peer-to-peer and daisy-chain configurations. The overall project is to give a new life to this arm (it was used in the 80ies for teaching robotics in schools, using a TO7 micro-computer made by Thomson - more detail here) by having it controlled using “modern” technos such as HTTP/REST for instance.

    The RasPi is for sure overkill for such a task, but the dev comfort has no price… especially when you consider the RasPi’s one :) And it has enough power under the pedal for advanced extensions, such as for instance using a camera at gripper level for object picking control.

    For a presentation of the project in its current state, you can have a look here. This documents the current demo status, using the original electronic board and producing its control signals used with an Arduino. The ongoing works aims at replacing the electronic board and its external control logic (Arduino by now) by 6 dSPINs driven by a Raspberry.

  • Thanks for this detailed reply. Things are crystal clear now and you’ve confirmed my final understanding of this famous fig. 18 of the datasheet.

    Too bad I came home too late for completing the coding of the “commands multiplexing”. It will have to wait for next week-end :/

    WRT the oscillator configuration, I’ve noted that when using an external source, the OSC_OUT produces and inverted signal. Which kind of effect can result from this ?

    I understand now what you meant by “non-linearity”. You’re right, I’m not facing this kind of problem. A classical solution for the non linear path is to approximate them by a succession of small segments, thus simplifying the combined control laws. BTW I’m not sure that doing a circular path for instance with a single move command is possible, since it will require modifying the speed in real time while moving, and I didn’t find any mention of such a capability in the dSPIN documentation. Do you agree ?

    But even for segments, it will be needed to be careful with accelerations and decelerations computation, since they have to be synchronised (i.e. end and start at the exact same time for both motors) to ensure a perfectly linear path.

  • Thanks for replying so quickly ;)

    Synchronize the clocks

    You mean “by using OSCIN and OSCOUT pins” ?

    clocking one byte of data in per board, then de-asserting CS to latch those bytes

    How can this be done since the L6470 requires CS to be toggled for each byte of data ?

    [EDIT] found the reply. I finally understood the meaning of fig. 18 of the datasheet. It worth trying. There is some preparation to be done to fill command trains with nops when all the motors are not supposed to receive the same command (e.g. make only 3 of 6 move), but it seems feasible. I understand now why STM engineers have chosen what appears first as an unconventional way of using CS (i.e. de-asserting after each byte, and not after the whole message). They are really smart people ;)

    the complexity of non-linear pulse trains

    I’m not sure to get your point here. What you propose seems to make it possible to have all moves start at the same time.

    How the non-linearity of pulse train (I guess you refer to the pulses at the coils level) comes into play here ?

  • I plan to use 6 Autodrivers to control a robotic arm. An often needed situation is to start the moves of several joints (i.e. motors) at the exact same time.

    Ideally a “deferred move” command would be used to send the move to be executed at a later time to each motor in turn, and then a “execute pending” sent to all of them (toggling their respective CS line in a synchronized way) would trigger all motors at the same time. Dynamixel digital servos for instance offer this way of controlling several motors in a synchronized way.

    Unfortunately we don’t have such commands with the dSPIN. What would be the best approach to come close to the expected result ?

    Maybe the execution time of the code sending the move command to all involved motors in turn will be short enough so that the delay between each start will be negligible, but this does not satisfy me fully. I’d like to be able to write the control software in Python (on a Raspberry) for a lot of reasons, and I’m afraid to have some timing issues there.

    Any suggestion will be appreciated.

  • If only this product had existed at the time I was working on this project. Similar products I could find at that time cost 10 times this price :(

    I’ll order one to test it… as soon as I could gather enough articles to balance the overseas shipping costs ;)

No public wish lists :(