search

HaddingtonDynamics / Dexter

GNU General Public License v3.0
376 stars 85 forks source link

Upgrade Ubuntu Kernel from 12 to 16 LTS #25

Closed JamesNewton closed 5 years ago

JamesNewton commented 6 years ago

Upgrade Ubuntu Kernel from 12 to 16 LTS and produce a new SD card image for user update. This may allow WiFi support and will allow a more modern version of Node.JS to be installed for local scripting.

JamesNewton commented 6 years ago

http://xillybus.com/xillinux has the new image. I set up an SD card following the directions from: http://xillybus.com/downloads/doc/xillybus_getting_started_zynq.pdf

I copied the devicetree.dtb file from the FAT partition on our image. And the FPGA xillydemo.bit file.

With that .dtb file from the old image, the new image will NOT boot; it kernel panics. With the .dtb file provided with the new image, it does boot, but there is only a /dev/uio0 and the extra /dev/uio1 which was on the old image is missing. DexRun.C expects /dev/uio1 Modifying DexRun.c to point to the /dev/uio0 causes the ethernet adapter to stop working, and DexRun fails at the test for mapped[SENT_BASE_POSITION]!=0

I've verified that the correct .bit file is on the image; the #define INPUT_OFFSET 14 one from https://github.com/HaddingtonDynamics/Dexter/commit/50257ea7178e0d76e99f8571c61051b56fff7421 and that DexRun.c does have that offset.

According to this document; http://xillybus.com/doc/old-xillinux-zedboard "boot.bin and xillydemo.bit from Xillinux-1.3 can be used with Xillinux-2.0 with no changes."

Perhaps the device tree was edited to add that new uio1. There is no devicetree.dts file on the old image. The source dts file should be: https://github.com/xillybus/xillinux-kernel/blob/master/arch/arm/boot/dts/xillinux-microzed.dts

Things that do work:

Things that are missing / not configured / not working:

Those issues are moot until we can figure out why DexRun.c isn't seeing what it expects in the mapped area.

JamesNewton commented 5 years ago

The gcc compiler included in Xillinux 16.04 is C99 standard and gets(char*) has been removed from the stdio.h header. Instead, use fgets(char*, int, FILE) e.g. fgets(iString, sizeof(iString), stdio)

JamesNewton commented 5 years ago

Learning to compile the devicetree so that it can be edited and then re-compiled. Following: http://xillybus.com/downloads/doc/xillybus_getting_started_zynq.pdf chapter 6, I was able to get the files: git clone https://github.com/xillybus/xillinux-kernel.git into a folder. But the command export CROSS_COMPILE=/path/to/crosscompiler/arm-xilinx-linux-gnueabi needs a valid path, and I'll be darned if I can find it.

Following: http://xillybus.com/downloads/doc/xillybus_getting_started_linux.pdf The line: apt-get install gcc make kernel-devel-$(uname -r) causes an error: "E: You must put some 'source' URIs in your sources.list" https://techoverflow.net/2018/05/03/how-to-fix-apt-get-source-you-must-put-some-source-uris-in-your-sources-list/ Had the solution.

It appeared to complete once, but now I get Unable to locate package kernel-devel-4.8.0-36-generic

JamesNewton commented 5 years ago

http://xillybus.com/pcie-download says that the "driver" should be included with current Ubuntu distributions (14 or higher, I'm running 16 on my PC and 16 on Dexter). But I've downloaded the files anyway to look at the sample code. As far as I can tell, all of that is designed for use on a PC which has an FPGA in it via the PCIe slot. E.g. NOT for use on the microzed. I think http://xillybus.com/downloads/doc/xillybus_getting_started_linux.pdf is specific to that setup. I'm going back to trying to find the path for the cross compiler in http://xillybus.com/downloads/doc/xillybus_getting_started_zynq.pdf

JamesNewton commented 5 years ago

Apparently none of that is actually needed. There is a specific application to compile or decompile device tree files http://xillybus.com/tutorials/device-tree-zynq-1

