Hi everyone! I’m new to both ArduPilot and the BeagleBone Blue, so I’ll apologize in advance for my noob questions and rather lengthy post.
Backstory:
I’m putting together a rather unorthodox plane as my second foray into RC flying, and my first foray into ArduPilot.
(Here’s a quick picture I drew up, just so y’all know what I’m talking about:)
Basically I just repurposed spare parts from my first airplane to make this one, as well as buying quite a bit of new hardware for all the extra features.
My three requirements for the plane are simple, yet complicated at the same time. I need good, stable flight down to quite slow speeds (hence the double-main-wing design for extra lift), I need VTOL/hover capability (hence the quadcopter rotors embedded in the wings), and I need it to be a true airplane, not a quadcopter. Hopefully these three things will make it a very easy plane to learn RC flying on, as I can just go slow/stop outright to give myself more time to react.
Here’s my issue though. I can’t use Y-harnesses (reducing the number of servos I have to control) on either main wing without losing the ability to run the wing control surfaces in “elevon mode”, which is an ability that I want to keep. So, I’ve got 5 brushless motors (and therefore ESCs) and 5 servos to control. That’s a total of 10 devices, and the BeagleBone only has 8 servo outputs… And here we have my problem. Since all problems are best fixed in software , we arrive at my question.
Question:
Can the 2-pin DC motor output ports (located on the short edge of the board, away from the USB port) be repurposed as additional servo control ports? My understanding is that both types of ports are simply using different flavors of PWM, so I thought repurposing them might be possible. If it is possible to repurpose the ports, could someone point me in the direction of instructions on how to do it?
There are eight channel and 16 channel receivers, like the X8R from FrSky when coupled, that can handle many different brushless motors along w/ the required ESCs. I know your system will need dc, servo, and bldc b/c of the lack of using your Servo Header on the BBBlue for all motors.
…
I think you can do it with i2c or with another technology. Maybe making a small i2c kit may prove valuable. Anyway, let me know what you think about what I have typed here and we can review other ideas further.
The PRU onboard the BBBlue is handled by the Receiver and those four DC motor connectors can have a DC motor per connector connection. So, four DC motors and four DC motor connectors. There are plenty of Servos that be added to the Servo Header.
There are the quadrature encoders too. B/c of the PRU being used up with SBus on, like w/ the X8R receiver, a single pin, maybe three quad. encoders can still be used w/ another form of source outside of ardupilot/arduplane/arducopter or whatever you are using to make it work.
For instance, there are a couple of libraries out there for the BBBlue and bbb.io boards in general.
Seth
P.S. Oh and about that repurposing DC motor connections into Servo motor connections, maybe. Just maybe. I think there are H-Bridge drivers onboard the BBBlue for making DC motors move…Servo Drivers are a bit different. AOZ1284 is the servo chip and the H-Bridges for the DC motors are TB6612FNG. I am sure there is a way but I cannot tell just yet. One reason I cannot tell is b/c I do not fully understand both schematics of the chips, the datasheets, and how to incorporate a middle driver to make things work there and back. But, I found onboard the BBBlue many GPIO pins (GP0 and GP1) and an i2c pin (I2C1). Complicated…yes. Doable…maybe. Receiving knowledge on how to go about it…priceless. Let me know.
I am sure there are chips that handle exactly what you are describing. I am unaware of them off hand but I can review the idea in time and keep replying. Give updates and I will return service when I find out more.
Seth
P.S. I found some nice info. here: https://www.nxp.com/docs/en/application-note/AN4776.pdf. Further down in the article, there is a section called 4.1. Try that idea out, i.e. read it and get back to me. I am sure you already know this info. but it is a good recapture of ideas. Hall Sensors!
Okay so, I figured out what to do but I do not think that the two H-Bridge drivers on the BBBlue can handle more than two or maybe just one BLDC: https://www.pololu.com/file/0J86/TB6612FNG.pdf.
https://www.ti.com/motor-drivers/brushless-dc-bldc-drivers/overview.html. At 6:35 in the video if you scroll down, you will see what needs to happen that is not happening already on the BBBlue for the BLDC motors to work. Complicated…yes. Worth making it work…yes. Gaining knowledge…priceless.
Sorry for the long wait, I’m a first-semester college student, so my schedule is rather busy right now.
I took a look at the resources you linked to, and I see what you’re getting at. I’ll probably just use an I2C servo controller to run the extra outputs.
Do you have any recommendations on how to make Ardupilot use the I2C port on the BeagleBone to run some servo outputs? I don’t know how to make it use the non-standard port. I have a servo controller to test it with.
No sir. But…I am sure you could set up your own i2c “gateway” for the BBBlue w/ “ease” for i2c1 onboard the BBBlue.
Have you reviewed the source for the i2c stuff from ArduPilot? I am currently not familiar with it but I can dig in it a bit for use for you and on my side of things.
I usually use smbus2 for i2c related items for promoting i2c communication. Oh and no big woof, do not worry about time limits. I have time every so often to reply and learn more too.
So, w/ the balloon photo, you can see where the i2c connector is located. Then, w/ the lower photo, the schematic, it shows exactly which pins are handled in the i2c connector.
I will go off and review some i2c source for the ArduPilot program. In the meantime, I would guess, if you have time, look into what you were describing to me and get one or two just in case. I have a Seeed Studio i2c adapter board and I found some JST-SH connectors to Grove adapters w/ wiring. This handy for attaching specific Grove modules directly to the BBBlue w/out having to rewire everything.
Anyway, off to look up the I2C sections on the ArduPilot source.
Seth
P.S. Since you can alter the source of ArduPilot to handle more than just one i2c peripheral, I am sure if it is not already implemented, just compiling the i2c source may be available. Who knows? This is sort of new to me. So, reading will ensue!
Also…look here: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL_Linux/I2CDevice.cpp . I think the ArduPilot people are working to make it available for use outside of the HAL object source. Anyway, I cannot do it along but if you have some time to work on making i2c source available in userspace, we may be able to figure it out. I know changing some lines will prove useful for the i2c1 address, “/dev/i2c-1”, on the BBBlue for when utilizing it in source for use.
I have had some slow production efforts so far. I can feel this will be very elongated with time and effort.
…
For i2c on the BBBlue, we have one option. Although odd, there may be some efforts already being accomplished due to the Compatibility Layer on the BBB and BBAI side of things with the PCA9685 onboard the ServoCape. The fellows at GSOC and beagleboard.org figured out how to manage a layer with dts and other board/file systems to make the PCA9685 that usually uses i2c into working with a couple of commands of the filesystem.
This means to me that the PCA9685 onboard the ServoCape or in another PCA9685 standalone package may be useful to you.
Seth
P.S. I have not had time to dive deeper in the source for the i2c yet on ardupilot and github.com. Are you making any headway?
Are you considering UAVCAN ?
You can use the uavcan4hobbist you can have several esc outputs - pwm, dshow, oneshot and you have save up to 12 outputs - I don’t remember right now the correct number.
I have some restrictions and concerns about I2C under beaglebone - I just can use 2 devices on the same bus, have several locks, cpu consuption and all using resistors on the lines - so I move several things to other protocols - SPI, UAVCan with better results.
The bridges you need 2 relay pins to control the bridges and you need to change the vehicle code to use 2 pins for each h-bridge - in case of blue you just can use 3 - once you can have max of 6 relay pins.
Do you see what @juvinski just typed? That may be something. I just know w/ i2c, you can add multiples of whatever you are doing w/ little to know extra hardware.
Hi @De_Funct
yes you can have up to 6 gpio. I done this - with the LM H-Bridge, just be carefull because on the default boot, you will have - I don’t remember right now, a motor running until ardupilot starts - in my case I made a rover and the left or right motor, when powering the vehicle , start spinning and just stop after the ardupilot’s boot.
My solution was change to gpio 5 and 6 to have everything working.
The i2c if I not wrong supports in theory, 128 slaves devices.
So sorry everyone, I’m just getting back into things after multiple extended COVID hospital visits (and a general lack of energy to do anything for many months), and am trying to get back into my projects that were so rudely interrupted by the virus. Thank you for continuing to ponder over this when I haven’t been able to!
I’ve taken a look at the resources that y’all have posted, and I see a few promising things. I do now have two PCA9685 16-port servo drivers, so I can test things as needed. Unfortunately I’m not too sure how to get an equivalent for UART or SPI.
Am I reading correctly that a good option is to put my 4 dshot-capable ESCs on UAVCAN, and then use the normal servo ports for my other functions? I’m good with that, especially because the VTOL motors (what those ESCs drive) will then have better response time and control resolution than over analog servo anyways. Is there any sort of example available for how to set up ESCs on UAVCAN?
Since my VTOL ESCs are Dshot capable, can’t I just use GPIO to transmit to them over Dshot? That clears up enough normal servo pins to do what I need, and I know Dshot is supported by Ardupilot. Shouldn’t I be able to just declare some GPIO pins as outputs in my hardware file, and then assign those in ardupilot to the proper motors?
I was thinking of using UAVCAN, but that would probably be more complicated and higher latency than just using Dshot over GPIO.
First off, please forgive me. I am happy people can beat this pandemic. It is nice to be a survivor and know how terrible things are currently. Outside of heartfelt stuff…
Other people have sort of moved on. I bring this up b/c the other people seem to know more than I on this issue. Me personally, I have not used DShot and I cannot describe what UAVCAN is right now for some reason.
I still like the port of this project to the BBB and BBBlue and pocket beagle. I never would have thought to fly a BBBlue into a tree if it were not for the people behind the porting of ArduPilot to the Beagleboard.org boards.
So, if you want to try to update me, b/c I know things too, on exactly what you need…I can probably be of some assistance but probably not 100% productive on your end from what I can explain.
…
Okay…I say all that to say this: If you have a BBBlue, using GPIO is fine for whatever reason you have currently. On/Off…this on/off will you turn things on and turn things off.
…
The port is made. The idea to keep things current is not easy from what I have seen. Some people, not me, are better than others at this idea.
Seth
P.S. I never really understood what exactly you were trying to do. This is my issue mostly, i.e. as most people read and just blindly answer. But…I have a real concern for making it work, keeping it working, and being able to use it in the future as a working model for something (flying, making my two wheeled bots go, go, go, and the new Blimp status on ArduPilot seems neat)! So, outside of my life and my needs, please tell me exactly what you need/want. I will tell you upfront if I can help. I just do not want to waste your time if you are willing to listen to someone else instead. That is all. Yes sir!
I didn’t realize people had moved on, I just thought that discussion had subsided while I was away. Thanks for letting me know!
I’ll try going through the documentation again now that I know to look for Dshot and UAVCAN instead of SPI or I2C, and I’ll see where I can get with that. I’ll open a new topic/post if I have any more issues/questions. Thank you for all your help!
Hello
I am getting a little late in discussion but here is my advice. I think you can use splitter on elevons servos as each side of wings will operate with the same logic thus reducing total PWM to 8.
A note about the airframe, I dont thing that this configuration will be easy to implement as there is no known configuration for flat biplane.
I suspect this wing arrangement is not airworthy…unless you have successfully demonstrated it?
I was simply planning on pulling an X-29 and forcing something unstable to behave in a stable manner with a control loop in ardupilot. As such, I felt like I needed the extra ability for each flap to operate independently, so everything is an independent flap-e-von.
I haven’t even built the airframe yet, much less flown it, sadly.
, we arrive at my question.
