Group Actions
Engagement
  • Author Author: screamingtiger
  • Date Created: Date Created
  • Views 2105 views
  • Likes 2 likes
  • Comments 23 comments
Related
Recommended

Quad Cop with ChipKit Pi - An "Experience" with Innovation Required

screamingtiger

Previous Posts

 

Application Information
http://www.element14.com/community/community/design-challenges/sci-fi-your-pi/blog/2015/04/22/some-information-from-my-application

ChipKit Pi Vs Arduino Pro Mini
http://www.element14.com/community/community/design-challenges/sci-fi-your-pi/blog/2015/05/01/quick-update-on-the-quadcop-and-the-chipkit-pi

Quadcopter Assembled (You call that a Quadcopter?)
http://www.element14.com/community/community/design-challenges/sci-fi-your-pi/blog/2015/05/06/quadcopter-assembled

QuadCop -The Control Switch
http://www.element14.com/community/videos/16202/l/control-switch-explanation

 

CHIPKIT-PI-3-800x533.jpg

 

I continue to find issues with the ChiKit Pi and work around them as I can.  Here is a brief list and then a more in depth explanation for those who are interested.  My goal is to show our Hosts the amount of innovation it takes to use the ChipKit Pi and to also help others who may choose to use it.

 

1)  Digital Pins 4,5,6,7 and analog pins A3,A4 and A5 are not present.  While there are pinouts on the the CKP for  the digital pins, they are connected to nothing.  SDL and SCL are present but not in the form of A4 and A5.

 

2)  There is a bug in I2C as a slave, where the callback routine only gets 1 byte at a time.  This means if I send  3 bytes in a block, the call back will be called 3 times instead of 1 time.  This isnt a show stopper but requires one to create a block protocol similar to a serial communication.

See https://github.com/chipKIT32/chipKIT32-MAX/issues/310 for the bug submission

 

3)  If your code uses Serial.println statements, you need to change to Serial1.println to see the output on the pi.

 

4) The Servo library doesn't work for me, however the SoftwarePWMServo does, and work well it has.  its very similar just different function calls.  Its not object oriented though.

 

5) The serial pins for the Pi are covered up by the CKP.  There is a small header on  the top of the board next to the header that connects to the pi.  Some of the GPIO pins are brought here from the pi, but they are NOT in the expected location.  You need a pinout for this.   However the Serial pins are not broken out.  So to get around this I soldered wires to the serial pins so I can connect my GPS directly to the Pi.

 

6) Number 6 isn't found yet but I am sure it will be  image

 

None of these bugs are show stoppers.  However, they require innovation to work around.  I need to solder on wires, develop a block protocol for I2c, and remap all my pins in software to work around the pins I used that are not present on the CKP.

Now for the more in depth explanations.


ChipKit Pi (CKP) notes

The CKP gives us a nice breakout for the PICPIC32MX250F128B in a format similar to the arduino uno.

However, because the PIC32 included on the board does not have as many pins as the AVR328p on an UNO, some of the

pins are present on the breakout but not actually connected to anything!  This had me stumped for a bit until I

found the pinout located here:

 

http://wiki.kewl.org/dokuwiki/boards:chipkitpi

 

Once again I assumed this breakout was 100% arduino compatible and I assumed wrong.  This meant I had to do some

reading, and it serves me right for not doing so up front.   Thats ok, I still really like it.

 

My original pinout mapping for the Arduino Pro Mini used most of the pins. The chipkit Pi is missing Digital Pins

4-7 and A4,A5.  On the Arduino A4 and A5 are used for I2C SDA and SCL respectively.  The SDA and SCL are present on

the breakout and can be used to bring the CKP onto the I2C bus.  Its unclear to me if these will actually function

as analog pins as well.  A3 is nowhere to be found.

 

In my original code for the Aruino, I needed 7 digital pins to read PWM, 4 digital pins to write PWM (software

based), SDA, SCL, and 2 digital pins for signaling the RPI.

 

So 13 digital pins are needed in addition to the two for I2c.  However the CPK only has 12 digital pins if I also

count A0 and A1 as digital pins.  What to do?

 

Right next to the header where the raspberry pi
                    JP5
                +---J4---+
NC              01      02 GPIO0/GPIO2
GPIO1/GPIO3     03      04 NC
GPIO4           05      06 GND
GPIO18          07      08 GPIO17
GND             09      10 GPIO21/GPIO27
GPIO23          11      12 GPIO22
GPIO24          13      14 3V3
GND             15      16 GPIO10
GPIO25          17      18 GPIO9
GPIO8           19      20 GPIO11
GPIO7           21      22 GND
                +--------+

You can see some of the GPIO pins covered up by the Raspberry Pi are available for use.  I "assume", and there is

that word again, this is a stright passthrough from the RPi.

 

Here are the items that need a digital pin:
Radio Channel 1 - Forward/Reverse
Radio Channel 2 - Left/Right
Radio Channel 3 - Climb/Dive
Radio Channel 4 - Rotate left/Right
Radio Channel 5 - Auto or manual pilot mode
Radio Channel 6 - Macro mode start/stop
Radio Channel 7 - Perform sensor sweep indicator

 

Motor ESC* 1
Motor ESC* 2
Motor ESC* 3
Motor ESC* 4


Automode Indicator - Connection to RPI to turn it to automode
Macromode Indicator - connection to RPI to tell it to start/stop recording
Sensor Sweep Indicator - connection to RPI to tell it to note a sensor sweep at these coordinates

*ESC = electronic speed controller, which given a PWM sets the speed of a brushless motor.  In all technicality

these pins actually connect to the flight controller not the ESCs themselves.


One solution is to read one of channels 5-7 through one of the GPIO pins on the RPFS.  Given the Raspian is not a