I have decompiled our version of the devicetree file from the old v12 OS (see attached) devicetree.dts.zip

In comparison to the new .dts file, I don't see anything that is in our old file that is not in the new file. There are a large number of differences because the format of a decompiled file is slightly different, but even when compiling and decompiling the v16 file, it seems like the v16 file has new items and is not missing anything that is in our v12 file.

A better comparison is between their original v12 file (decompiled) and our modified V12 file (decompiled), but I'm having a difficult time finding that file in their repo. The only commit is apparently the original, or at least it says it's for Xillinux 1.3 as well as 2.0 https://github.com/xillybus/xillinux-kernel/commits/master/arch/arm/boot/dts/xillinux-microzed.dts It looks like I can download the original 1.3 image from: http://xillybus.com/doc/old-xillinux-zedboard

JamesNewton commented 5 years ago

I've downloaded the Xillinux 1.3 image, extracted the .dts file from the boot folder, compiled it, decompiled it (so that the syntax matches as much as possible) and this compared it with the decompiled version of our v12 devicetree.dtb. Here is that session (note all the warnings... no idea what's up with that).

~/Documents/xillinux/dtc$ ls *.dts
devicetree.dts  xillinux-1.3-microzed.dts  xillinux-2.0-microzed.dts

~/Documents/xillinux/dtc$ ./dtc -I dts -O dtb -o xillinux-1.3-microzed.dtb xillinux-1.3-microzed.dts 
xillinux-1.3-microzed.dts:47.6-53.5: Warning (unit_address_vs_reg): /pmu: node has a reg or ranges property, but no unit name
xillinux-1.3-microzed.dts:58.33-317.5: Warning (unit_address_vs_reg): /amba@0: node has a unit name, but no reg property
xillinux-1.3-microzed.dts:292.8-300.5: Warning (simple_bus_reg): /amba@0/leds: missing or empty reg/ranges property
xillinux-1.3-microzed.dts:147.33-188.6: Warning (spi_bus_bridge): /amba@0/ps7-qspi@e000d000: node name for SPI buses should be 'spi'
xillinux-1.3-microzed.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge'
xillinux-1.3-microzed.dts:90.41-114.6: Warning (avoid_unnecessary_addr_size): /amba@0/ps7-ethernet@e000b000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
xillinux-1.3-microzed.dts:234.11-253.7: Warning (avoid_unnecessary_addr_size): /amba@0/ps7-slcr@f8000000/clocks: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
xillinux-1.3-microzed.dts:54.22-57.5: Warning (unique_unit_address): /memory@0: duplicate unit-address (also used in node /amba@0)
xillinux-1.3-microzed.dts:14.3-49: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 'stdout-path' instead

~/Documents/xillinux/dtc$ ./dtc -I dtb -O dts -o xillinux-1.3-microzed.dts xillinux-1.3-microzed.dtb 
xillinux-1.3-microzed.dts: Warning (unit_address_vs_reg): /pmu: node has a reg or ranges property, but no unit name
xillinux-1.3-microzed.dts: Warning (unit_address_vs_reg): /amba@0: node has a unit name, but no reg property
xillinux-1.3-microzed.dts: Warning (simple_bus_reg): /amba@0/leds: missing or empty reg/ranges property
xillinux-1.3-microzed.dts: Warning (spi_bus_bridge): /amba@0/ps7-qspi@e000d000: node name for SPI buses should be 'spi'
xillinux-1.3-microzed.dts: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge'
xillinux-1.3-microzed.dts: Warning (avoid_unnecessary_addr_size): /amba@0/ps7-ethernet@e000b000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
xillinux-1.3-microzed.dts: Warning (avoid_unnecessary_addr_size): /amba@0/ps7-slcr@f8000000/clocks: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
xillinux-1.3-microzed.dts: Warning (unique_unit_address): /memory@0: duplicate unit-address (also used in node /amba@0)
xillinux-1.3-microzed.dts: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 'stdout-path' instead

