RicE06

Member Since: January 12, 2009

Country: United States

Profile

Role

researcher

Spoken Languages

French, English

Programming Languages

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

Associations

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

Expertise

embedded software, electronics, sensor networks, IA

Interests

robotics, electronics, music

  • I’ve attached this block with the base one, and it is not possible to insert an SD card into the slot when a USB cable is connected.

    This means that you have to disconnect the cable(s) first (and thus to shut down the Edison before it it is powered through them) for either inserting or removing a card. Not very practical for a removable data support :/

    The only option is to buy the battery block and use it as backup PSU while the USB cable which powers the Edison is disconnected. Not a big deal :(

    As I wrote in another comment, I’ve bought an assortment of blocks for professional research works involving IoT stuff, and although they are quite attractive at first (and on the pictures) they prove to have too many design flaws for being really adopted for use cases other that basic ones.

    I hope that Sparkfun (which is one of my favourite providers for the kind of products they sell) will come soon with redesigned versions of these blocks, taking in account a couple of mechanical issues (another customer mentioned to problem of bolts been too close to some components, there is also the problem of the battery being shorted by the USB socket of the base block if you overlook to put an insulation first,…).

    Best regards

  • Although very attractive, these boards have some annoying flaws.

    Among others, the space between the micro-USB sockets has been underestimated, and it is not possible to use both sockets depending on the USB plugs housing size.

    Another big problem is the battery pack. The USB socket placement is even worse since you just cannot connect any USB cable to the base board sockets once you have connected the power supply to the battery pack.

    I have bought several pieces of each for a research experiment at work and I’m not able to use them as planned.

    Any suggestion please ?

  • Hello,

    Any plan for a RS485 block ?

  • Hello,

    Is there any way (f.i. by reading some system file in /sys or alike) to know if external power is applied? I’d like to issue a system shutdown after a given delay past the loss of external supply.

    Maybe some uevent is available for this too, but I could not find information about this topic until now.

    TIA for any suggestion.

    Best regards

  • 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.

No public wish lists :(