Looking for folks to test a possible fix to the program the arduino failures


#1

https://gist.github.com/BrianAdams/5174730

Replace the /opt/openrov/linux/arduino/firmware-upload.sh file with this one. It keeps the reset pin low until after programing completes and seems to work first shot for me each time. Let me know if it works for you.


#2

I tried this on the weekend on 2 systems (my test bench system and my Openrov) it did not work. I still got errors on the reset at the end and ended up using the UNO board to progam. Sorry, it would be a lot easier if it worked.

I really like the new code for Open CockPit! It has some great features, cannot wait to try it in the pond or lake. We still have ice here.

I attached a file showing how I uploaded the Beaglebone with your code. It has a couple of changes to the original docs.

John

1541-updatingOpenROVsoftware.rtf (45.5 KB)

#3

Thanks! Yea, I'm still hitting my head on the keyboard trying to figure this out. The only other delta I can think of is that I moved the my programmer speed from 57.6 to 115.2. Usually the first try my updates work, but if they fail to work the retries don't make a difference. I actually need to wait and try then entire process again. If it does not work after 3 tries I find rebooting the bb gets me back to first try works.

Regardless, thanks for trying.

-Brian


#4

it failed for me aswell,

ive attached the output from before and after changing the file.

it seems that the response is a bit diffrent from avrsync.

1540-firmwareuploadfailure.txt (9.73 KB)

#5

Yea. I think these are all the same original problem. I suspect that the bootloader is not kicking in in time and catching the programming request signal before starting the program loop. Odd thing is that it seem the first time it fails, it consistently fails with the same error code for all of the retries.

Anyhow, this reminds me that I need to reopen the issue in git...


#6

I have tried to install the openrov-master-software.zip and it seems to pause after Scanning dependencies of src. I then have to hit Apply new firmware to get it to move on to the next file then it just stopped responding and never did a scan on the last file.

undefinedunpack: build dir is /tmp/tmp.FsIFI5mnel
Scanning dependencies of src
unpack: build dir is /tmp/tmp.KPdSrajXov
Scanning dependencies of src
unpack: build dir is /tmp/tmp.e892TgjLRM
Scanning dependencies of src
unpack: build dir is /tmp/tmp.qBMpqeqLkA
Scanning dependencies of src
unpack: build dir is /tmp/tmp.nrLelg5V4n
Scanning dependencies of src
unpack: build dir is /tmp/tmp.2R9bhVcLex
Scanning dependencies of src
unpack: build dir is /tmp/tmp.8bHt8JnNIu
Scanning dependencies of src
unpack: build dir is /tmp/tmp.0bZMtoseqH
Scanning dependencies of src
unpack: build dir is /tmp/tmp.ssTyQOVef2
Scanning dependencies of src
unpack: build dir is /tmp/tmp.6RyWqzMwVU
Scanning dependencies of src
unpack: build dir is /tmp/tmp.eN0pNj7tPm
Scanning dependencies of src
unpack: build dir is /tmp/tmp.pzZB38xJqM
Scanning dependencies of src
unpack: build dir is /tmp/tmp.amy7SlJC13
Scanning dependencies of src
unpack: build dir is /tmp/tmp.txEo5Cjcj3
Scanning dependencies of src
unpack: build dir is /tmp/tmp.M8garbJ3Ir
Scanning dependencies of src
unpack: build dir is /tmp/tmp.B0YGQiRjSU
Scanning dependencies of src
unpack: build dir is /tmp/tmp.kmSLXtigBd
Scanning dependencies of src
unpack: build dir is /tmp/tmp.tNv4h1Bbo5
Scanning dependencies of src
unpack: build dir is /tmp/tmp.hVU3A7e2v4
Scanning dependencies of src
unpack: build dir is /tmp/tmp.VSiSsSVzh4
Scanning dependencies of src
unpack: build dir is /tmp/tmp.RkXlkCbYDY
Scanning dependencies of src
unpack: build dir is /tmp/tmp.BPhEKJhq52
Scanning dependencies of src
unpack: build dir is /tmp/tmp.a8j0yzDD0Z
Scanning dependencies of src
unpack: build dir is /tmp/tmp.ZlDMckj29f
Scanning dependencies of src
unpack: build dir is /tmp/tmp.laFkUqC9zg
Scanning dependencies of src
unpack: build dir is /tmp/tmp.dkvYe915TU
Scanning dependencies of src
unpack: build dir is /tmp/tmp.F4LSbdKWat
Scanning dependencies of src
unpack: build dir is /tmp/tmp.PbrB078CjM
Scanning dependencies of src
unpack: build dir is /tmp/tmp.BFyy8ZfdA3
Scanning dependencies of src
unpack: build dir is /tmp/tmp.s1fe4RvoY8
Scanning dependencies of src
unpack: build dir is /tmp/tmp.ip49LarsaR
Scanning dependencies of src
unpack: build dir is /tmp/tmp.jHhoVrYQBt
Scanning dependencies of src
unpack: build dir is /tmp/tmp.TrjqL3KaSb
Scanning dependencies of src
unpack: build dir is /tmp/tmp.yNl1JcIsIr
Scanning dependencies of src
unpack: build dir is /tmp/tmp.0sQx9pIOYp
Scanning dependencies of src
unpack: build dir is /tmp/tmp.RHD8MrCSVh
Scanning dependencies of src
unpack: build dir is /tmp/tmp.UMD9AQEYZp
Scanning dependencies of src
unpack: build dir is /tmp/tmp.4tsVC2BVlZ


#7

I used a copy of the openrov-software-master I had from 19 Mar and this seems to work ok.


#8

I use to edit the Arduino files directly at the beaglebone (using putty and the vi editor), so I don't use the cockpit software to update the Arduino firmware. But from the console, I have a reliable script to upload the code from there.

