It would be great if we could acquire a Robotics Cape as soon as possible but since it doesn't seem possible yet, why not add a Mailing List or a Contact Me page so that we can subscribe and know when the cape is available?

Also, couldn't find any contact/email on the website...

Thanks

Beagle Bone Green Wireless has pin conflicts. I believe its reasonable to patch the code to detect BBGW and remove the 2 Encoders as most wheeled robot minus Mecanum drive configs use only two encoders.

Would need to drop the support in battery monitor for Batt LED1 and Batt LED2.

Assume would also need a way to flag the PRU code so not to access the PRU encoder pins code if BBGW.

Would need to edit the overlay to disable exclusive use.

Conflict Pins that I found are as follows
p8 Pins BBWG Robotics Cap
11 WL_SDIO_D1 QEB2B
12 WL_SDIO_D0 QEB2A
15 WL_SDIO_D3 PRU ENC A
16 WL_SDIO_D2 PRU ENC B
17 WL_IRQ BATT LED 1
18 WL_SDIO_CLK BATT LED2

Documentation currently says rc_get_battery_voltage and rc_get_dc_jack_voltage at http://www.strawsondesign.com/#!manual-adc.

Within file "rc_filter.c", within functions "rc_prefill_filter_inputs" and "rc_prefill_filter_outputs".

The number of array elements is one greater than the order of the system, so both these function fail to assign the last value within each array.

Current code:
for(i=0;iorder;i++)

Revised code:
for(i=0;i<=f->order;i++)

Alternative revision:
for(i=0;iorder+1;i++)

Just received my BBBlue , upgraded the robotic cape and I connected this Motor & Encoder:
https://www.banggood.com/6V-210RPM-Encoder-Motor-DC-Gear-Motor-with-Mounting-Bracket-and-Wheel-p-1044064.html?rmmds=buy

Testing with rc_test_encoders and when turning the wheel manually, the display shows a persistent error between CW and CCW readings.
Example:
Manually slowly turning the wheel CW 1/4 turn = its counting up to 180
Manually slowly turning the wheel CCW 1/4 turn = its counting down to -90
Same pattern on both motors-encoders.
I swapped phases , No changes

I am available for further tests

Just an update , I trid on channel 4 with the PRU == Same problem

Same error on Arduino = Closing issue

Within file "rc_quaternion.c", and within function "rc_quaternion_to_rotation_matrix".

The calculation for the direction cosine matrix is incorrect. The upper and lower triangles are not pure reflections of one another, and the signs are opposite for the upper triangle.

Current code:
// compute upper triangle
m->d[0][1] = 2.0f * (q.d[1]*q.d[2] - q.d[0]*q.d[3]);
m->d[0][2] = 2.0f * (q.d[1]*q.d[3] + q.d[0]*q.d[2]);
m->d[1][2] = 2.0f * (q.d[2]*q.d[3] - q.d[0]*q.d[1]);
// mirror lower triangle
m->d[1][0] = m->d[0][1];
m->d[2][0] = m->d[0][2];
m->d[2][1] = m->d[1][2];

Revised code:
// compute upper triangle
m->d[0][1] = 2.0f * (q.d[1]*q.d[2] + q.d[0]*q.d[3]);
m->d[0][2] = 2.0f * (q.d[1]*q.d[3] - q.d[0]*q.d[2]);
m->d[1][2] = 2.0f * (q.d[2]*q.d[3] + q.d[0]*q.d[1]);
// compute lower triangle
m->d[1][0] = 2.0f * (q.d[1]*q.d[2] - q.d[0]*q.d[3]);
m->d[2][0] = 2.0f * (q.d[1]*q.d[3] + q.d[0]*q.d[2]);
m->d[2][1] = 2.0f * (q.d[2]*q.d[3] - q.d[0]*q.d[1]);

Within '/libraries/math/rc_matrix.c' concerning function 'rc_matrix_transpose'.

Inputs A.rows and A.cols should be reversed within the line:
"if(unlikely(rc_alloc_matrix(T,A.rows,A.cols))){"

