Maestro-linux will not run

iHover · March 26, 2017, 12:32am

I followed all the instructions on the liniux install and maestro-linux will not run I get the following error
Oh I’m running the latest version of raspberry PI Linux OS on raspberry PI 3

 Assertion at mini-codegen.c:807, condition `i == sel' not met

Stacktrace:

  at <unknown> <0xffffffff>
  at System.Windows.Forms.TextBoxBase.Draw (System.Drawing.Graphics,System.Drawing.Rectangle) <0x000ab>
  at System.Windows.Forms.TextBoxBase.OnPaintInternal (System.Windows.Forms.PaintEventArgs) <0x00063>
  at System.Windows.Forms.Control.WmPaint (System.Windows.Forms.Message&) <0x0017f>
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) <0x00217>
  at System.Windows.Forms.TextBoxBase.WndProc (System.Windows.Forms.Message&) <0x00313>
  at System.Windows.Forms.TextBox.WndProc (System.Windows.Forms.Message&) <0x001d3>
  at System.Windows.Forms.Control/ControlWindowTarget.OnMessage (System.Windows.Forms.Message&) <0x0002b>
  at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) <0x0003b>
  at System.Windows.Forms.NativeWindow.WndProc (intptr,System.Windows.Forms.Msg,intptr,intptr) <0x0028b>
  at System.Windows.Forms.XplatUIX11.DispatchMessage (System.Windows.Forms.MSG&) <0x00023>
  at System.Windows.Forms.XplatUI.DispatchMessage (System.Windows.Forms.MSG&) <0x0002b>
  at System.Windows.Forms.Application.RunLoop (bool,System.Windows.Forms.ApplicationContext) <0x00abf>
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) <0x0005f>
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) <0x0002b>
  at Pololu.MaestroControlCenter.Program.Main () <0x0003b>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:


Debug info from gdb:

[New LWP 1437]
[New LWP 1436]
[New LWP 1435]
[New LWP 1434]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
0x76ec9ef8 in __libc_waitpid (Cannot access memory at address 0x3
pid=1438, stat_loc=0x7ed63d80, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
40	../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
  Id   Target Id         Frame 
  5    Thread 0x75cfb430 (LWP 1434) "mono" 0x76ec7a40 in do_futex_wait (isem=isem@entry=0x3181a4) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
  4    Thread 0x735c1430 (LWP 1435) "mono" 0x76ec57a4 in __pthread_cond_wait (Cannot access memory at address 0x1
cond=0x10184e0, mutex=0x10184c4) at pthread_cond_wait.c:187
  3    Thread 0x732ff430 (LWP 1436) "mono" 0x76e40b80 in poll () at ../sysdeps/unix/syscall-template.S:81
  2    Thread 0x72aff430 (LWP 1437) "mono" 0x76ec57a4 in __pthread_cond_wait (Cannot access memory at address 0x1
cond=0x1018450, mutex=0x1018434) at pthread_cond_wait.c:187
* 1    Thread 0x76fdf000 (LWP 1433) "mono" 0x76ec9ef8 in __libc_waitpid (Cannot access memory at address 0x3
pid=1438, stat_loc=0x7ed63d80, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40

Thread 5 (Thread 0x75cfb430 (LWP 1434)):
#0  0x76ec7a40 in do_futex_wait (isem=isem@entry=0x3181a4) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
#1  0x76ec7af4 in __new_sem_wait (sem=0x3181a4) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69
#2  0x00219f98 in mono_sem_wait ()
#3  0x0019091c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x735c1430 (LWP 1435)):
Cannot access memory at address 0x1
#0  0x76ec57a4 in __pthread_cond_wait (cond=0x10184e0, mutex=0x10184c4) at pthread_cond_wait.c:187
#1  0x001f6ae8 in ?? ()
Cannot access memory at address 0x1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0x732ff430 (LWP 1436)):
#0  0x76e40b80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7349b848 in ?? () from /usr/lib/arm-linux-gnueabihf/libusb-1.0.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0x72aff430 (LWP 1437)):
Cannot access memory at address 0x1
#0  0x76ec57a4 in __pthread_cond_wait (cond=0x1018450, mutex=0x1018434) at pthread_cond_wait.c:187
#1  0x001f6ae8 in ?? ()
Cannot access memory at address 0x1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x76fdf000 (LWP 1433)):
Cannot access memory at address 0x3
#0  0x76ec9ef8 in __libc_waitpid (pid=1438, stat_loc=0x7ed63d80, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x000c0ba4 in ?? ()
Cannot access memory at address 0x3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Aborted

Does anyone know where to get the source for the Linux Metro app? Who ever wrote the USC control libs didnt bother commenting much and didnt put any method headers in (really bad practice) so I am having problems figuring out how to use them. Im hoping I can reverse engineer how to make the metro 18 work from the control center app code. I cant believe they advertise the great programming support on this product and turn around and provide such poor documentation on the underlying control lib.

iHover · March 27, 2017, 11:17pm

I cant get the Linux - metro app to run but I have been able to get the USC example apps to run in mono.
They connect but nothing happens. the servos don’t move. The green LED blinks when connected so Im assuming commands are making it to the metro 18
Ive tried several different servos of different types and noting seems top happen. Im powering the servos with a wall wart thats supplying 5 volts on the metros terminal. I can see that 5 volts are coming across the servo connections on the metro

I wish they included a straight forward console example application or at least took the time to comment the methods on the USC exaplme lib. I cant figure anything out from the examples. I wasted an hour messing with one example that was included that didn’t even apply to my controller.

iHover · March 27, 2017, 10:54pm

UpDate, Advanced example now runs on my raspberry PI 3. Since the Linux Meastro Control center application wouldn’t run I installed the drivers and software on my windows laptop. As soon as the control center tried moving a servo it prompted me to change the baud rate on the Meastro board. It worked in windows. Going back to the Raspberry PI after that the Advanced example did move the servo. I still cant run the control center on the raspberry though.

DavidEGrayson · March 27, 2017, 11:55pm

Hello.

I merged two of your topics into one because there was a lot of overlap in the things you were talking about.

I am sorry you are having trouble controlling your Mini Maestro 18-Channel USB Servo Controller from your Raspberry Pi 3.

I wish they included a straight forward console example application

Have you seen the source code for UscCmd in the Pololu USB SDK? UscCmd is a small console application that would probably work for you. You can run it with no arguments or look in the source code to see what options it supports. The most important option is probably --servo, which allows you to move servos from the command line. For example, to set the target of channel 3 to 1500 microseconds, you could run:

./UscCmd --servo 3,6000

Unfortunately, the Maestro Control Center does not work on ARM-based Linux machines like the Raspberry Pi. For more information, see the “Supported Operating Systems” section of the Maestro user’s guide.

We do not provide the source code for Maestro Control Center, but we can answer questions about how the Maestro’s USB interface works, so you will not need to reverse engineer anything.

If you have further questions, please let me know.

–David

iHover · March 28, 2017, 12:57am

Dave thanks for the quick response.
I missed the note on ARM-based Linux and Maestro Control Center.
You might want to make a note somewhere in the Doc’s or site for
ARM-based Linux to first hookup and run the board on windows in order to
reset the default baud rate. that’s what caused my initial issue. As
soon as I attempted to move a servo Maestro Control Center told me that
the baud rate needed to be changed and just did it. The UscCmd source
is little help its as poorly documented as the Usc code. I think Ill
work on replicating the Maestro Control Center for the ARM that should
hit most if not all the methods in Usc and Ill add proper method headers
as I go. Its a shame the folks that wrote it didn’t take the time. Im a
senior programmer analyst with a small team , Id never let anything
forward facing roll out of my shop like that. Ill post questions on
the forum as needed.

Thanks
Brian Grant