mirkix / bbbmini Goto Github PK

I was wondering if there was anyway you would be able to provide the kernel source/headers as a .deb? I need to build wifi drivers for my 80211ac adapter.

I have also recently built gstreamer 1.4.5 on my beaglebone black and have been playing around with streaming. Have you had any experience with this and do you think the beaglebone could handle this and ardupilot? I am using a logitech c920 so the camera does all the grunt of video encoding.

http://docs.emlid.com/Navio-APM/video-streaming/
I was able to stream video to my android phone using the apk provided here. Might be interesting to use this application in conjunction with google cardboard or modified for cardboard for fpv.

Also if you have not mailed the pcb I can pay to have it expedited as I would love to get my hands on it.

Hi,

after try this last tutorial, the PRU Compiler is missing

Mirko,
I was looking at the pdf for the bbbmini schematic and noticed the resistors that were attached to rc input. Is this to act as a logic level shifter? How should i go about using connecting a receiver to a 1.2 board?

Hi,

I'm updating my SD card and I found an issue on software wiki.
Is missing git submodule update to update modules folder - without that submodule folder are empty and waf is not available.

Hello Denecke;
Thanks for sharing your interesting project. I have one question about Linux embedded programming. How do you handle hard interrupt? For Example external interrupt that comes from MPU-9250:
1- By Polling GPIO in Linux user space (c code and thread)
2- By using PRU (poll GPIO and send soft interrupt to Linux USER SPACE)
3- Linux Kernel Programming (Which support hard interrupt)
Or we can do it in RT-Linux by programing USER SPACE
Yours Sincerely,
Rostami;

Hi all,