This is also incorrect:
for(i=0;i<(A.rows);i++){
for(j=0;j<(A.cols);j++){
T->d[i][j] = A.d[j][i];
}
}

This won't show up as an error for square matrices, but it is incorrect for non-square matrices. Either switch 'A.rows' with 'A.cols', or switch the variable 'i' with variable 'j', within the loop; whichever is faster.

@StrawsonDesign & @jadonk
Please update the "battery_monitor" to check cat /proc/device-tree/model and definitely blacklist the BeagleBone Green Wireless, (to be safe, only run on the Blue/Blue-cape), as it takes away the IRQ pin we use on the wl18xx, thus breaking wlan0/etc. ;)

[   58.653762] genirq: Failed to request resources for wl18xx (irq 54) on irqchip 44e07000.gpio

https://github.com/StrawsonDesign/Robotics_Cape_Installer/tree/master/battery_monitor_service/battery_monitor

(background: we like to try using one image for all boards, so while battery_monitor is only for the blue/blue cape, it's enabled by default..)

Regards,

In my app I periodically poll the battery and jack voltages. Very, very, occasionally my app will hanging while reading the jack voltage. This is the stack trace (sorry for the limited symbol information):

Thread 1 (Thread 0xb6c9d000 (LWP 5197)):
#0 0xb4c3c3d8 in mmap_adc_read_raw () from /usr/lib/libroboticscape.so
#1 0xb4c4126a in rc_adc_volt () from /usr/lib/libroboticscape.so
#2 0xb4c41304 in rc_dc_jack_voltage () from /usr/lib/libroboticscape.so
#3 0xb4c6dd68 in BBBluePower::JS_jackVoltage(v8::FunctionCallbackInfov8::Value const&)
()
from /root/borgcube-rov/hw/board/beagleboneblue/native/build/Release/beagleboneblue.node
#4 0x00403158 in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfov8::Value const&)) ()
#5 0x0042e290 in ?? ()

I experimented with a few breakpoints and have determined that mmap_adc_read_raw never returns. I see a few while loops in the code which - obviously - should never fail, but it appears that occasionally they do.

Thanks
Tim

The imu state drifts significantly when initializing the imu and leaving the blue at rest.

When running rc_test_dmp or when using a custom program utilizing the robotics cape library, the imu drifts up to 4 degrees a minute while at rest. I have tried changing the imu config for various sampling rates and filters but the drift remains constant.

Previous experience with the MPU9250 in other embedded systems has not shown this drift.

I am trying to use the robotics cape together with ardupilot to be able to use ardupilot's PRU's for PWM and RC receiver. To do that, I am modifying an example from ardupilot, in this case example/Printf which you can find in /libraries/AP_HAL/examples/Printf, and I am trying to put there an example code of the library of rc_test.

Moreover, I copied the libraries folder of the robotics cape into a folder called roboticscape in ardupilots libraries....

I am then including the libraries files in this way...

extern "C"{
#include <roboticscape/rc_usefulincludes.h>
#include <roboticscape/roboticscape.h>
}

I then copied the whole code of rc_test_dmp example into Printf.cpp file (erased the original one totally) and I got this error...

../../libraries/AP_HAL/examples/Printf/Printf.cpp: In function ‘rc_imu_orientation_t orientation_prompt()’:
../../libraries/AP_HAL/examples/Printf/Printf.cpp:192:8: error: invalid conversion from ‘int’ to ‘rc_imu_orientation_t’ [-fpermissive]
return 0;

Why am I getting this error? Isn't this supposed to already compile correctly?

So I removed the return 0 and then I got this other error...

../../libraries/AP_HAL/examples/Printf/Printf.cpp: In function ‘int main(int, char**)’:
../../libraries/AP_HAL/examples/Printf/Printf.cpp:232:8: error: jump to case label [-fpermissive]
case 'm': // magnetometer option
^
compilation terminated due to -Wfatal-errors.

So error after error, I decided to stop testing and ask for help...

Does anyone know why does this happen?

I have already the whole ardupilot base code compiled in my beaglebone blue.... what am I doing wrong?

The assumption that GPIO pins are available should be avoided and the case they aren't available should be handled. Memory mapping GPIO pins may typically still work, but the helper may or may not be available. Pinmux should be checked to see if the pin is in GPIO mode.

root@beaglebone:/var/lib/cloud9# test_motors -d 0.1
gpio/direction: No such file or directory
ERROR: Failed to set gpio pin 66 as output
gpio/direction: No such file or directory
ERROR: Failed to set gpio pin 67 as output
WARNING: Failed to configure all gpio pins
ERROR: failed to configure GPIO
failed to initialize cape

I would like to suggest a modification or option in the pru0 library to be able to identify the CPPM protocol used by many RC receivers. I am not sure weather this is possible using encoder library by itself and I am almost sure it needs a modification. But please, let me know if I missed anything.

Within "quaternion.c", and function "rc_normalize_quaternion", the loop only applies to three of the four quaternion elements.

currently:
for(i=0;i<3;i++) q->d[i]/=len;

revision:
for(i=0;i<4;i++) q->d[i]/=len;

I reset the package back to what the master of Robotic_Cape_Installer is:

rcn-ee/repos@581744a

As you can see we have a nice lockup, that's a BIG no-no... I'll start hacking the install/postinstal/etc..

root@beaglebone:~# apt update ; apt upgrade
Hit http://repos.rcn-ee.com jessie InRelease
Hit http://security.debian.org jessie/updates InRelease                        
Hit http://repos.rcn-ee.com jessie InRelease                                   
Hit https://deb.nodesource.com jessie InRelease                                
Ign http://httpredir.debian.org jessie InRelease                               
Get:1 http://repos.rcn-ee.com jessie/main armhf Packages [812 kB]              
Hit http://httpredir.debian.org jessie-updates InRelease                       
Hit http://httpredir.debian.org jessie Release.gpg                             
Hit http://httpredir.debian.org jessie Release              
Get:2 http://security.debian.org jessie/updates/main armhf Packages [421 kB]   
Get:3 http://security.debian.org jessie/updates/contrib armhf Packages [994 B] 
Get:4 http://security.debian.org jessie/updates/non-free armhf Packages [20 B] 
Get:5 http://repos.rcn-ee.com jessie/main armhf Packages [6,723 B]     
Get:6 https://deb.nodesource.com jessie/main armhf Packages [967 B]         
Get:7 http://httpredir.debian.org jessie-updates/main armhf Packages [17.6 kB]
Get:8 http://httpredir.debian.org jessie-updates/contrib armhf Packages [20 B] 
Package configuration


 ┌───────────────────────┤ Configuring roboticscape ├────────────────────────┐
 │ Please select a program to run on boot. The default value is 'rc_blink'   │
 │ which will flash the green and red LEDs on boot to indicate all if        │
 │ working. For BeagleMiP select 'rc_balance'. If you have your own          │
 │ roboticscape project set to run on boot and wish to leave it alone then   │
 │ select existing. To do nothing on boot select 'none'.                     │
 │                                                                           │
 │ Which program to run on boot?                                             │
 │                                                                           │
 │                                rc_blink                                   │
 │                                rc_balance                                 │
 │                                existing                                   │
 │                                none                                       │
 │                                                                           │
 │                                                                           │
 │                                  <Ok>                                     │
 │                                                                           │
 └───────────────────────────────────────────────────────────────────────────┘


(Reading database ... 37989 files and directories currently installed.)        
Preparing to unpack .../roboticscape_0.3.1-git20170205-0rcnee0~bpo80+20170206+1_armhf.deb ...
Removed /etc/systemd/system/multi-user.target.wants/battery_monitor.service.
Unpacking roboticscape (0.3.1-git20170205-0rcnee0~bpo80+20170206+1) over (0.2.2-git20161122-0rcnee9~bpo80+20161219+1) ...
Uninstallation Complete
Setting up roboticscape (0.3.1-git20170205-0rcnee0~bpo80+20170206+1) ...
user selected none
systemctl daemon-reload
Enabling roboticscape Service
Created symlink /etc/systemd/system/multi-user.target.wants/roboticscape.service → /lib/systemd/system/roboticscape.service.
Enabling rc_battery_monitor Service
Created symlink /etc/systemd/system/multi-user.target.wants/rc_battery_monitor.service → /lib/systemd/system/rc_battery_monitor.service.
Starting rc_battery_monitor Service
Configuring Device Tree
WARNING, roboticscape library only designed to work with Black, Black wireless, and Blue
At your own risk, you can try the normal BB Black RoboticsCape device tree.

Progress: [ 66%] [#######################################...................]

Regards,

Right now installing the deb package prompts the user for which program to start on boot, then enables the two systemd services and sets the RC device tree to load in uEnv.txt. In light of this now being part of the default image, these default actions are probably not suitable. Perhaps instead the post-inst script should give the user the option to skip these steps if they are not interested. Already the two systemd services won't run if the robotics cape device tree isn't loaded, but it is set to load by default if the package is loaded.

who can help me?
debian@beaglebone:/$ rc_balance
Inner Loop controller D1:
order: 2
timestep dt: 0.0100
-4.9450z虏 + 8.8620z + -3.9670

1.0000z虏 + -1.4810z + 0.4812

Outer Loop controller D2:
order: 2
timestep dt: 0.0100
0.1886z虏 + -0.3721z + 0.1835

1.0000z虏 + -1.8605z + 0.8605

Hold your MIP upright to begin balancing

dsm Calibration File Doesn't Exist Yet
Run calibrate_dsm example to create one
Using default values for now

RUNNING: Hold upright to balance.
胃 | 胃_ref | 蠁 | 蠁_ref | 纬 | D1_u | D3_u | vBatt |arm_state|
0.216 | 0.000 | 0.213 | 0.000 | 0.006 | 1.000 | -0.008 | 8.603 | ARMED |inner loop controller saturated
0.362 | 0.025 | 0.359 | 0.000 | 0.006 | 1.000 | -0.008 | 8.613 |DISARMED |

the project version is 0.3.4. I execute the rc_test_motors -d0.5.the two motors can run as usual.
I may think if it is the PID date is not confihuration.who can help me.

It would be nice to be able to have multiple processes (not just threads of the same process) that can interact with the hardware using the RC libraries. This would be useful in systems where process level fault-mitigation strategies (such as restarting processes) allow for greater separation and componentization of code. The same can be true for distributed systems process migration.

Hi,
I'm trying to start a project on the bbblue. I'm compiling on it directly.

At last, to make it easy, I try to compile the project through gcc/g++.

In the same directory, I have the main:

#include "rc_usefulincludes.h"
#include "roboticscape.h"
int main(){
	rc_initialize();
}

And : libroboticscape.so, rc_usefulincludes.h,roboticscape.h

I do try this:
gcc -g -o binary -lroboticscape main.cpp
and this is what happens:

In file included from main.cpp:6:0:
libraries/rc_usefulincludes.h:15:0: warning: "_GNU_SOURCE" redefined
 #define _GNU_SOURCE  // to enable macros in pthread
 ^
<command-line>:0:0: note: this is the location of the previous definition
/tmp/cc7mQL20.o: In function `main':
/home/debian/robot/main.cpp:14: undefined reference to `rc_initialize()'
collect2: error: ld returned 1 exit status

I'm a bit annoyed, at first because I don't like warnings, but also because, I checked, and rc_initialize is really in libroboticscape.so.

How can I compile in command line?
Do you know the other place where the define is defined? (where should I remove it?)

When running rc_test_dmp on the beaglebone blue, it seems the calculations for the heading are wrong.
If the beaglebone's heading is kept at a fixed position and then the board is rolled, the heading will start increasing or decreasing.

Within file "rc_filter.c", within function "rc_alloc_filter_from_arrays".

Both the arrays for numerator and denominator initialize to the same length, no matter what is passed into the function. The problem is that some functions will later require the relative degree of the transfer function to work properly. But if the TF is formed with this function, it will always have a relative degree of exactly zero, which is not always accurate.

Current code:
if(unlikely(rc_vector_from_array(&f->num,num,order+1))){
fprintf(stderr,"ERROR in rc_alloc_filter_from_arrays, failed to alloc vector\n");
return -1;
}
if(unlikely(rc_vector_from_array(&f->den,den,order+1))){
fprintf(stderr,"ERROR in rc_alloc_filter_from_arrays, failed to alloc vector\n");
rc_free_vector(&f->num);
return -1;
}

Several functions make use of temporary matrix structs, without freeing the memory. They all have conditional statements to free the memory upon an error, but best practice should also clear that memory for cases without errors. This happens in the following function calls within "/libraries/math/rc_matrix.c":
rc_left_multiply_matrix_inplace;
rc_right_multiply_matrix_inplace;
rc_matrix_transpose_inplace.

Within '/libraries/math/rc_vector.c' concerning function 'rc_vector_outer_product'.

    for( j=0; j<v2.len; j++ ) {
            for( i=0; i<v1.len; i++ ) {
                    A->d[j][i] = v1.d[i] * v2.d[j];    // Should be "A->d[i][j]"
            }
    }

Within "quaternion.c", and within function "rc_normalize_quaternion_array", the for loops only apply to the first three elements within the quaternion.

currently:
for(i=0;i<3;i++) sum+=q[i]*q[i];
for(i=0;i<3;i++) q[i]=q[i]/len;
revision:
for(i=0;i<4;i++) sum+=q[i]*q[i];
for(i=0;i<4;i++) q[i]=q[i]/len;

At beginning of initialize cape, can you add a line to set the state to uninitialized.

rc_balance out of box fails to arm controller. and thus, won't balance.

The template should build out-of-the-box.

"echo 4a334000.pru0 > /sys/bus/platform/drivers/pru-rproc/unbind" returns "Unknown Device"

Within rc_matrix.c, in functions rc_left/right_multiply_matrix_inplace():
Because these two functions only work on square matrices, there should be some minor error checking, to confirm that both matrices A and B are square, and that they both share common dimensions.

Missed one: https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/examples/rc_test_buttons/Makefile#L3

Power_off IMU not needed, at least shutting down the imu threads when they haven't started. I get a seg fault on power_off_imu since the imbue threads don't exist.

I've been seeing some strange magnetometer data coming out of the robotics cape library and my BB Blue. Here is a snippet of a log I took, which is just the "mag" field array within the "imu_data_t" structure. The recording is of one slow 360 degree spin (x axis is in seconds).

The X-Direction seems to be behaving, Y is ~0 (not actually zero) and Z is nonsense. Perhaps the wrong bytes are being parsed from the i2c read?

I started investigating this when I noticed the fused yaw angle was becoming unstable, which using magnetometer heading to correct for gyro drift. Has anyone else seen similar behavior?

Continuing on configuring dcan as in #48 , it appears that dcanRX is not configured to read properly.

I connected the blue to a pre-existing can bus and viewed its output with a logic analyzer.

After configuring can0 to the proper bitrate, running candump can0 -L on the blue produces no data, even though traffic was seen on the logic analyzer.

WIth can0 configured with no loopback, writing to the bus fails, as shown below.

After enabling loopback, the blue can successfully write to the bus:

But it follows no arbitration and will write even if the bus is already in use. When the bus then goes to an error state, it ignores it and continues to write.

This is fairly consistent with no actual RX feedback, even though the logic analyzer tied to the RX and TX pins on the blue show proper connection.

Within rc_vector.c file, in function "rc_std_dev()"
the calculation for standard deviation should have "N-1" in the denominator prior to taking the square root.

return sqrt(mean_sqr/((float)v.len-1.0f));

Instructions on this page

http://www.strawsondesign.com/#!manual-pwm

State to use the pinmux API to reconfigure UART1_HEADER_PIN_3 and UART1_HEADER_PIN_4 to mode PINMUX_PWM.

PWM channel 0 is actually on pins GPS_HEADER_PIN_3 and GPS_HEADER_PIN_4

I would like to suggest the Servo/ESC functions to be modified so that they can generate pulses of certain length and certain frequency and not just one pulse of certain length.

As it is said in the library, ESCs and even digital servos allow update rates of up to 400 Hz. However, you don't give a way to define this frequency INDEPENDENTLY of whatever you are running in your main program.

Your function rc_test_servos uses function rc_usleep to achieve the update rate, but what if you don't wanna have to be updating at 400 Hz on the main loop? Clearly you want to be updating as fast as you can to overcome the filtering of ESCs which you can see here (https://www.rcgroups.com/forums/showthread.php?1250488-ESC-Response-Testing). However, that doesn't mean that you necessarily need to be taking decisions at the same rate. If your main loop is running at 50 Hz, the difference in the update rate can have a significant impact on the flight performance.

This could also be achieved by "timer interrupts" but since I am noob on linux I still don't know how to implement them in the beaglebone blue.

show_temp isn't used inside of print_data.

More of a suggestion...
It would be helpful if all the functions within a single file has a similar prefix. I would suggest that you adopt a naming convention that always begins with "rc_vector_" and then append the specifics to remainder of the function name. That when, when coding, you don't have to look up the specific syntax of a function. Here are the suggested revisions to the offending functions:

rc_vector_alloc
rc_vector_free
rc_vector_empty
rc_vector_random
rc_vector_duplicate
rc_vector_set_entry
rc_vector_get_entry
rc_vector_print
rc_vector_print_sci
rc_vector_std_dev

I have no battery connected, but running the battery monitor on Beaglebone Blue indicates a compatibility problem:

root@beaglebone:~# uname -a
Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux
root@beaglebone:~# rc_battery_monitor
gpio/direction: No such file or directory
gpio/direction: No such file or directory
gpio/direction: No such file or directory
gpio/direction: No such file or directory

2S Pack   Jack   #Cells   Cell
 0.40V   0.00V   0       0.00V

Unless I am missing something, it does not seem that the CAN bus can be fully set up at this time.

Device: Blue

Kernel: 4.4.39-ti-r75

rc version: 0.3.4

Looking at BB-DCAN1-00A0.dts we see the following two fragments required for setting up CAN1 if we did not have the robotics cape library installed

/dts-v1/;
/plugin/;
 
/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";
 
    /* identification */
    part-number = "dcan1pinmux";
 
    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            dcan1_pins_s0: dcan1_pins_s0 {
                pinctrl-single,pins = <
                    0x180 0x12  /* d_can1_tx, SLEWCTRL_FAST | INPUT_PULLUP | MODE2 */
                    0x184 0x32  /* d_can1_rx, SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */
                >;
            };
        };
    };
 
    fragment@1 {
        target = <&dcan1>;
        __overlay__ {
             #address-cells = <1>;
             #size-cells = <0>;
 
             status = "okay";
             pinctrl-names = "default";
             pinctrl-0 = <&dcan1_pins_s0>;
        };
    };
};

fragment@0 is responsible for setting the pin mux and can be handled readily either by using the robotic's cape built in pinmux functions

rc_set_pinmux_mode(UART1_HEADER_PIN_3, PINMUX_CAN);
rc_set_pinmux_mode(UART1_HEADER_PIN_4, PINMUX_CAN);

or by directly setting the state of the pins in the file system

echo can > /sys/devices/platform/ocp/ocp\:P9_24_pinmux/state 
echo can > /sys/devices/platform/ocp/ocp\:P9_26_pinmux/state 

But I do not currently see a way to perform the function of fragment@1 to enable the CAN device after setting up the pinmux.

Within file 'rc_quaternion.c', within function "rc_quaternion_multiply_array", the dimension of the two for loops needs to be changed.

Current:
for(i=0;i<3;i++){
c[i]=0.0f;
for(j=0;j<3;j++) c[i]+=tmp[i][j]*b[j];
}
Revision:
for(i=0;i<4;i++){
c[i]=0.0f;
for(j=0;j<4;j++) c[i]+=tmp[i][j]*b[j];
}