In /opt/openrov/arduino/Openrov I created a subdirectory called 'src' and another one called 'lib'. I put all the files (Openrov.ino etc.) from the directory /opt/openrov/arduino/Openrov to the subdir 'src'. Thie 'lib' directory is empty, but is required by the 'ino' command.

When I want to upload the firmware, I go to /opt/openrov/arduino/Openrov and execute the following simple script from there (as root with sudo):

ino clean
ino build
/opt/openrov/linux/setuart.sh
/opt/openrov/linux/reset.sh &
sleep 0.4
ino upload -p /dev/ttyO1

Which builds and uploads the code reliably. The crucial thing about this was to find out the correct sleep value (0.4 seconds) after starting the reset and before starting the upload - the time window seems to be very narrow.

Maybe this is the key for making Brian's code work?

-Stefan


#9

Perfect thanks so much for sharing this I will give it a try.


#10

I've been able to follow the instructions that Stefan lists here, but I'm not having any luck controlling the motors. I've tried this on a clean install of the OpenROV image (freshly updated to the latest software), but the motors will only respond for a moment or two, then there is no further response. I'm wondering if there is something wrong with the firmware I've uploaded. Is there any good way to verify that the upload worked correctly?

-Ben


#11

Check the /var/log/openrov/log for errors. In the telemetry on the lower right, do you see a "motors: 1" listed? It indicates if the motors are currently engaged or not.


#12

Here's what I get in the openrov.log file:

/opt/openrov/node_modules/nconf/lib/nconf/stores/file.js:132
throw new Error("Error parsing your JSON configuration file.")
^
Error: Error parsing your JSON configuration file.
at File.loadSync (/opt/openrov/node_modules/nconf/lib/nconf/stores/file.js:$
at Provider.add (/opt/openrov/node_modules/nconf/lib/nconf/provider.js:135:$
at Provider.use (/opt/openrov/node_modules/nconf/lib/nconf/provider.js:108:$
at Object.<anonymous> (/opt/openrov/src/lib/config.js:20:7)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:362:17)
at require (module.js:378:17)

As for the random obnoxiousness, the software is still giving me fits. The motor control seems to be working now (somewhat - more on this in a bit), but within a minute or two of getting things going, the whole things freezes - no more camera, putty connection drops, and reloading cockpit doesn't improve the situation. Disconnecting power seems to be the only way forward, and that only works sporadically (sometimes I can't connect, even after a reboot.)

When I am managing to test the motor, I'm running into trouble at the low throttle ranges. At low throttles, the motor moves spasmodically, appearing to twitch in both directions before I get the throttle high enough to get things into constant motion. But if I just let the thing sit - no commands - it will twitch every 15 seconds or so. I'm not sure what's going on here. I'm going to play with the ESC programming and see if that improves the situation.

Something weird is going on - at a minimum I'm getting much different behavior this evening compared to yesterday.

-Ben


#13

Go ahead and delete the /usr/local/etc/rovconfig.json. That should clear the JSON error. It will automatically get recreated.

It is likely the JSON error is killing the cockpit software which would explain everything suddenly stopping until you reboot... and then it would be a question of timing before it crashes again.

As far as the twitches go. there is a problem on the serial connection where we get corrupt data between the beagle and the arduino. It may be as simple as needing to turn on error correction on the serial connection but I've not looked in to it yet. The latest firmware has code that ignores motor commands that are outside normal parameters which seemed to be the case most times that corruption would occur so it *should* be rare to see the motors twitch anymore.

The big exception to this is if the ESCs have not been calibrated in which case they can easily seem to randomly turn.


#14

I'll do that when I get things set up again tomorrow. Between clearing the JSON file and calibrating the ESCs, maybe that will take care of this. I appreciate all your help!

-Ben


#15

Does not work ever for me. Stefan's method works occasionally, but sometimes the delay is .1, sometimes, .2, and sometimes, .4 - aaarrrr. I started poking around in avrdude.conf (/usr/share/arduino/hardware/tools/avrdude.conf). I found the 328P section and upped the resetdelay to 2000 and I can get it to program 9 out of 10 times.


#16

I think I found the solution for this. After stumbling across this page: http://wiki.openrov.com/index.php/Software_Rearchitecture, I modified upload.py to toggle the reset pin directly, and I get 100% upload success.


#17

Cool. Can you post a diff of the file?


#18

Let me give you a little background. I have been a programmer on and off for 30 years. I was a Linux administrator back during the dotcom boom. But I haven't had to dig deep into Linux for several years. For the last 10 years, I've been primarily working in C++, PHP/MySQL, PhotoShop, CorelDraw, and G-Code - so I am in a re-learning process right now. I am most familiar with RedHat, so just navigating the OpenROV file system is taking me some time right now. Git did not exist when I was a Linux guru, we only had RPMs and g-zipped tarball source files back then. I have never even looked at Python code before, and Node.js is greek to me. So having said all that...

I simply found the section where upload.py was toggling DTR and called an external script with subprocess.call('/reset_low', shell=True). The script /reset_low contains echo "low" > /sys/class/gpio/gpio32/direction. I know you can simply run the command directly in the python code, but there seems to be a maximum length component to the syntax, and I don't yet know how to properly escape the shell characters. So the quickest and dirtiest thing I could think of was to create scripts in / and call them. Any advice to further kickstart my Python skills would be appreciated.


#19

Okay, I figured out the python thing. Here's a diff file. The proper python syntax is: subprocess.call('echo \"low\" > /sys/class/gpio/gpio32/direction', shell=True)

1539-upload.py.diff (197 Bytes)

#20

Well I finally got to integrating it back in and on first pass it looks promising. I'll keep on it over the weekend and see if it keeps working.