Obviously, there is a version mismatch between the Freedom firmware version and the Aisoy’s ROS stacks. Let’s go to botserver again the start a new update in case it could fix the situation. We can read all the apt-get typical messages on the console. Bad luck botserver is not available in source form, since grabbing the appropriate command from there would allow using it directly from the console. This situation is by the way a bit abnormal for a product advertised as open-source.
This time things seem in better shape, since the error messages are no more here. freedom_driver.py is not the same version neither, since the test statement which triggered the error message is not the same as before. The new statement shows that the previous version was a typical copy/paste bug, borrowing code the the accelerometer related code.
The on/off switch is operational too Would it be that we have succeeded in reaching working conditions now ? If so, a backup copy of the SD card is mandatory.
Now that the servo arm has been fixed at the right position we can check that the head moves as expected during the initialisation sequence, and also when actuating in test programs. Guys, it seems that we are on the right track now.
Go ahead re-assembling the thing, adding a piece of foam in the battery case to avoid it to wander too freely. Patiently put all the cables in place and switch on. Strange : no more display on the LED matrix now No result neither when trying the direct Freedom command ((echo "k OK " > /dev/ttyACM0). The mouth displays a line and nothing else.
I am now able to disassemble the Aisoy with eyes shut and in the dark. Once the PCBs off their supports, the cause is clearly visible : the tiny JST like connector of the I2C link to the LED matrix is broken. One of its legs is cut.
Such sockets should normally be soldered flush to the PCB, but Aisoy assemblers have decided otherwise, and have placed them nearly 1mm off the surface. This is clearly visible on the speaker cable socket, which is still alive but for how long ?
The problem with this strange mounting option is that the mechanical stress created by connecting and disconnecting the cable is transferred to the tiny legs, although it is supposed to be absorbed by the socket housing contact with the PCB. Hence the current situation
Since I have not this kind of connector in stack, a makeshift repair is done by soldering short wires to the PCB, and link them to a polarized header. I would have re-engineered almost all connectors of this beast
Another strange thing : why did they use a shielded cable for the speaker ? This is strictly of no use for speaker level signals and has the disadvantage to be quite stiff for short lengths such as here, generating a bit more stress on connections. By the way, it was secured to the connector with a bit of melt glue
Yup. Dumped to the trash, and replaced by standard wires. The problem now is that the tiny JST plug cannot be reused (since half crimped and half soldered) and I do not have this kind of parts in my stock. McGyver method one again : use two female crimped contacts without housing and insulated with shrink wrap tubing. This fits well in the socket and provides good electrical contact and mechanical retention. I guess that sooner or later the speaker cable socket will break the same way the I2C did, and that it will be replaced by the same alternate solution.
Well, with respect to sturdiness this is another story. What should happen happened : one of the two columns of the RasPi fixture broke The backpack is no more attached to the Aisoy. I’ll try to glue it but am not confident at all.
[EDIT 25/04/14] This has been fixed a bit later
Well, our Aisoy is not what I would call a finished product. It will be a bit difficult to use it in real projects, that is to say manipulated by people other that properly educated ones, for instance the volunteers who participate to the scientific experiments I work on in my professional activities .