\~/Documents/xillinux/dtc$ diff devicetree.dts xillinux-1.3-microzed.dts
16c16
<       bootargs = "console=ttyPS0,115200n8 consoleblank=0 root=/dev/mmcblk0p2 rw rootwait earlyprintk mem=0x3f000000";
---
>       bootargs = "console=ttyPS0,115200n8 consoleblank=0 root=/dev/mmcblk0p2 rw rootwait earlyprintk";
71d70
<       linux,phandle = <0x01>;
126d124
<                   linux,phandle = <0x04>;
143d140
<           linux,phandle = <0x05>;
234d230
<           linux,phandle = <0x02>;
281d276
<                   linux,phandle = <0x03>;
349,355d343
<           interrupt-parent = <0x02>;
<       };
< 
<       xillybus_lite@75c00000 {
<           compatible = "xillybus,xillybus_lite_of-1.00.a";
<           reg = <0x75c00000 0x1000>;
<           interrupts = <0x00 0x3c 0x01>;

To summarize the changes:

JamesNewton commented 5 years ago

So it turns out there is a dtc program on the image at: /usr/src/kernels/3.12.0-xillinux-1.3/scripts/dtc and the files compile / decompile without warning when you use it. The result appears to be the same; the same differences are found.

So now to apply the changes to the new dts file. The last section in the source file from the Xillinux 2.0 repo is 

        watchdog0: watchdog@f8005000 {
            clocks = <&clkc 45>;
            compatible = "cdns,wdt-r1p2";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 9 1>;
            reg = <0xf8005000 0x1000>;
            timeout-sec = <10>;
        };

And from the decompiled .dtb file it appears as:

        watchdog@f8005000 {
            clocks = <0x03 0x2d>;
            compatible = "cdns,wdt-r1p2";
            interrupt-parent = <0x02>;
            interrupts = <0x00 0x09 0x01>;
            reg = <0xf8005000 0x1000>;
            timeout-sec = <0x0a>;
        };

So I'm guessing our added section can be 

        xillybus_lite@75c00000 {
            compatible = "xillybus,xillybus_lite_of-1.00.a";
            reg = <0x75c00000 0x1000>;
            interrupts = <0 60 1>;
            interrupt-parent = <&ps7_scugic_0>;
        };

0x3C is 60 in decimal which appears to be the preferred radix for expressing interrupts, and &ps7_scugic_0 appears to translate in to 0x02 as an interrupt-parent

I have no idea what to do about the phandle as they don't appear in the source file, and only show up in the decompiled versions. I'm going to guess they aren't needed.

The mem=0x3f000000 has been added to the end of the bootargs line.

With those changes, the new file appears to compile on the old image. Next to place it on the new image, compile there, and see if a /dev/uoi1 shows up.

JamesNewton commented 5 years ago

And Dexter is up! DexRun runs, and doesn't crash, DDE connects, move all joints works.

The source file, made as indicated above, is attached as xillinux-2.0-microzed-dex.dts.zip. It gets compiled via the Linux kernel device tree compiler. (must be done on a Linux machine, e.g. on Dexter Ubuntu 16.04)

$ git clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git dtc
$ cd dtc
$ make
$ cd ..
$ dtc/dtc -I dts -O dtb -o devicetree.dtb xillinux-2.0-microzed-dex.dts

Which then generates devicetree.dtb.zip which then gets moved to the SDcard FAT partition, and restart

$ mount /dev/mmcblk0p1 /mnt/usbstick/
$ mv devicetree.dtb /mnt/usbstick
$ shutdown -restart now

I was also able to install samba and get it working by following this tutorial: https://tutorials.ubuntu.com/tutorial/install-and-configure-samba#0 The username is root and password is klg.

TODO:

JamesNewton commented 5 years ago

Making DexRun run on startup was confusing. The file /etc/rc.local appears to say that each time a user logs in it will execute, but it appears that it is only run once on system startup. So I just added the line:

/srv/samba/share/DexRun 1 3 0 &

just before the exit 0 line. I tested by logging in twice and pgrep DexRun shows only one copy running.

P.S. Should we make DexRun check for other DexRuns and not start if one is already running? Or kill the running one and start?

EDIT: That does NOT work. Starting from root, if you do /srv/samba/share/DexRun 1 3 0 & it starts, displays all the expected messages, responds to commands, but the arm doesn't move! On the exact same robot, DDE, etc.. if I cd to /srv/samba/share and enter ./DexRun 1 3 0 & then it DOES work! The issue appears to be the working directory, because if you are in /srv/samba/share, then /srv/samba/share/DexRun 1 3 0 & does work and the arm moves. So the working directory is critical.

I created a file in /srv/samba/share called RunDexRun and in it put:

cd /srv/samba/share
./DexRun 1 3 0 &

then changed it's permissions so everyone can run it, and that works from the root directory, e.g. from / the command /srv/samba/share/RunDexRun works.

So I've edited /etc/rc.local to put in 

/srv/samba/share/RunDexRun

and after a restart, Dexter moves again.

JamesNewton commented 5 years ago

Had already apt-get install gnome-session but gnome-session --debug reports that hardware acceleration failed. gnome-session --debug --disable-acceleration-check fails to find any gnome sessions

nano /etc/ssh/ssh_config and changed X11Forwarding yes then service sshd reload but I don't think that applies because e.g. xclock or leafpad work just fine already.

apt-get install ubuntu-desktop but I think that just gets all the apps that can run on the desktop. e.g. libreoffice, etc... Maybe it will also install valid sessions? Yep... Now gnome-session --disable-acceleration-check appears to work, but XMing crashed. Try more tomorrow.

JamesNewton commented 5 years ago

gnome-session --disable-acceleration-check works, but all you get is a desktop with terminal. No launcher, the right click options just offer to create a folder, open terminal, sort the desktop icons by name, and "Keep Alighted" which is checked. There is no status bar at the top, etc... The debug output is massive: DexterGnomeSession.log

A 2D gnome-session file is apparently needed?

Following this page: https://askubuntu.com/questions/795301/gnome-classic-on-ubuntu-16-04 I installed the "flashback" to put gnome on 16.04 sudo apt-get install gnome-session-flashback

None of that seems to work. Many errors are listed on the debug output. I think the issue is the session files aren't right or I'm not starting it right. Searching for gnome-session documentation, I found this: https://help.gnome.org/admin/system-admin-guide/stable/session-user.html.en and realized perhaps its the desktop that isn't being started. Looking in /usr/share/xsessions I see a ubuntu.desktop file which contains the same gnome-session --session=ubuntu which doesn't work. The Lubuntu.desktop file contains: /usr/bin/lxsession -s Lubuntu -e LXDE which actually works! But it's a very different desktop. Actually a bit more like Windows, with a start menu lower left, and task bar across the bottom. /usr/bin/startlxde also works, but it basically the same with a different wallpaper.

/usr/bin/openbox-session Sort of works, but is apparently missing "debian-menu.xml" files so it comes up with a blank grey screen. Right click to access a setup menu. The missing bits can perhaps be downloaded?

Apparently the issue is that 1. we don't have hardware acceleration since there isn't a real graphics card and 2. ubuntu-2d support has been removed, and the standard one expects unity 3d support? Perhaps sticking with Lubuntu desktop is best?

JamesNewton commented 5 years ago

DDE is running on the 16.04 image! The following instructions from Bret with one small change to the last line did it:

$ git clone https://github.com/cfry/dde
$ cd dde
$ npm i
$ npm run start

npm run build can't work because the electron-packager can't run on arm processors, although it can apparently create packages for arm7l when run on x86, etc... In this case, we don't need to make a distributable package, we just want to run it.

A "dde_apps" folder must be created under the "/root" folder (alongside Documents, not in it).

Setting the dexter0 ip address to localhost in the dde_init.js file allows local connection of DDE to DexRun. The program takes a while to load (need faster SD Card and interface?) but operation isn't horribly slow on the Lubuntu desktop.

JamesNewton commented 5 years ago

DexRun was crashing whenever I tried to make the robot move. It turns out this was as the result of a "write past end of array" error that has been in the code for a long time. See source code below. In the past, whatever was in memory after RxBuf (usually TxPacket so no harm done) was getting clobbered and there was no indication of it. The new gcc includes code that catches this at run time and causes a *** stack smashing detected *** crash.

Here is the relevant code: https://github.com/HaddingtonDynamics/Dexter/commit/42df0e01285ef8b67764ed53f3cc697df44d4d93#diff-691272021fae98368efb598f8e089c16R1339

void UnloadUART(unsigned char* RxBuffer,int length)
{
    int i;
    unsigned char RecData;
    for(i = 0;i < length + 11; i++)
    {
        mapped[UART1_XMIT_CNT] = 16; // generate next data pull
        RecData = mapped[UART_DATA_IN];
        RxBuffer[i] = RecData;
        #ifdef DEBUG_XL320_UART
        printf(" %x ", RecData);
        #endif
        mapped[UART1_XMIT_CNT] = 0; // generate next data pull       
    }
}
void SendGoalSetPacket(int newPos, unsigned char servo)
{
    int i;
    unsigned char RxBuf[20];
    unsigned char TxPacket[] =  {0xff, 0xff, 0xfd, 0x00, servo, 0x07, 0x00, 0x03, 30, 0, newPos & 0x00ff, (newPos >> 8) & 0x00ff, 0, 0};
    unsigned short crcVal;
    crcVal = update_crc(0, TxPacket, 12);
    TxPacket[12]=crcVal & 0x00ff;
    TxPacket[13]=(crcVal >> 8) & 0x00ff;

    SendPacket(TxPacket, 14, CalcUartTimeout(14 + 14),RxBuf, 16);  // send time plus receive time in bytes transacted
    //UnloadUART(RxBuf,16); // TODO refine actual size
}

SendPacket just passes that RxBuf pointer and the 16 onto UnloadUART which then shoves 27 (16+11) bytes into it, writing 7 bytes past its end. I've updated the code on the SpeedsUpdate branch to use sizeof in all cases and set the size of the char array to the size I think it's actually pulling.

cfry commented 5 years ago

You're reminding me why I don't miss writing C code. Great detective work!

On Fri, Jan 25, 2019 at 8:33 PM JamesNewton notifications@github.com wrote:

DexRun was crashing whenever I tried to make the robot move. It turns out this was as the result of a "write past end of array" error that has been in the code for a long time. See source code below. In the past, whatever was in memory after RxBuf (usually TxPacket so no harm done) was getting clobbered and there was no indication of it. The new gcc includes code that catches this at run time and causes a stack smashing detected crash.

Here is the relevant code: 42df0e0#diff-691272021fae98368efb598f8e089c16R1339 https://github.com/HaddingtonDynamics/Dexter/commit/42df0e01285ef8b67764ed53f3cc697df44d4d93#diff-691272021fae98368efb598f8e089c16R1339

void UnloadUART(unsigned char* RxBuffer,int length) { int i; unsigned char RecData; for(i = 0;i < length + 11; i++) { mapped[UART1_XMIT_CNT] = 16; // generate next data pull RecData = mapped[UART_DATA_IN]; RxBuffer[i] = RecData;

ifdef DEBUG_XL320_UART

  printf(" %x ", RecData);
  #endif
  mapped[UART1_XMIT_CNT] = 0; // generate next data pull      
  }

} void SendGoalSetPacket(int newPos, unsigned char servo) { int i; unsigned char RxBuf[20]; unsigned char TxPacket[] = {0xff, 0xff, 0xfd, 0x00, servo, 0x07, 0x00, 0x03, 30, 0, newPos & 0x00ff, (newPos >> 8) & 0x00ff, 0, 0}; unsigned short crcVal; crcVal = update_crc(0, TxPacket, 12); TxPacket[12]=crcVal & 0x00ff; TxPacket[13]=(crcVal >> 8) & 0x00ff;

SendPacket(TxPacket, 14, CalcUartTimeout(14 + 14),RxBuf, 16); // send time plus receive time in bytes transacted //UnloadUART(RxBuf,16); // TODO refine actual size }

SendPacket just passes that RxBuf pointer and the 16 onto UnloadUART which then shoves 27 (16+11) bytes into it, writing 7 bytes past its end. I've updated the code on the SpeedsUpdate branch https://github.com/HaddingtonDynamics/Dexter/commit/769d4dc53fa3eded806d40d2389f94b8e83700c9 to use sizeof in all cases and set the size of the char array to the size I think it's actually pulling.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaddingtonDynamics/Dexter/issues/25#issuecomment-457788807, or mute the thread https://github.com/notifications/unsubscribe-auth/ABITfXI5HnnNMUMYFqKX6z8VVbY1rNMeks5vG7B9gaJpZM4Vk673 .

cfry commented 5 years ago

From James N above: "A "dde_apps" folder must be created under the "/root" folder (alongside Documents, not in it)."

I'm surprised by this because I've seen a "Documents" dir in Linux systems that SEEMS to be the same kind of dir that both Windows and MacOS has. (which itself is a miracle that the 3 agreed on something so sensible.) Now the code that determines where the dde_apps folder should live is in DDE main.js,

let documents_dir = app.getPath("documents") console.log("First try getting 'documents' yielded: " + documents_dir) let the_dde_apps_dir = documents_dir + "/dde_apps"

So I guess what's happening is that in Linux,

app.getPath("documents") doesn't return

a "Documents" dir at all, but "/root"

This is more expected, ie whenever a decent standard is proposed,

somebody will screw it up.

Now is this the same for Ubuntu running on your laptop,

or can the dde_apps dir be under "documents" there?

BTW, I'm impressed that you figured this out.

Did my console.log statement above help?

I left it in there for just such a possibility.

On Fri, Jan 25, 2019 at 8:33 PM JamesNewton notifications@github.com wrote:

DexRun was crashing whenever I tried to make the robot move. It turns out this was as the result of a "write past end of array" error that has been in the code for a long time. See source code below. In the past, whatever was in memory after RxBuf (usually TxPacket so no harm done) was getting clobbered and there was no indication of it. The new gcc includes code that catches this at run time and causes a stack smashing detected crash.

Here is the relevant code: 42df0e0#diff-691272021fae98368efb598f8e089c16R1339 https://github.com/HaddingtonDynamics/Dexter/commit/42df0e01285ef8b67764ed53f3cc697df44d4d93#diff-691272021fae98368efb598f8e089c16R1339

void UnloadUART(unsigned char* RxBuffer,int length) { int i; unsigned char RecData; for(i = 0;i < length + 11; i++) { mapped[UART1_XMIT_CNT] = 16; // generate next data pull RecData = mapped[UART_DATA_IN]; RxBuffer[i] = RecData;

ifdef DEBUG_XL320_UART

  printf(" %x ", RecData);
  #endif
  mapped[UART1_XMIT_CNT] = 0; // generate next data pull      
  }

} void SendGoalSetPacket(int newPos, unsigned char servo) { int i; unsigned char RxBuf[20]; unsigned char TxPacket[] = {0xff, 0xff, 0xfd, 0x00, servo, 0x07, 0x00, 0x03, 30, 0, newPos & 0x00ff, (newPos >> 8) & 0x00ff, 0, 0}; unsigned short crcVal; crcVal = update_crc(0, TxPacket, 12); TxPacket[12]=crcVal & 0x00ff; TxPacket[13]=(crcVal >> 8) & 0x00ff;

SendPacket(TxPacket, 14, CalcUartTimeout(14 + 14),RxBuf, 16); // send time plus receive time in bytes transacted //UnloadUART(RxBuf,16); // TODO refine actual size }

SendPacket just passes that RxBuf pointer and the 16 onto UnloadUART which then shoves 27 (16+11) bytes into it, writing 7 bytes past its end. I've updated the code on the SpeedsUpdate branch https://github.com/HaddingtonDynamics/Dexter/commit/769d4dc53fa3eded806d40d2389f94b8e83700c9 to use sizeof in all cases and set the size of the char array to the size I think it's actually pulling.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaddingtonDynamics/Dexter/issues/25#issuecomment-457788807, or mute the thread https://github.com/notifications/unsubscribe-auth/ABITfXI5HnnNMUMYFqKX6z8VVbY1rNMeks5vG7B9gaJpZM4Vk673 .

JamesNewton commented 5 years ago

LOL. Adding wifi support required: 1. Plugging in a usb wifi dongle (I didn't even restart... just hot plugged it) 2. configuring my wifi SSID and password. Done. Stable and working nicely so far. I can connect to the robot from DDE on my PC to the adapters IP address and send commands.

JamesNewton commented 5 years ago

Quick note: On Ubuntu 16.04 PC, you can add the -X to ssh, as in ssh root@192.168.1.142 -X and it will forward all XWindows commands back to the local PC. So you can /usr/bin/startlxde and the Dexter desktop show up ON the PC desktop! LOL! Luckily, the XDE desktop uses the bottom and left corner, and the Ubuntu desktop uses the top and left side, so they co-exist pretty well. It's fun keeping track of which application is running on which device.

JamesNewton commented 5 years ago

I'm setting the cat 5 interface to 192.168.1.142 and using the WiFi interface (via a little USB dongle) via DHCP to my router. The #51 issue is effectively resolved and this greatly simplifies the use of the arm: When no router / wifi is available, a direct connection with CAT5 to a PC provides the expected static IP interface on the 192.168.1 network. With that, the user can SSH in and setup WiFi via the command line or use the xWindows interface to set it up via the very easy configuration dialog box from the network icon in the lower right corner of the desktop. If a fixed IP is desired for the WiFi, that can be configured on Dexter or, if the wifi router is accessible, it might support manually assigned DHCP addresses based on the MAC id of the WiFi adapter. I have NOT been able to get Dexter to drop the DHCP lease, so I would recommend setting that up on the router /before/ enabling WiFi on Dexter.

JamesNewton commented 5 years ago

Note that for support of the Dynamixel servos, /srv/samba/share/RunDexRun or /etc/rc.local must start DexRun with parameters 1 3 1 vs 1 3 0. That was an hour and a half of my life and more than a few curse words. I knew that, but had forgotten it.

I was able to confirm that BOTH servos do work after eventually getting my "3" servo made back into a "1" servo. See the Wiki Article for programming servos

In DDE 2.5.13 LTS, under Jobs / Show robot status, if I press the "run update job" button, at first I get 148.48 and 0 for Joint 6 and Joint 7 "MEASURED ANGLE" but if I first move J6 / J7 by going to Jobs / Run instruction / Show dialog... and enter 0 for J6 and J7 then press "move_all_joints" then go back and do the status thing again, it works correctly.

Note that the 'a' command values for J6/7 are in servo units, not arcseconds. @JamesWigglesworth says that for J6 zero degrees is actually 512 and for J7 it's 0.

Apparently, the FPGA needs to be told to move J6/7 before that system becomes active. As per Kent, we can fire that off automatically on startup. e.g. there is no reason not to. The easiest way to do that is by adding values for J6/7 to a boot dance 'a' command in a make_ins file. This keeps it under customer control. e.g. if they don't want that running, they can delete or modify the file. Figuring out which file to put that in is probably a conversation to have with @JamesWigglesworth , but for now, I've just added a 0 0 0 0 0 512 0 to the autoexec.make_ins file.

Sadly, that file /isn't being executed/ because the code that does it was moved to after the sleep in mode 3!

So I'm moving that to the start.

Now the servos send back position as soon as the robot starts.

JamesNewton commented 5 years ago

Note to self: Xillinux 2.0 uses U-BOOT, not GRUB or LILO. https://www.denx.de/wiki/view/DULG/Manual

JamesNewton commented 4 years ago

Kamino cloned this issue to HaddingtonDynamics/OCADO