PDA

View Full Version : [Project] Biped Controller



vehemens
01-16-2015, 09:42 PM
Needed a controller for a biped, so I purchased an OpenCM 9.04 controller, OpenCM 485 expansion board, and a Sparkfun MPU-9150 (SEN-11486). Have however found a few issues so far.

First is that the OpenCM software v1.0.2 is buggy. One issue I found is the Dynamixel.cpp function rxPacket checksum is not correctly calculated if the sum is greater then 255. Fixed it by modifying the code to mask the result prior to the test as follows:

if(mPacketType == 1){ // Dxl 1.0 checksum
for(bCount = 2; bCount < bLength; bCount++){
bChecksum += mRxBuffer[bCount]; //Calculate checksum of received data for compare
}
bChecksum &= 0xff; <-- new line
if(bChecksum != 0xff)

Second is that I cannot connect the MPU to the controller when using the expansion board. Haven't decided if I'm going to solder wires to the controller pins, reverse the controller pins so the MPU can be plugged into it, or something else

Third is that I purchased a ST-Link/V2 as I plan to switch to a Linux development environment. However I was not able to read the flash with my Windows 7 setup. I considered trying to load the Robotis firmware, but have held off so far as I was concerned it would render the controller unusable.

tician
01-16-2015, 11:14 PM
They only had one person at Robotis somewhat dedicated to working on the OpenCM IDE and core, so not too surprising there are still several bugs lurking in their rewrite of the dynamixel library (they reverted to somewhat older code when they made it modular to support multiple dxl objects). The Maple core that was adapted into the OpenCM core was quite shite, so much of the OpenCM core continues in that tradition. If I were still being paid to work with it, I would have continued the complete rewrite of the USB functionality and transforming the rest of the core to mimic/reuse the Arduino 1.5.x ARM core.


Kind of disappointed that they did not add double headers (two 2x20) on the RS-485 breakout to maintain access to the pins of the OpenCM, but there are alternatives like using extra long pins that protrude above and below the OpenCM or using the long pinned stackable pin/socket headers like some arduino shields do (give socket access above and shield pin below). The OpenCM come without any of the 0.1" headers soldered, so should be able to use whatever you want instead of the short headers that come with some of the kits.


The ST-Link is only needed if you want to replace the bootloader, not for normal firmware uploading. If you have an ST-Link dongle, then you have direct access to the entire memory space (RAM, FLASH, and all memory mapped peripherals) so there is no way to bork the STM32 short of disabling JTAG/SWD interface or performing some sort of security lock of the FLASH.

If you use RoboPlus to upload the Robotis firmware to work with RoboPlus Task/Motion/Manager, then you should still be able to use the OpenCM/Arduino IDE to replace it with any other firmware at a later time. The only possible issue is if you have to use the ST-Link to upgrade the CM-904 to the closed-source bootloader they added to all newer OpenCM IDE github repository to use RoboPlus. In the unlikely event that it has changed the upload process such that it breaks compatibility with the OpenCM IDE, then you would still be able to use the ST-Link to upload an older bootloader to restore compatibility with the OpenCM IDE.

vehemens
02-07-2015, 06:17 PM
Kind of disappointed that they did not add double headers (two 2x20) on the RS-485 breakout to maintain access to the pins of the OpenCM, but there are alternatives like using extra long pins that protrude above and below the OpenCM or using the long pinned stackable pin/socket headers like some arduino shields do (give socket access above and shield pin below). The OpenCM come without any of the 0.1" headers soldered, so should be able to use whatever you want instead of the short headers that come with some of the kits.

Just finished replacing several pins on the OpenCM9.04 with longer ones. Did it by removing the plastic frame to allow changing one pin at a time, then put the frame back on in three four pin sections to keep the correct mating pin length. Somehow I bumped off the AREF capacitors while modifying the board, but the card works otherwise.

Noticed that the documentation sheet has errors in the layout figure (i.e. section 2). The 1339 version (i.e. number on the bottom of the sheet), has the 5V and 3.3V pins swapped, and both the 1339 and 1438 version has an extra pin labeled IO 26.

vehemens
02-24-2015, 06:01 AM
Been having a problem with my ST-Link/V2 probe and OpenCM9.04 controller where the ST-LINK utility software kept reporting "Connection to device is lost: ...".

Turns out the diagram (see below) that ROBOTIS has for connecting the controller to the probe is wrong.

Note that the controller can get power from either the probes pin 19 (i.e. 3.3 V) or an external source such as the USB port or a power supply.

When the controller was connected to the probe as shown in the diagram, the ST-LINK utility would report a supply voltage of 1.6 V, but would not work reliably independently of the how the controller was powered.

Turns out you need to connect the controllers 3.3 V pin to the probes pin 1 (i.e. MCU VDD), at that point the ST-LINK utility will report a supply voltage of 3.3 V (external supply) or 3.1 V (probe supplying) and will work reliably. Note to power the controller from the probe, just connect the probes pin 19 to the probes pin 2 (i.e. pins 1 and 2 are connected internally).

vehemens
02-25-2015, 01:03 AM
Note that the controller can get power from either the probes pin 19 (i.e. 3.3 V) or an external source such as the USB port or a power supply.

Took another look at the probe in terms of using it to provide power and found that unloaded it reads 3.28 V and when powering the controller it drops to 3.141 V. So as I've not found any information on max load in the probes documentation, I would advise caution when using the probe to power a device.

vehemens
03-01-2015, 11:28 PM
Now able to load the controller firmware (i.e. boot loader and a OpenCM program) using my Fedora system, openocd and a ST-Link/V2 probe.

In addition, I can now build an OpenCM program on my Fedora system using make and arm toolchain.

One annoying aspect of using the Robotis boot loader is that it sets the "Read Out Protection" bit.

vehemens
03-03-2015, 02:59 PM
Took some searching but found the code for the two libcs3_stm32_XXX_density.a libraries (i.e. five source files and make file). Also got rid of startup_stm32f10x_md.c as it doesn't appear to be used anywhere.

vehemens
03-09-2015, 04:12 AM
Now able to run a subset of the DARwIn-OP CM730 firmware on a OpenCM9.04. Currently it's just the Dynamixel communication routines, but it's enough for most of the DARwIn-OP applications.

vehemens
03-12-2015, 02:17 AM
Was looking for a way to use NeoPixel strips and rings a while back and found a solution on GitHub. It's uses DMA and a timer to reduce processor overhead. Finally had some time to try it and now have it working with an OpenCM9.04, NeoPixel strip and level shifter (i.e. BSS138).

vehemens
03-15-2015, 06:53 AM
Got the STM USB VirtualComport_Loopback example (i.e. stsw-stm32121) running on an OpenCM9.04. Built it as a STM3210E_EVAL board as the documents were available (i.e. user guides, schematics, etc.). Only code change required was to switch the USB disconnect pin to GPIO port C pin 13.

jwatte
03-15-2015, 01:34 PM
bChecksum &= 0xff; <-- new line


For what it's worth, as long as bChecksum is an unsigned char (which it should be, with a name prefix of "b") then that line is not necessary.

vehemens
03-17-2015, 12:09 AM
bChecksum &= 0xff; <-- new line


For what it's worth, as long as bChecksum is an unsigned char (which it should be, with a name prefix of "b") then that line is not necessary.

It's defined as a word in both the windows and linux versions:

byte Dynamixel::rxPacket(int bRxLength){
unsigned long ulCounter, ulTimeLimit;
word bCount, bLength, bChecksum;
byte bTimeout;
...

jwatte
03-17-2015, 10:56 AM
word bCount, bLength, bChecksum;
byte bTimeout;


Beautiful!

And by "beautiful" I mean "terrible in a way that explains why everything is wrong in the world."

KurtEck
03-17-2015, 11:04 AM
FYI - I know it was either Visual Basic or Visual C++, I did something similar.

Why? Because the system would generate an overflow fault if your code overflowed a variable... Simplest way to fix, is to use larger value like word and then and it off... Darn type and value checking...

Kurt ;)

vehemens
03-18-2015, 09:51 PM
Started work last week on the modifications to add a GYRO / Accelerometer to my OpenCM9.04. After reviewing the schematics and component datasheets, I decided to use a LSM9DS0 instead of a MPU-9150 as the functionality was nearly identical to the CM730 components (i.e. L3G4200D and LIS331DLH) and as such would be simpler to integrate.

The LSM9DS0 arrived yesterday and is now working. Testing so far has been with the dxl_monitor program. The firmware changes consist of switching to the SPI1 interface (i.e. was SPI2) and configuring GPIO port A for the SPI and device select signals.

vehemens
03-19-2015, 08:38 PM
When running the dxl_monitor program, had been getting random RX_TIMEOUT and RX_CORRUPT errors, so I took a look at the Linux CM730 message code (i.e. CM730::TxRXPacket).

By increasing the packet timeout value, the errors were eliminated (reduced?) and I could see that the response time reported was ~2.5 ms typical to as much as 13.6 ms.

The varying response time is most likely a result of the differences of my Fedora OS versus the one used for the DARwIn-OP. Not much I can do for now other then to increase the timeout value.

I did notice that the code does not appear to account for the length of the return packet when calculating the timeout value, so that needs to be looked at as well.

Xevel
03-20-2015, 04:00 AM
Maybe check how to set the internal delay of the FTDI (I remember the old days when I used FTDI based stuff on a desktop Ubuntu and did not know that parameters could be changed, and receiving data could suffer up to 16ms of delay...).
On a system properly configured, with servos setup to have 0 in the Return Delay Time register, a round trip should not be more than 2ms.

vehemens
03-27-2015, 04:33 PM
Maybe check how to set the internal delay of the FTDI (I remember the old days when I used FTDI based stuff on a desktop Ubuntu and did not know that parameters could be changed, and receiving data could suffer up to 16ms of delay...).
On a system properly configured, with servos setup to have 0 in the Return Delay Time register, a round trip should not be more than 2ms.

My current assumption is that it's due to the Linux scheduler randomly suspending the dxl_monitor process while it's waiting for the message response and as a result miscalculating the actual response time.

Xevel
03-27-2015, 04:51 PM
Any way to check what is actually happening on the bus? Logic analyzers like the Saleae Logic are quite useful for that.

What is the configuration of your kernel in the matter of preemption? In my mind only servers are configured not to have low latency.
Most kernels I've used set PREEMPT=y, which is indicated for "low latency desktop", and then unless you load the proc at 100% there is no reason that I can think of for the kernel to suspend the process for so long.

vehemens
03-27-2015, 04:58 PM
Started integration of my OpenCM 485 by hooking up the board switches and LEDs. Now that the Mode and Start buttons are available, programs such as the DARwIn-OP demo can be run.

jwatte
04-30-2015, 09:19 PM
By the way -- are you sharing the code setup you're making somewhere? A github repository?

vehemens
05-01-2015, 05:47 PM
By the way -- are you sharing the code setup you're making somewhere? A github repository?

Got a github account and uploaded most of my OpenCM9.04 code changes for baby_overlord (https://github.com/vehemens/baby_overlord).

vehemens
05-31-2015, 11:31 PM
Now have a version that uses the OpenCM9.04 USB and works with the dxl_monitor program. It's just a proof of concept at this point as it does not have full functionality and is unstable.

vehemens
06-07-2015, 06:03 AM
Updated the internal USB version with the LED and button code so the demo program can be run.

vehemens
06-30-2015, 06:41 PM
I've updated my Linux code with fixes including those for running on a Biloid like servo configuration (i.e. angle offsets and rotation inversion from NimbRo-OP).

Also have the core portion of the CM-730 code running on my OpenCM9.04 using the processors USB. In terms of functionality and stability the code is somewhere between alpha and beta.

vehemens
07-09-2015, 03:44 AM
I've incorporated a number of fixes and enhancements into the main and sub controller code since my last post. The most significant enhancement being that the framework hard coded parameters that tend to change for each robot can be now be loaded from a configuration file.

Also one can now use the OpenCM9.04/485 as an alternative to the CM-730 with one caveat. That caveat being an issue with random message failures which I hope to resolve soon.

vehemens
09-07-2015, 07:10 PM
Just upgraded to Fedora 22 from Fedora 20 and it appears that a majority of the sub-controller message errors were OS related as I've only seen an occasional Bulk Read RX corrupt error since the upgrade.