BTW if someone knows a better way to attach a video than creating a zip, please let me know.
Usually we just upload the video to YouTube and add the embedded video to the post. You can make the video "unlisted" if you don't want it showing up on YouTube without a link.
Nice line-following and very "Entertaining" music, Ben!
BTW, your line-following path looks kind of like an Easter Island head silhouette. I say make another one to match Ken's head profile. I know better than to suggest mine; my nose is so big that it would be cruel & unusual punishment to make a bot try to follow that treacherous path.
I'd rather put the BOM money towards a bigger battery than dead weight as well. I haven't requested battery quotes yet but I'm expecting the cost to be noticeable. The current battery is probably undersized , it was just one that I could get easily.
Here are a few more "heads" to ponder. I mount my line following tracks to foam core sheets and store them behind my office supply cabinet.
Ive been thinking about power switches the past couple of days and I thought I would throw the topic out for discussion. Just to review, the S2 had a hard slide type power switch. You cant get much simpler than that but it does look at little dated by modern standards. Soft power switches on the other hand typically take the form of a push switch which you usually press to turn the device on and then a long press or processor command turns the device on.
The charger IC which I have selected offers support for a soft power switch in the form of a Ship Mode. When in the Ship Mode, the battery current drops to a 20uA draw. To put that into prospective, a fully charged 3000 mAh battery would take 15 years to discharge! The Ship Mode can be exited and the robot turned on by either a push button switch press or by connecting the USB cable at which point the battery charging also starts automatically.
I envision replacing the power slide switch with a second push button switch on the right side of the user interface area. The left switch would operate the same as before and the new right push switch would act as a soft power switch. The new switch would be connected to both a Prop IO and the battery charger IC.
The battery charger Ship Mode can only be entered via a command over the I2C bus and this is where the potential problem arises. We can add appropriate code to the S3 object to detect if the user holds down the power off push switch and send command over the I2C bus easily. Since the S3 object runs in its own cog, I believe its unlikely that a user would write code that would interfere with the switch press detection and power off behavior. Someone please correct me if thats a bad assumption. The only thing that I can think of is if someone set the switch IO direction incorrectly causing the S3 object to not be able to read the switch. We could counter this by checking the IO direction in the object every time it polls the input if needed.
The only problem case that I can see would be if someone decided to directly control the hardware and not utilizes the S3 object. I cant think of a reason to do this other than expanding it in some way, PhiPi did an amazing job of cramming vast functionality into a single cog. In this case, a user would need to write some power off code. What do you guys think, is this is an acceptable trade for the inclusion of a soft power switch?
The only problem case that I can see would be if someone decided to directly control the hardware and not utilizes the S3 object. I cant think of a reason to do this other than expanding it in some way, PhiPi did an amazing job of cramming vast functionality into a single cog. In this case, a user would need to write some power off code. What do you guys think, is this is an acceptable trade for the inclusion of a soft power switch?
I'm not dead set against a soft power switch but I think it's very likely the Scribbler will be loaded with all sorts of strange software.
A while back someone posted a demo using the S2's microphone and speaker, I don't know if the demo used the S2 object or not but I think there will be plenty of times none standard software will be loaded in the Scribbler.
I like the soft power switch idea, but I'd be concerned if there weren't a way to power the Scribbler off without having the official object running in the Scribbler.
Worse case you could reload the default software - couldn't you? As you have just outline it, if someone had an issue where they messed up their power switch by reprogramming something incorrectly - their code would reveal the fault would it not?
Would removing the battery and replacing it restart the robot? If so, you could then reload the default. Or I am I missing something?
Ben, thanks to you and the Parallax gang for involving users in these decisions or at least in the discussion! Sounds like lots of great work is happening.
Thanks for feedback everyone. I can't think of anything that an errant program would do that couldn't be undone by simply reloading the default program. You wouldn't have to pull the battery to reload the default, the FTDI USB chip drives the reset line so it can reset the Prop out of any sort of locked up condition. The annoying case would be if your robot was driving it's wheels full speed and blaring the speaker while your computer blue screened. You would have to deal with that while waiting for your PC to reboot. In that case, I'd probably disconnect the battery until my PC was operational again. It probably only takes 15 - 20 lines of code to turn the power off, its just a short message over the I2C bus. We can provide a code snippet for easy inclusion in someones program without including the entire S2 object as well. -Ben
There are several hardware based soft power switches as well so that code does not have to be involved. For example, Pololu's soft power switch. Plus some newer switching ICs have soft enables built in.
One nice thing about a slide or toggle switch is that you can look at it and tell whether it's on or off, regardless of other soft or programmable cues. In the S2, all the LEDs, including the "power" LED are software driven, and it's possible to write a program wherein the bot is "on" but the blue light remains unlit. So the S2's switch position is the only completely reliable indication fo its power state.
If a "soft" power switch were implemented, I would also recommend a hardware-connected power LED for positive identification of the on/off state, without relying on software.
+1 with Phil. Dated-looking or not, a master off slide switch to disconnect the battery is IMO the best option. Soft switches are cool, but when you need to shut the thing down NOW for whatever reason, you want an easy-off kill switch. Reloading software or removing batteries are not beginner-friendly options.
There are some lovely push on/push off mechanical switches that would look great, but those are pretty expensive compared to a simple slide switch. Save the switch money and spend it elsewhere. Lasers?
Thanks for the feedback everyone, lots of good points. My thinking is that we should just keep the slide power switch since that's the only way to guarantee that the user can turn the power off regardless of their software load. I don’t think we should have both a soft power switch and a hard power switch since this would be confusing to users. We would just ignore the soft power feature all together. If someone were to send the I2C command to start the ship mode, plugging in the USB cable or cycling the power switch will reset everything.
We could still use the power feature of the charger IC to have the Scribbler turn it self off right? I think it would be nice to still have access to this feature.
Thanks for keeping us in the loop. I'm a big fan of the S2 but there are a few things about the S2 which I think could be improved and I'm excited to see what improvements you have planned.
I hope you keep the discussion going when it's time to think about interfacing to the hacker port. As I mentioned earlier in the thread, I really dislike level shifters for general purpose I/O (they're great if they're intended to be used with known hardware peripherals).
I originally thought some 4.7K resistors would be fine on the hacker port but I've found several devices which won't work with a 4.7K resistor in series. The SF02 rangefinder (which should be one of the first peripherals added to any Scribbler) doesn't communicate with the Propeller Activity Board if I plug the TX line into the a servo header. I have to use an I/O pin without a resistor in order for the serial communication to work well. I've heard of other people having similar trouble with GPS devices when used with a series resistor.
I don't know what should be used to protect the Prop I/O pins, but I hope the problem is given a lot of thought because IMO, having the hacker port work well with other devices is very important in order to use the Scribbler to its full potential.
You are right, the power off feature could still be used. You would just need to send the appropriate I2c command over the bus. Wake up would happen on connection of a USB cable or cycling the power switch off and then back on.
If a "soft" power switch were implemented, I would also recommend a hardware-connected power LED for positive identification of the on/off state, without relying on software. -Phil
Agree! The mechanical switch would be a master power switch and the soft switch could be like the "standby" switches on many products today. As with any switch, a power LED should be trivial to implement.
Soft switches are cool, but when you need to shut the thing down NOW for whatever reason, you want an easy-off kill switch.
One of the reasons that I suggested a hardware based soft switch. They can be controlled with software, but can also be controlled with a mechanical switch in many cases so they can be killed instantly.
In all honesty, the soft switch idea, although cool and in line with current technology, needs a valid justification to be added to the design, in my opinion. Other than the cool factor, I don't have one....
Let’s talk about the Hacker Port next since Duane brought IO protection for it. I know there will likely be a variety of opinions on how we should connect the Hacker Port IO’s to the Prop since the Hacker port can be used in so many different ways. We have already decided to remove the 3.3 -> 5V level shift since it has been problematic in the past. The Propeller has 8kV ESD protection internally so we are really just talking about protecting the Hacker Port from user faults. The most common faults will be a high output shorted to ground, low output shorted to the 3V3 and a hacker input of 5V. In order to drive the design choice, I came up with these design specs:
It should not impose any severe hardware interfacing limitations on the user.
It should protect the Propeller IO when the IO is driven in all possible direction and logic states from shorts to 5V and GND.
The Propeller’s absolute max pin voltage is spec’d at 0.3V over Vcc so we will need to clamp the voltage that the Prop sees to 3.6V max. We should also limit the current to 40 mA per pin.
We will trust the Propeller’s internal ESD circuitry to protect it from ESD events.
We won’t try to protect the Propeller from negative voltages or voltages higher than 5V since those don’t exist on the hacker port.
I considered a half dozen protection schemes and only two met my design requirements:
1) Small Series Resistor & Forward Biased Diode to 3V3 – I have used this solution in the past and it can be pretty solid. The challenge is finding inexpensive and small diodes with a Vf of <= 0.3 V. A quick search of Digikey didn’t turn up many options.
2) Small Series Resistor & Zener Diode clamp – This option seemed the best of all considered. There are lots of inexpensive and relatively small zener’s available. I looked at arrays but single zener packages seemed to be the most cost effective and smallest size. The trouble with zener’s is that they have an internal impedance of ~100 ohms which limits how hard they can clamp. I was able to work around this be using a 3.0V zener instead of a 3.3V . Below are the design calculations, the worst case prop IO voltage would be 3.62V with a 5V input which is close enough to the design goal for me. I also calculated the RC roll off frequency at just over 1 Mhz which should be ok for most user purposes I think.
Finally to wrap up this long post, let’s look at the Hacker Port power supply The battery charger IC has a built-in boost switching power supply and power path circuitry which is designed to supply 5V for USB OTG applications. With a USB cable connected, the hacker port power would be supplied directly from USB port. Without a USB cable, the LiPo battery voltage would be boosted up to 5VDC @ > 1.3 Amps. There should be plenty of power to drive a couple servo’s and half dozen sonars if you wanted to from the battery. I’m currently planning on putting a ~1.0 Amp PTC fuse in-line with the hacker port since there is no electronic current limiting to protect it.
I think this is a relatively simple protection plan that will be both robust and minimally limit user hardware interfacing options. I look forward to any feedback that you might have though. -Ben
Ben - Thanks for the detailed discussion of the IO protection. You solution seems ingenious. I like the power supply idea too.
If I remember correctly - one of the goals set by Ken was to move access to the Hacker's Port to the surface of the S3 - this along with your work on the IO protection and power supply should make this really fun, easy and safe to use.
Thanks again to you and Parallax for the open discussion of all this during the design process - it really gives us a insight into how the sausage gets stuffed! ;-)
A latching relay could be the best of both worlds for the "soft power switch". Nearly zero power consumption and could br turned on or off through user button presses or software.
A latching relay could be the best of both worlds for the "soft power switch". Nearly zero power consumption and could br turned on or off through user button presses or software.
The old Androbot TOPO robots used a similar method. They had a pair of push buttons on the back of the robot on the power board. One was used to turn on the robot and would engage the relay. The other would break the circuit and turn the robot off. Having the relay is nice since it also had a battery monitor as part of that board and could automatically shut off power if the voltage was too low.
My preference would be something like this or a regular power switch. I really dislike not having a way to completely turn something off.
Ive been working on the detailed S3 design and I wanted to share the progress and a few changes with everyone. Below is the schematic for the finalized hacker port. It has the 3V zener diodes to protect the digital IOs as previously discussed. Also, some users had requested access to the 3V3 supply so I have brought it out in place of the 5V0 for the hacker port analog input pins. This seemed the easiest option for exposing the 3V3 without breaking the Parallax servo connector standard since the analog ports didnt match it anyway.
I had to add a much larger 3V3 linear regulator to supply the 310 mA peak current that the XBee Wi-Fi module draws in addition to the Propeller and other digital circuitry. The regulator design turned out to be a little challenging because of the LiPo batterys low voltage. The battery voltage is nominally about 3.6 but varies from about 2.7 to 4.2V over its full range. When the battery is discharged below the 3.5V Vsys min setting, the charger IC boosts the SYS output to 3.5V. This is a pretty neat feature and lets us use an LDO for the regulated 3V3 supply. The challenge was finding a 500mA LDO with a drop out voltage of less than 200mv. I really only found one part which met the required specs and fortunately it wasnt too expensive: Analog Devices ADP124ACPZ-3.3-R7.
I also designed a serial line multiplexer for the XBee module and USB data path to support WiFi programming based on Jeffs work. Both the XBee module and the FTDI USB chip need a connection to the Propellers serial port (P30 & P31) at different times to support programming. I needed a circuit which intelligently switched the serial connection between the two devices. With the S3 connected to a PC USB port, the Propellers serial lines are connected to the FTDI USB converter. Otherwise the Propeller is connected to the XBee module. The goal was to give the USB connection priority, but also enable WiFi programming if the S3 is being charged by a USB wall adapter or just powered from the battery. Im actually not 100% sure that the switching of the serial port lines wont cause a glitch with the PC programming, but given the complexity, I probably just need to route the board and test the prototype. I was lucky that the BQ24392RSER USB switch IC provided an active low output with the desired logic levels (!USB_HOST_DETECT). A 74LVC1G18 1:2 mux and a 74LVC1G157GW 2:1 mux perform the serial data line switching. The unselected output of the 74LVC1G18 is Hi-Z. This addresses the issues of inadvertently powering the FTDI chip through the Propellers TX data lines.
The motor driver requires of a 3.5V input to 9.0V @ 900mA output boost switching power supply which is based on the Analog Devices ADP1614. I had previously tested this IC using an eval. board with my Frank prototype.
Finally I decided to remove the over-current protection comparator and latch off circuit from the motor driver. The trip point for this circuit on the S2 was 2.2Amps with a 10mS time constant. The original design intent was just to protect from short circuits so the higher current limit prevents nuisance trips. For the new design, ADP1614s step-up switching regulator has an internal cycle-by-cycle input over current protection which would protect the driver IC by reducing the 9V0 bus to about 3V in the event of a short at the output. The battery charger IC and the battery itself additionally both have short circuit protection so it would be a race to see which one tripped first in the event of a fualt. I kept the motor current measurement amp since Phils S2 object uses it as part of his stall detection algorithm.
Thanks for the continued feedback everyone. I have made a number of changes here so please let me know if you see something that I missed. These changes represent the bulk of the schematic level design work required the first S3 prototype. I have some additional tweaks and minor clean-up to do which I hope wrap up next week. Ill post the final schematic at that point for review and start routing the boards there after. Have a great weekend. -Ben
Comments
Usually we just upload the video to YouTube and add the embedded video to the post. You can make the video "unlisted" if you don't want it showing up on YouTube without a link.
BTW, your line-following path looks kind of like an Easter Island head silhouette. I say make another one to match Ken's head profile. I know better than to suggest mine; my nose is so big that it would be cruel & unusual punishment to make a bot try to follow that treacherous path.
Can the S3 monitor its own battery charge level?
You are welcome to increase the capacity and size of the Lithium Ion battery pack if it fixes the center of gravity problem.
I have a 50-teacher workshop coming up in Iowa, all around the S2.
Ken Gracey
That is me, erco. Can't you see that long horse-head of a person is all mouth? It talks all the time and doesn't do anything. . .
Ken Gracey
I was just thinking it would be great to have a larger capacity battery pack in there.
I've never complained about having too much capacity in a robot battery.
Yeah, hours of runtime is cool for the S2's artwork capability.
Ben, consider a bigger battery. We have customers who will pay for it.
Ken Gracey
Here are a few more "heads" to ponder. I mount my line following tracks to foam core sheets and store them behind my office supply cabinet.
-Ben
.
1. Хотелось бы иметь в s3 возможность поднятия маркера.
2. Хотелось бы, чтобы в gui могли читаться raw данные с датчиков линии. Это даст возможность использовать регуляторы (ПИ, ПИД и т.п.)
Translated:
Ive been thinking about power switches the past couple of days and I thought I would throw the topic out for discussion. Just to review, the S2 had a hard slide type power switch. You cant get much simpler than that but it does look at little dated by modern standards. Soft power switches on the other hand typically take the form of a push switch which you usually press to turn the device on and then a long press or processor command turns the device on.
The charger IC which I have selected offers support for a soft power switch in the form of a Ship Mode. When in the Ship Mode, the battery current drops to a 20uA draw. To put that into prospective, a fully charged 3000 mAh battery would take 15 years to discharge! The Ship Mode can be exited and the robot turned on by either a push button switch press or by connecting the USB cable at which point the battery charging also starts automatically.
I envision replacing the power slide switch with a second push button switch on the right side of the user interface area. The left switch would operate the same as before and the new right push switch would act as a soft power switch. The new switch would be connected to both a Prop IO and the battery charger IC.
The battery charger Ship Mode can only be entered via a command over the I2C bus and this is where the potential problem arises. We can add appropriate code to the S3 object to detect if the user holds down the power off push switch and send command over the I2C bus easily. Since the S3 object runs in its own cog, I believe its unlikely that a user would write code that would interfere with the switch press detection and power off behavior. Someone please correct me if thats a bad assumption. The only thing that I can think of is if someone set the switch IO direction incorrectly causing the S3 object to not be able to read the switch. We could counter this by checking the IO direction in the object every time it polls the input if needed.
The only problem case that I can see would be if someone decided to directly control the hardware and not utilizes the S3 object. I cant think of a reason to do this other than expanding it in some way, PhiPi did an amazing job of cramming vast functionality into a single cog. In this case, a user would need to write some power off code. What do you guys think, is this is an acceptable trade for the inclusion of a soft power switch?
-Ben
I'm not dead set against a soft power switch but I think it's very likely the Scribbler will be loaded with all sorts of strange software.
A while back someone posted a demo using the S2's microphone and speaker, I don't know if the demo used the S2 object or not but I think there will be plenty of times none standard software will be loaded in the Scribbler.
I like the soft power switch idea, but I'd be concerned if there weren't a way to power the Scribbler off without having the official object running in the Scribbler.
Worse case you could reload the default software - couldn't you? As you have just outline it, if someone had an issue where they messed up their power switch by reprogramming something incorrectly - their code would reveal the fault would it not?
Would removing the battery and replacing it restart the robot? If so, you could then reload the default. Or I am I missing something?
Ben, thanks to you and the Parallax gang for involving users in these decisions or at least in the discussion! Sounds like lots of great work is happening.
If a "soft" power switch were implemented, I would also recommend a hardware-connected power LED for positive identification of the on/off state, without relying on software.
-Phil
There are some lovely push on/push off mechanical switches that would look great, but those are pretty expensive compared to a simple slide switch. Save the switch money and spend it elsewhere. Lasers?
My two cents.
Thanks for keeping us in the loop. I'm a big fan of the S2 but there are a few things about the S2 which I think could be improved and I'm excited to see what improvements you have planned.
I hope you keep the discussion going when it's time to think about interfacing to the hacker port. As I mentioned earlier in the thread, I really dislike level shifters for general purpose I/O (they're great if they're intended to be used with known hardware peripherals).
I originally thought some 4.7K resistors would be fine on the hacker port but I've found several devices which won't work with a 4.7K resistor in series. The SF02 rangefinder (which should be one of the first peripherals added to any Scribbler) doesn't communicate with the Propeller Activity Board if I plug the TX line into the a servo header. I have to use an I/O pin without a resistor in order for the serial communication to work well. I've heard of other people having similar trouble with GPS devices when used with a series resistor.
I don't know what should be used to protect the Prop I/O pins, but I hope the problem is given a lot of thought because IMO, having the hacker port work well with other devices is very important in order to use the Scribbler to its full potential.
You are right, the power off feature could still be used. You would just need to send the appropriate I2c command over the bus. Wake up would happen on connection of a USB cable or cycling the power switch off and then back on.
-Ben
Agree! The mechanical switch would be a master power switch and the soft switch could be like the "standby" switches on many products today. As with any switch, a power LED should be trivial to implement.
One of the reasons that I suggested a hardware based soft switch. They can be controlled with software, but can also be controlled with a mechanical switch in many cases so they can be killed instantly.
In all honesty, the soft switch idea, although cool and in line with current technology, needs a valid justification to be added to the design, in my opinion. Other than the cool factor, I don't have one....
- It should not impose any severe hardware interfacing limitations on the user.
- It should protect the Propeller IO when the IO is driven in all possible direction and logic states from shorts to 5V and GND.
- The Propeller’s absolute max pin voltage is spec’d at 0.3V over Vcc so we will need to clamp the voltage that the Prop sees to 3.6V max. We should also limit the current to 40 mA per pin.
- We will trust the Propeller’s internal ESD circuitry to protect it from ESD events.
- We won’t try to protect the Propeller from negative voltages or voltages higher than 5V since those don’t exist on the hacker port.
I considered a half dozen protection schemes and only two met my design requirements:1) Small Series Resistor & Forward Biased Diode to 3V3 – I have used this solution in the past and it can be pretty solid. The challenge is finding inexpensive and small diodes with a Vf of <= 0.3 V. A quick search of Digikey didn’t turn up many options.
2) Small Series Resistor & Zener Diode clamp – This option seemed the best of all considered. There are lots of inexpensive and relatively small zener’s available. I looked at arrays but single zener packages seemed to be the most cost effective and smallest size. The trouble with zener’s is that they have an internal impedance of ~100 ohms which limits how hard they can clamp. I was able to work around this be using a 3.0V zener instead of a 3.3V . Below are the design calculations, the worst case prop IO voltage would be 3.62V with a 5V input which is close enough to the design goal for me. I also calculated the RC roll off frequency at just over 1 Mhz which should be ok for most user purposes I think.
Finally to wrap up this long post, let’s look at the Hacker Port power supply The battery charger IC has a built-in boost switching power supply and power path circuitry which is designed to supply 5V for USB OTG applications. With a USB cable connected, the hacker port power would be supplied directly from USB port. Without a USB cable, the LiPo battery voltage would be boosted up to 5VDC @ > 1.3 Amps. There should be plenty of power to drive a couple servo’s and half dozen sonars if you wanted to from the battery. I’m currently planning on putting a ~1.0 Amp PTC fuse in-line with the hacker port since there is no electronic current limiting to protect it.
I think this is a relatively simple protection plan that will be both robust and minimally limit user hardware interfacing options. I look forward to any feedback that you might have though. -Ben
If I remember correctly - one of the goals set by Ken was to move access to the Hacker's Port to the surface of the S3 - this along with your work on the IO protection and power supply should make this really fun, easy and safe to use.
Thanks again to you and Parallax for the open discussion of all this during the design process - it really gives us a insight into how the sausage gets stuffed! ;-)
The old Androbot TOPO robots used a similar method. They had a pair of push buttons on the back of the robot on the power board. One was used to turn on the robot and would engage the relay. The other would break the circuit and turn the robot off. Having the relay is nice since it also had a battery monitor as part of that board and could automatically shut off power if the voltage was too low.
My preference would be something like this or a regular power switch. I really dislike not having a way to completely turn something off.
I had to add a much larger 3V3 linear regulator to supply the 310 mA peak current that the XBee Wi-Fi module draws in addition to the Propeller and other digital circuitry. The regulator design turned out to be a little challenging because of the LiPo batterys low voltage. The battery voltage is nominally about 3.6 but varies from about 2.7 to 4.2V over its full range. When the battery is discharged below the 3.5V Vsys min setting, the charger IC boosts the SYS output to 3.5V. This is a pretty neat feature and lets us use an LDO for the regulated 3V3 supply. The challenge was finding a 500mA LDO with a drop out voltage of less than 200mv. I really only found one part which met the required specs and fortunately it wasnt too expensive: Analog Devices ADP124ACPZ-3.3-R7.
I also designed a serial line multiplexer for the XBee module and USB data path to support WiFi programming based on Jeffs work. Both the XBee module and the FTDI USB chip need a connection to the Propellers serial port (P30 & P31) at different times to support programming. I needed a circuit which intelligently switched the serial connection between the two devices. With the S3 connected to a PC USB port, the Propellers serial lines are connected to the FTDI USB converter. Otherwise the Propeller is connected to the XBee module. The goal was to give the USB connection priority, but also enable WiFi programming if the S3 is being charged by a USB wall adapter or just powered from the battery. Im actually not 100% sure that the switching of the serial port lines wont cause a glitch with the PC programming, but given the complexity, I probably just need to route the board and test the prototype. I was lucky that the BQ24392RSER USB switch IC provided an active low output with the desired logic levels (!USB_HOST_DETECT). A 74LVC1G18 1:2 mux and a 74LVC1G157GW 2:1 mux perform the serial data line switching. The unselected output of the 74LVC1G18 is Hi-Z. This addresses the issues of inadvertently powering the FTDI chip through the Propellers TX data lines.
The motor driver requires of a 3.5V input to 9.0V @ 900mA output boost switching power supply which is based on the Analog Devices ADP1614. I had previously tested this IC using an eval. board with my Frank prototype.
Finally I decided to remove the over-current protection comparator and latch off circuit from the motor driver. The trip point for this circuit on the S2 was 2.2Amps with a 10mS time constant. The original design intent was just to protect from short circuits so the higher current limit prevents nuisance trips. For the new design, ADP1614s step-up switching regulator has an internal cycle-by-cycle input over current protection which would protect the driver IC by reducing the 9V0 bus to about 3V in the event of a short at the output. The battery charger IC and the battery itself additionally both have short circuit protection so it would be a race to see which one tripped first in the event of a fualt. I kept the motor current measurement amp since Phils S2 object uses it as part of his stall detection algorithm.
Thanks for the continued feedback everyone. I have made a number of changes here so please let me know if you see something that I missed. These changes represent the bulk of the schematic level design work required the first S3 prototype. I have some additional tweaks and minor clean-up to do which I hope wrap up next week. Ill post the final schematic at that point for review and start routing the boards there after. Have a great weekend. -Ben
Will we still have to drill a hole in the shell to access it?
It all looks well thought out, Can't wait to see it in action.
-Tommy