installed ArduPlane-3.7.1 and Mission Planner 1.3.43. After syncing through Mavlink there is no Full Parameter list page in Mission Planner. Whole installation and setup was done from the tutorial (https://github.com/mirkix/BBBMINI/blob/master/doc/software/software.md).

Can you add a section to the software area that deals with building the pru firmware and loading the proper overlay with the 4.0 kernel. I have updated my kernel from your image but seem to be having issues with the overlay loading and the pru's working.

I have been looking at the startup.sh located in the bbbmini directory for the device tree's. I have noticed that unlike the pxf or the startup.sh located under linux_hal_essentials that it does not initialize the pru. So at this point I am lost. with the startup.sh under the bbbmini the pru isnt initialized nor is the firmware loaded for them.

Hi all,

I am trying to connect Xbee Pro S3B to Mission Planner. What I have achieved is to connect and verify that it all works through Minicom at baudrate of 57600. I can send data in both ways and all works fine. If I try to connect arduplane to Mission Planner it doesn't work.
Command used is: ./arduplane -C /dev/ttyO4 and that same command works with Prolific USB ttl serial module without any issue. Is there some modification in the code that needs to be done to make Xbee work.

Hi all,

I have a problem with an unstable bbbmini quad. Flipping upside-down both starting from ground or launching by hand.

The hardware configuration is:

• Frame - Tarot TL300A
• Motor - MultiStar 2206 Baby Beast
• Prop - 5040 Multirotor ABS
• ESC - Afro 12A OPTO V3
• Flight Control - BBB + bbbmini
• Battery - Turnigy nano-tech 1300mAh 3S 45
• UBEC - HKU5 5V/5A
• RX Receiver - X8 R6M 6Ch Micro 2.4GHz Assan
• TX Transmitter - JR BX8103A

About software:

I followed exactly the steps list on the website (https://github.com/mirkix/BBBMINI/blob/master/doc/software/software.md)
both, compiling and downloading the 3.3 ArduCopter.elf version.
(from http://firmware.bbbmini.com/ArduCopter.elf)

More or less I've got the same results: No way to fly the copter !

Please notice that I had to modify the parameters, due to my TX:

• RCMAP_PITCH = 3
• RCMAP_ROLL = 2
• RCMAP_THROTTLE = 1
• RCMAP_YAW = 4

The sensations, holding the copter in stabilized mode hanging from my hand, are:

1. Pitch and Roll were exchanged (acting Pitch on the transmitter, made Roll action on drone) even if the representation on the Radio Calibration screen is correct after RCMAP (Pitch with Pitch etc...)
2. Not using transmitter (just mid throttle), stabilizer reaction to manual solicitation was not correct (not equal and contrary to the cause, to keep it stable).

My supposition is that motors are acting in wrong order...
But they are correctly connected !!! No way to go wrong on BBBMINI Printed Board. (They all push up!)

Maybe RC-IN reader piece of code, RCInput_AioPRU.cpp, doesn't handle RCMAP channel substitution ?
Or something else down the line of signal management and motor control?

I'm suspecting of RCMAP because it's the only modification that I made, comparing with standard procedure...
Am I the only one who is trying to use RCMAP channels substitution with bbbmini? (I really cannot change channel number in the TX, only reverse)

What do you thing? Any idea?

Thanks and bye,
Enrico.

so I have this gps, https://goo.gl/photos/A2TdszUf7XFuapvy7, how do you recommend I connect it to the cape? Will there be any revisions that will support standard connections?

Hi,

I'm trying to run Arducopter following the BBB Mini software, but if I try to run any test software or arducopter I'm receiving this segment fault

(gdb) run
Starting program: /home/debian/ardupilot/libraries/AP_InertialSensor/examples/INS_generic/INS_generic.elf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000140e2 in Linux::LinuxI2CDriver::LinuxI2CDriver (this=0x33690 , semaphore=, device=)
at /home/debian/ardupilot/libraries/AP_HAL_Linux/I2CDriver.cpp:36
36 hal.scheduler->panic("I2C device is not a chardev node");

Any clue ?

Regards

Hi @mirkix ,

First of all congratulations for this project, nice work!!!

So i'm trying it with a different platform, i'm using a hexarotor. And so far i successfully got working the IMU MPU9250, Baro MS5611, the GPS Neo-m8 ublox. For the receiver i'm using an FRsky X8R connected to RC_in in the define BBB pins. The FRsky X8R operate with SBUS protocol, it is tested and working. I have also tested the RC_out, and all 6 motors are operating correctly. For last i had configure the APM planner to communicate with the BBB using wireless network.

Basically the issue is, after launch ArduCopter.elf, when i try to throttle or send other commands in the radio, the motors don't respond to any of them. In the APM planner i can see in the "Radio Calibration" section, the radio commands work fine (roll, throttle, pitch, yaw) as well in the "FailSafe" section in "Radio In" column. But in the "Motor Out" column the corresponding outputs bars remain static. Do you have any clue of the problem is? (or as I have recently start to explore the Ardupilot code, probably could be any configuration i'm missing)

Can you provide higher resolution pictures of the front and the back of your cape? how are you powering the beaglebone black? Is it being powered by a esc?

Hi,
anyone is trying to compile on beagle the new master version?
I'm getting this error
Waf: Entering directory `/root/ardupilot/build/bbbmini'
[1250/1277] Compiling ArduPlane/GCS_Mavlink.cpp
../../ArduPlane/GCS_Mavlink.cpp: In member function 'void Plane::send_extended_status1(mavlink_channel_t)':
../../ArduPlane/GCS_Mavlink.cpp:154:36: error: 'MAV_SYS_STATUS_REVERSE_MOTOR' was not declared in this scope
control_sensors_present |= MAV_SYS_STATUS_REVERSE_MOTOR;
^
compilation terminated due to -Wfatal-errors.

But cross compiling is working fine.

i see PWM_FREQ_DEFAULT is 50 hz ，may i chenge it to 300 or 400 and so on.

but i see it no possobal.can you re write the aiopru.

debian@beaglebone:~$ ls
antennatracker  arducopter  arducopter-heli  arduplane  ardurover  ardusub  bin
debian@beaglebone:~$ ./ardusub 
./ardusub: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.27' not found (required by ./ardusub)

Crosscompile master computer runs on Ubuntu 18.04.

I am not sure why i have to calibrate my compass every time i try to fly and half the time i cant get it to work properly. Is the resistor on the board for the compass? or is that for the canbus items? I am just not sure why i am forced to constantly re-calibrate the compass when i want to fly. BTW when it is calibrated it flies well. I need to do some tuning and get some fpv going with an android application. But after looking at how far I was able to get it I am wondering how to handle long range wifi.

Hi All,

one question - it's not clear to me until now is about the receiver.
What kind of receiver can be used? PPM or PWM will work? On the board there are one RC_Input with Voltage Divider and another 3 inputs with X_Quad name and I couldn't figured out what is the purpose.

Regards

Hello,

When following the instructions on the build on the software installation I get the following:

Unpacking linux-image-4.4.73-bone-rt-r18 (1jessie) ... Setting up linux-image-4.4.73-bone-rt-r18 (1jessie) ... update-initramfs: Generating /boot/initrd.img-4.4.73-bone-rt-r18 cp: cannot stat '/etc/modprobe.d/*': No such file or directory zz-uenv_txt: Updating /boot/uEnv.txt [uname_r=4.4.73-bone-rt-r18]

This also happened when I was doing the upgrade. The BBB seems to reboot and work fine, but I am not sure what exactly is causing this issue. The /etc/modprobe.d exits.

Thanks,

This was such a lovely project and I built one of these myself! I request you to tell me which libraries you used and provide me any that you wrote yourself for the sensors, RC, UART etc. I have been hunting everywhere for them and I have only found your PRU firmware on hackster.io

I have gotten my quad together and the beaglebone black is working fine. I however have not been able to fly yet due to it flipping. I am not sure if I have something wired wrong with the motors but everything should be fine. If there is anything you can suggest that would help. I will probably make a video to show whats happening.

The kernel you reference to is outdated and leads to certificate errors. Choosing another kernel leads to endless problems with devicetrees and your BBBMini cape. Please update your repository as it is still a cool project!

Hi, great project. I am currently implementing this using a begalbone black, mounted with a cape. I have followed the instructions provided on the BBBmini github page to download, configure and build the kernel and also the arducopter firmware. I am using the 4.0.6 version. My ESCs are from readytosky 30A (https://robu.in/product/readytosky-30a-2-6s-esc/) used with a 3s lipo. Here is the problem I am facing, on calibirating the ESCs manually, using my sbus based receiver, I achieve a consistent speed of 5000rpm on all my motors when the transmitter throttle is set to 50%. My motors can spin upto 10000 rpm. When the ESCs are plugged back to the begalbone black cape, following the diagram on the github page, the motors spin with different rpms. The difference in the RPM is usually around 2000-3000, sometimes more than 4000 rpm. Can you point out potential issues that can be causing this? My calibration sequence is the one mentioned in the ardupilot website. I have tried manual, all at once and semi automatic sequence but nothing seems to solve the problem.

I specifically will be taking my first flight in gas plane and will need to operate at least 4 servos. These are futaba fp-s148 servos. I see that they can operate between 5v and 6v. How would you recommend routing power? I understand you plan on powering the beaglebone black itself through a 5v ubec would you also use this source and just connect the servos to it as well? I know with a quadcopter this is not so much of an issue as you only need to provide ground and signal to the escs.

i have some questions. I have purchased this, http://www.ebay.com/itm/141729072661, power module to power my beaglebone black. I purchased it due to the fact that it does battery measurement and current sensing. Can this be made to be used with bbbmini?

Hi,

I am trying to run it in the Beaglebone Blue... I tried using the image provided in (https://github.com/mirkix/ardupilotblue) and at first it ran correctly but then it gave an error of No INS backend available.

I am having the following error

root@beaglebone:/home/debian# /home/debian/arducopter -C udp:192.168.137.1:14550
SPI: unable to open SPI bus /dev/spidev2.1: No such file or directory

I checked the /dev folder and spidev2.1 is not there,

I would assume is just a matter of changing it but I am thinking maybe I missed something. I ran all the steps in (https://github.com/mirkix/BBBMINI/blob/master/doc/software/software.md).

Any suggestions?

Regards,
Oscar

I am constantly plagued with issues related to the compass. I have tried calibrating my compass for the last 3 days. I get errors with compass variance and am unable to arm because of this.I have a new zmr250 carbon fiber frame with pdb. I thought initially it was the carbon fiber on the top plate causing issues but it didn't change things with it removed. I have this issue with two 1.0 boards I have

I dd'ed the latest image to a microsd card and rebuilt everything. Now when I try to run any of the test programs or even try to start arducopter.

I get this error:
debian@arm:~/ardupilot/ArduCopter$ sudo ./ArduCopter.elf
RCOutputAioPRU.cpp:SIGBUS error gernerated

Any ideas?
And if you needed me to provide postage for the pcb let me know. I am eagerly awaiting to try it out. it looks tons better than my birdnest.

Used the latest beaglebone black image and grabbing arducopter and compiling on debian leaves me with this error when attempting to start ardupilot. I have verified as well that the dtb is being loaded initially.

this is what i see in dmesg

[ 2104.096701] Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fe2000 [ 2104.096707] pgd = dc308000 [ 2104.096717] [b6fe2000] *pgd=9c354831, *pte=4a324343, *ppte=4a324833 [ 2112.307359] Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fd6000 [ 2112.307365] pgd = dcd38000 [ 2112.307376] [b6fd6000] *pgd=9c451831, *pte=4a324343, *ppte=4a324833 [ 2116.818783] Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fe8000 [ 2116.818789] pgd = dcf40000 [ 2116.818799] [b6fe8000] *pgd=9cd64831, *pte=4a324343, *ppte=4a324833 [ 2530.019735] Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6f80000 [ 2530.019740] pgd = ddc64000 [ 2530.019751] [b6f80000] *pgd=9c406831, *pte=4a324343, *ppte=4a324833

RCOutputAioPRU.cpp:SIGBUS error gernerated

Flashing is much faster if you use 'bmaptool' if you are flashing from a Linux host, rather than using 'dd'. Robert publishes .bmap files.

Rather than using a replacement .dtb, I recommend using a .dtbo and using the 4.1 kernel. You can use the /opt/scripts/tools/update_kernel.sh script that is on the image (https://github.com/RobertCNelson/boot-scripts/blob/master/tools/update_kernel.sh).

See http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#4.1.x-ti_BeagleBone.2FBeagleBone_Black.2FBeagleBoard-X15_.2B_RT for the flags to pass /opt/scripts/tools/update_kernel.sh.

I used:

sudo apt-get update
sudo apt-get install -y lsb-release
sudo /opt/scripts/tools/update_kernel.sh --ti-rt-channel --testing

I just used a newer console flasher, rather than doing 'sudo apt-get upgrade'. I find using 'sudo apt-get upgrade' removes the usefulness of telling people to grab a particular image because it is unpredictable what might break. Doing the 'update_kernel.sh' script, rather than specifying a version, also adds some unpredictability, but at least I know that is coming from the BeagleBoard.org community, rather than Debian at large.

Hi, i have done a fresh installation following the all the steps in software section, but when i'm try to run a simple test (RCOutput.elf) to check the output to the motors, but sometimes the motors start to spin, and other times they simple start to beep more fast, without spin the motors. When i run the main routine (arducopter-hexa) the behavior is the same just beeping. It seems to be a problem in the pwm signal or the pru that isn't active. His there any test to check what is the issue?

In using a hexacopter, with the bbbmini pcb rev.1.4, and DJI 2212 930kv motors and the E300 ESC's.