real time OS, this is generally not recommended.  However channels 5-7 are simply "off/on" so they go from 1ms to

2ms and nothing in between.  I feel that the variance that RPi will have is acceptable and will be less 100

microseconds anyways.  This would be an issue if I needed more precise readings but on these pins I do not.  if I

go this route I will take the reading 3 times in a row and use the average in case there is some 1ms delay for some

reason.

 

Another option is to instead of using 3 digital pins to signal the RPI, write commands through I2C.  I originally

avoided this approach due to my original design of using the Arduino Minis.  With all the reading and writing PWM

signals on top of some I2c stuff, I felt is was being overtaxed already.  The CKP has so much power though I think it will be strong enough to handle more parsing.

 

With the bug in I2C its going to be more work to implement additional I2C commands.  In the get hub bu submission at https://github.com/chipKIT32/chipKIT32-MAX/issues/310
There is a work around but it requires blocking the ISR.  Given I need to update servos and read PWM input all ISRs must run fast.  It would be better to work around the bug using non-blocking code.

 

Blocking code = When an ISR is called interrupts are disabled, so no other ISR can run.  Servos are updated via an ISR so if an ISR takes too long, the servos will start to jitter.

Parents

  • BTW I found issue  #6, well not an issue but a surprise none the less.

    Pin 2 outputs 3.3V instead of 5V.  So the flight controller would never read it as high.  Its the only oddball pin that does this I am using as output.


    SUPRISE!  image

  • in reply to screamingtiger

    A transistor or two should fix that, I'm sure =)

  • in reply to crimier

    Re:  Shift Register

     

    What I mean is that for reading PWM inputs, it very similar to pulseIn but it first does a pin select via the register.  This would allow 1 pin to read up to 8 PWM inputs, but NOT at the same time.

     

    The RPi as master and ChipKit and Arduino as slave is working fine.  In  my previous post the CHipKit can only read 1 byte at time at the driver level.

     

    I had experiminted with serial but it seems to be 10X slower than I2c in terms of the amount of time it takes to transmit a byte.  Not sure what that is about.

     

    In all actuality the protocols I have developed will work under any communication medium, just have to override the specific read and write functions.  The rest is just protocol over head for buffering and signaling when certain types of data are received.

     

    I will be spelling out my protocol very soon, so feel free to comment on it.  Right now I preparing a post where I use the chipkit to read PWM, and then write PWM to a quadcopter.  So it is essentially acting as a relay for the PWM signal.  This allows me to switch the sources of the PWM on the fly.

  • in reply to crimier

    BTW, other reasons I didn't choose serial:

    I might need up to 5 devices on the bus, with serial I can only use 2 per port (master and slave)

    The MicroStack GPS unit uses serial, so this itself uses up 1 serial port.

     

    The chipkt Pi has 2 uarts and there is always software serial, so plenty of serial ports to go around.  Its just that for each device I need to use up 2 pins on the master flight system.  I2C will allow only 2 pins total to be used on the master and I could have 5 devices connected to those 2 pins.  That is the main advantage of I2C.

     

    So the RPi is the master, and if I need to communicate with a GPS, the chipkit Pi and an arduino I will need to use 6 pins just for these 3 devices on the Pi.

    If I add another device, I will need 8 pins totals.

     

    I2c would require only 4 pins for the same count of devices.

  • in reply to screamingtiger

    Ah, understood the PWM thing =) Then what you need is some kind of analog multiplexer like this, not a shift register, I think. Or is it some another way?

     

    Serial being slow is weird. Could be something about a buffer needing to be flushed right after each Serial.write() . Or maybe just transaction speed being 9600 instead of, say, 115200 or more =)

     

    Yeah, that's the best thing about protocols - most of the times they're easily portable. I'm now searching for some protocol to do RPC over Unix sockets using Python. I think I'll search for something already existing today, as I don't want to reinvent the wheel =) But I've had developed my own protocols before and it'll be quite interesting to see yours!

  • in reply to screamingtiger

    Personally, I'm going to connect GPS using USB-UART converter. It's so easy to not to have enough UARTs when there's only one =) Converters are cheap and readily available... And you get a console. Actually, if you want, you can connect ChipKIT Pi through USB-UART, too =) I don't think you'll run out of USBs that easily, given that there are hubs and stuff like that.

     

    BTW, a good question. Are you going to make your own hardware? For example, make a custom board with that ChipKIT MCU + all the necessary logic and all the headers, as well as desolder all the unnecessary sockets from the Raspberry Pi (I know size and weight is an issue for copters).

  • in reply to crimier

    I've soldered on some additional connections to the chipkit pi but no I will not be removing anything.  I guess I did remove 3 pins from the xtrinsic board as they hit the HDMI port when connect to the pi.

     

    One of the properties of Quad Copters is they have a huge thrust to weight ration around 2 to 5.  So they are designed to lift weight.  the quad I have can probably life a 12 pack of beer.

     

    The main issue is space.I should be ok there.  I am trying very hard to use only components in the kit but right now I may have to include an Arduino pro mini.

     

    PS I was reading, doesn't the Pi have 2 uarts too?

Comment
  • in reply to crimier

    I've soldered on some additional connections to the chipkit pi but no I will not be removing anything.  I guess I did remove 3 pins from the xtrinsic board as they hit the HDMI port when connect to the pi.

     

    One of the properties of Quad Copters is they have a huge thrust to weight ration around 2 to 5.  So they are designed to lift weight.  the quad I have can probably life a 12 pack of beer.

     

    The main issue is space.I should be ok there.  I am trying very hard to use only components in the kit but right now I may have to include an Arduino pro mini.

     

    PS I was reading, doesn't the Pi have 2 uarts too?

Children